Authentication and authorization at a glance
| Authentication | Authorization | |
|---|---|---|
| Core decision | Who is making the request? | Is this identity allowed to perform this action? |
| Subjects | Agent, workload, human, or organization | Authenticated subject plus delegated policy |
| Typical evidence | Key possession, certificate, passkeyA phishing-resistant FIDO credential that replaces a password with public-key cryptography and local device verification. assertion, or ID token | Access token, scopeA defined boundary describing the operations or resources an access grant permits.s, structured permissions, or signed mandate |
| Timing | At registration, connection, login, or step-up | At token issuance and again at each protected action |
| Main failure | Impersonation or stolen credentials | Excess privilege, purpose drift, or out-of-scopeA defined boundary describing the operations or resources an access grant permits. execution |
| Example | Prove this is agent A acting for user B | Allow agent A to refund up to $100 for user B until 5 p.m. |
What does authentication prove?
authenticationThe process of establishing who or what is making a request and verifying the evidence supporting that identity. establishes a trustworthy answer to who is requesting. For an agentic action, that answer may include the software agent, its operator, the human on whose behalf it acts, and the key or authenticator currently under the caller’s control. NIST’s agent identity concept paper
Agent and human identities should remain distinct. If an agent simply reuses the human’s password or session cookie, the service loses visibility into which actor made the request and weakens revocation and accountability.
What does authorization decide?
authorizationThe policy decision that determines what an authenticated identity may do under the current scope, context, and limits. applies policy to an authenticated identity and a requested action. It evaluates the operation, resource, purpose, amount or data boundary, duration, delegation path, risk, and whether fresh human approval is required.
OAuthAn authorization framework for granting limited access to protected resources without sharing the user’s password. 2.0 defines limited access using tokens with scopeA defined boundary describing the operations or resources an access grant permits., duration, and other attributes. Agent systems often need more context than a broad string scopeA defined boundary describing the operations or resources an access grant permits. can express, so task-bound authority and structured action details become important. RFC 6749 OAuth 2.0
- Which operation is allowed?
- Which resource, merchant, account, or data set is in scopeA defined boundary describing the operations or resources an access grant permits.?
- What amount, frequency, purpose, location, and time limits apply?
- May the agent delegate to another agent or tool?
- Is the authority current, unrevoked, and appropriate to the present risk?
Why do agent systems confuse the two?
Many integrations begin with an API key or OAuthAn authorization framework for granting limited access to protected resources without sharing the user’s password. token and treat successful access as proof that every later action is legitimate. That collapses identity and policy into one long-lived credential.
A valid agent can still make an unsafe request because its instructions changed, a tool introduced new context, prompt injection altered the plan, or a sub-agent received more authority than intended. authenticationThe process of establishing who or what is making a request and verifying the evidence supporting that identity. should not become a permanent permission slip. OpenID Foundation’s agentic identity analysis
How should authentication and authorization work together?
- 01
Authenticate the agent
Verify its registered identity and current possession of its credential.
- 02
Authenticate the human when needed
Use a trusted method such as a passkeyA phishing-resistant FIDO credential that replaces a password with public-key cryptography and local device verification. when the person must approve or step up.
- 03
Issue constrained authority
Bind permission to the agent, human, resource, purpose, limits, delegation rules, and expiry.
- 04
Present proof with the action
The agent sends its identity evidence and authorizationThe policy decision that determines what an authenticated identity may do under the current scope, context, and limits. artifact to the protected service.
- 05
Evaluate both at execution
The resource serverThe API or service that hosts protected resources and evaluates access tokens and authorization policy. verifies identity, key possession, scopeA defined boundary describing the operations or resources an access grant permits., context, freshness, and policy.
- 06
Deny or step up when context changes
A valid identity does not override an out-of-scopeA defined boundary describing the operations or resources an access grant permits. request.
Common control failures
| What went wrong | Better control | |
|---|---|---|
| Agent uses the user’s password | Agent and human identities are indistinguishable | Separate agent identity plus delegated access |
| Long-lived bearer token is copied | Possession is not tied to the intended client | Sender-constrain with DPoPDemonstrating Proof of Possession. An OAuth mechanism that binds tokens to a client-held key to reduce token replay. or mTLSMutual Transport Layer Security. Both client and server present certificates, allowing the server to authenticate the calling client. |
| Full account access consent | authorizationThe policy decision that determines what an authenticated identity may do under the current scope, context, and limits. is too broad to express intent | Task-specific scopeA defined boundary describing the operations or resources an access grant permits., limits, purpose, and expiry |
| User approved login, then agent wires funds | authenticationThe process of establishing who or what is making a request and verifying the evidence supporting that identity. was mistaken for transaction approval | Fresh, action-bound authorizationThe policy decision that determines what an authenticated identity may do under the current scope, context, and limits. proof |
| Sub-agent inherits all permissions | Delegation does not attenuate privilege | Explicit delegation chainThe traceable sequence of authority grants from the original principal through agents, services, or tools. with reduced scopeA defined boundary describing the operations or resources an access grant permits. |
| Service logs only the user ID | Agent actions cannot be attributed | Record human, agent, task, policy, and outcome |
How LoginID connects the layers
LoginID separates four capabilities: authenticationThe process of establishing who or what is making a request and verifying the evidence supporting that identity., authorizationThe policy decision that determines what an authenticated identity may do under the current scope, context, and limits., Verification, and Payment. A passkeyA phishing-resistant FIDO credential that replaces a password with public-key cryptography and local device verification. can verify the human. scopeA defined boundary describing the operations or resources an access grant permits.d consent can define what the agent may do. Verification can establish required attributes. Digitally signed transaction authorizationThe policy decision that determines what an authenticated identity may do under the current scope, context, and limits. can connect approval to the consequential action.