Authentication vs. authorization: OAuth and OIDC
Authentication establishes the identity associated with a request. Authorization determines what the request is permitted to do. OAuth provides a framework for granting access to protected resources. OpenID Connect, or OIDC, adds an identity layer for authentication on top of OAuth.
These mechanisms work together, but their tokens and claims serve different purposes. OpenID Connect's overview explains the authentication relationship. A successful sign-in does not, by itself, authorize every downstream action.
Explore Dome: Access · Docs: Agent identity.
Ask what each token is for
Suppose an employee signs into an assistant and asks it to retrieve a support case. The application may receive identity information for the sign-in and separately obtain an access token for a protected service.
| Item | Question it helps answer |
|---|---|
| Identity claim | Which subject does the trusted issuer identify? |
| Access token | What granted access can be presented to a resource server? |
| Token audience | Which receiving service is the token intended for? |
| OAuth scope | Which categories of access were granted? |
| Resource-server decision | Is this particular request permitted? |
For the case request, the access token must be intended for the receiving service, which then decides whether the employee may read that case.
JWT describes a token's format, not its purpose or trustworthiness. The receiving service must validate the relevant signature and claims according to its protocol and trust configuration.
Anyone who has a bearer token can use it if the receiving service accepts it. Keep it protected, even if it expires quickly.
Explore Dome: Access · Docs: Agent identity.
Define what OAuth scopes allow
A scope such as “tickets.write” may describe a class of operations. The name alone doesn't tell you whether the employee may close a particular ticket or change another team's records.
The service must define which operations and records each scope allows the caller to access. It may combine the grant with role membership, object ownership, current state, and other authoritative facts.
The Model Context Protocol (MCP) authorization specification describes OAuth-based access for relevant HTTP deployments. OAuth grants access to the protected service. The service may then apply additional business rules to decide whether a particular action is allowed.
Also distinguish the application's identity from the represented user's identity. Delegated authorization explains how to account for both identities.
Explore Dome: Authorization · Docs: Govern per end user.
Identify which check failed
If the employee's case request fails, trace it through these checks:
- Was the credential accepted for this service and request?
- Did it carry the necessary access grant?
- Was any required represented-user context verified?
- Did the applicable action policy permit the operation?
- Did the backend accept the operation given the case's current state?
Error conventions vary. Use the implementation's logs and error details to identify which check failed.
Dome's identity documentation describes agent authentication and verified end-user context; its authorization model describes rules for governed calls. Use the failed check to guide the fix. A policy refusal may require a different response from an invalid credential or missing scope.
See agent authorization for the facts needed to decide an individual action, and non-human identity for identifying software callers.
Explore Dome: Authorization · Docs: Authorization model.