This field-guide entry has not been reviewed in its new form yet. The studies are summarized as published; no review date is implied.
Key findings #
In the Agentic Identity Broker, a user grants an agent access to a service with a chosen permission set and an optional expiry, and can revoke that grant at any time.
Under RFC 7009, revoking a refresh token should also invalidate all access tokens based on the same authorization grant if the authorization server supports access token revocation.
Immediate revocation of self-contained access tokens needs backend coordination that RFC 7009 calls non-standardized, and short-lived access tokens limit how long a revoked token stays in use.
Refresh tokens must be bound to the scope and resource servers the resource owner consented to.
Evidence #
| Study | Year | Sample | Method | Finding |
|---|---|---|---|---|
| OAuth 2.0 Token Revocation (RFC 7009)IETF | 2013 | n/a | Specification | Defines a revocation endpoint and how revoking one token can revoke related tokens and the grant. |
| Best Current Practice for OAuth 2.0 Security (RFC 9700)IETF | 2025 | n/a | Specification | Binds refresh tokens to the consented scope and resources and lets them expire after inactivity. |
| Resource Indicators for OAuth 2.0 (RFC 8707)IETF | 2020 | n/a | Specification | Lets the authorization server tell the user which resources a client will access on their behalf. |
| OAuth 2.0 Token Exchange (RFC 8693)IETF | 2020 | n/a | Specification | Leaves revocation of tokens issued by an exchange to the implementation. |
| Model Context Protocol: Authorization (revision 2026-07-28)Model Context Protocol | 2026 | n/a | Specification | Asks clients to request minimal scopes first and add scopes through step-up authorization. |
| What I Learned Building an Identity Broker With Coding Agentsthis site | 2026 | n/a | Field report | Describes per-agent grants with chosen permissions, optional expiry and revocation at any time. |
What to do #
For engineers #
Model the grant as a record of its own that names the person, the agent, the service, the permissions and the expiry, and issue every token from it. Check that record whenever you issue or exchange a token, so a revocation takes effect at the next tool call. Expiring tokens are the fallback for tokens you can’t recall.
Wire revocation through every layer you control. Call the RFC 7009 revocation endpoint where the provider offers one, and don’t stop at the first token. RFC 8693 says tokens issued by a token exchange aren’t linked to their input token, so revoking one doesn’t reach the other unless you build that.
Ask for the least access first. The MCP authorization specification describes this as step-up authorization: request minimal scopes and add more when a server asks for them.
For product and UX #
Show each grant with the agent, the service, the permissions and the expiry in plain words, and put the revoke action next to it. Default to an expiry instead of open-ended access. When an agent needs more access, ask at that moment for that specific permission.
How it works #
Granting access in OAuth starts with an authorization request. The client names the access it wants in scope and, with RFC 8707, the resources in resource. RFC 8707 notes that the authorization server can use those resource values to inform the user about the resources the client will access on their behalf. The consent screen can then name the service, not only a list of scopes.
In the Agentic Identity Broker, which Magnus Jungsbluth and I built, a user grants an agent access to a service with a chosen permission set and an optional expiry. The broker keeps both the user and the agent in every authorization decision. I describe the design in the retrospective, and my AppSec essay argues for narrow, time-limited permissions that the user can revoke at any moment.
Revoking access in OAuth uses the revocation endpoint from RFC 7009. A client sends the token it wants revoked, and the server invalidates it and, depending on policy, related tokens and the grant itself. RFC 7009 gives 2 reasons this matters for people: it stops a grant from staying valid without the user’s knowledge, and revoked grants disappear from any list of grants the authorization server shows the user. The server answers with HTTP 200 even for an invalid token. A 503 means the client must assume the token still exists.
Self-contained tokens make revocation harder. A resource server can check a self-contained token, such as a JSON Web Token (JWT), without asking the authorization server, so it won’t learn about a revocation on its own. RFC 7009 names short-lived access tokens with refresh tokens as one alternative. RFC 9700 adds that refresh tokens must stay bound to the consented scope and resources, should expire after a period of inactivity, and may be revoked on security events such as a password change or logout.