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, passkey assertion, or ID token | Access token, scopes, 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-scope 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?
Authentication 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?
Authorization 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.
OAuth 2.0 defines limited access using tokens with scope, duration, and other attributes. Agent systems often need more context than a broad string scope 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 scope?
- 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 OAuth 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. Authentication 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 passkey 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 authorization artifact to the protected service.
- 05
Evaluate both at execution
The resource server verifies identity, key possession, scope, context, freshness, and policy.
- 06
Deny or step up when context changes
A valid identity does not override an out-of-scope 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 DPoP or mTLS |
| Full account access consent | Authorization is too broad to express intent | Task-specific scope, limits, purpose, and expiry |
| User approved login, then agent wires funds | Authentication was mistaken for transaction approval | Fresh, action-bound authorization proof |
| Sub-agent inherits all permissions | Delegation does not attenuate privilege | Explicit delegation chain with reduced scope |
| 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: Authentication, Authorization, Verification, and Payment. A passkey can verify the human. Scoped consent can define what the agent may do. Verification can establish required attributes. Digitally signed transaction authorization can connect approval to the consequential action.