OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents
draft-oauth-ai-agents-on-behalf-of-user-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Thilina | ||
| Last updated | 2025-05-02 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-oauth-ai-agents-on-behalf-of-user-00
Network Working Group T. S. Senarath
Internet-Draft WSO2
Intended status: Informational 2 May 2025
Expires: 3 November 2025
OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents
draft-oauth-ai-agents-on-behalf-of-user-00
Abstract
This specification defines an extension to the OAuth 2.0
Authorization Framework [RFC6749] to enable AI agents to obtain
delegated access tokens to act on behalf of users. It introduces a
new authorization request parameter, requested_agent, and defines a
grant type, urn:ietf:params:oauth:grant-type:agent-
authorization_code, specifically designed to facilitate explicit user
consent for an agent's actions and enable the agent to exchange an
authorization code for a delegated access token using its own
authentication credentials (an agent token). The extension ensures
secure delegation, explicit user consent captured at the
authorization server, and enhanced auditability through specific
token claims that document the delegation path from the user to the
agent acting via a client application.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 November 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Senarath Expires 3 November 2025 [Page 1]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Preconditions . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. High-Level Overview . . . . . . . . . . . . . . . . . . . 4
4.2. Sequence Diagram . . . . . . . . . . . . . . . . . . . . 5
5. Detailed Protocol Steps . . . . . . . . . . . . . . . . . . . 7
5.1. User Authorization Request . . . . . . . . . . . . . . . 7
5.1.1. Parameters . . . . . . . . . . . . . . . . . . . . . 8
5.1.2. Authorization Server Processing . . . . . . . . . . . 8
5.1.3. Authorization Code Response . . . . . . . . . . . . . 8
5.1.4. Error Response . . . . . . . . . . . . . . . . . . . 9
5.2. Delegated Access Token Request . . . . . . . . . . . . . 9
5.2.1. Parameters . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. Authorization Server Processing . . . . . . . . . . . 10
5.2.3. Delegated Access Token Response . . . . . . . . . . . 10
5.2.4. Error Response . . . . . . . . . . . . . . . . . . . 11
6. Delegated Access Token Structure and Claims . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
AI agents are increasingly integrated into systems to perform tasks
on behalf of users. These agents often require access to protected
resources, necessitating a robust and secure authorization mechanism
that accurately reflects the user's intent and the agent's role in
the access request. Standard OAuth 2.0 flows, such as the
Authorization Code Grant [RFC6749] and the Client Credentials Grant
[RFC6749], do not fully address the nuances of agent delegation where
explicit user consent for a specific agent's action is required and
the agent itself acts as a distinct identity in the token exchange
process. While the OAuth 2.0 Token Exchange specification [RFC8693]
provides a mechanism for exchanging tokens, it typically focuses on
Senarath Expires 3 November 2025 [Page 2]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
inter-service communication or impersonation flows initiated server-
side and doesn't inherently provide a mechanism for obtaining
explicit user consent for an agent via the front channel initiated
from the authorization endpoint.
This specification extends OAuth 2.0 to specifically support
scenarios where a user delegates authority to an AI agent. It
leverages the existing Authorization Code Grant flow by introducing
mechanisms at the authorization endpoint to identify the specific
agent for which delegation is sought and by defining a new grant type
for the token endpoint that allows the agent to authenticate itself
while presenting the user-approved authorization code. The resulting
delegated access token explicitly records the identity of the user,
the agent, and the client application involved, facilitating clear
audit trails.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
This specification uses the following terms:
Agent: An autonomous software entity that acts on behalf of a user.
An agent has a distinct identity and authentication credentials
separate from the client application that might host or invoke it.
Agent Token: A security token (e.g., a JWT [RFC7519]) used by an
agent to authenticate itself to the authorization server or
resource servers. The sub claim of an agent token identifies the
agent.
Delegated Access Token: An access token issued by the authorization
server to an agent, granting it permission to access protected
resources on behalf of a specific user. This token explicitly
documents the delegation path.
User: The resource owner who grants consent for an agent to access
their protected resources.
Client: An application that initiates the authorization flow and
facilitates the interaction between the user, agent, and
authorization server. This is the "client" as defined in OAuth
2.0 [RFC6749].
Senarath Expires 3 November 2025 [Page 3]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
Authorization Server: The server that issues access tokens to the
client and agent after successfully authenticating a resource
owner and obtaining authorization.
Resource Server: The server hosting the protected resources, capable
of accepting and validating delegated access tokens. Resource
server can be a model context protocol (MCP) server, another agent
or genaric protected resource.
Authorization Code: A temporary, single-use code issued by the
authorization server to the client's redirect URI after the user
has authenticated and granted consent for a specific agent to act
on their behalf. This code is then provided to the agent.
3. Preconditions
The agent holds a valid agent token, obtained via a separate process,
which is not covered in this document. The agent token is used to
authenticate the agent and authorize it to perform actions on its own
behalf.
4. Protocol Overview
This extension defines a flow where a client application facilitates
user consent for an agent, and the agent then uses this consent along
with its own authentication to obtain a delegated access token.
4.1. High-Level Overview
1. The client application initiates the flow by directing the user's
user-agent to the Authorization Server's authorization endpoint,
including a requested_agent parameter identifying the agent.
2. The Authorization Server authenticates the user and presents a
consent screen detailing the client, the requested agent, and the
scopes. Upon user consent, the Authorization Server issues a
short-lived Authorization Code tied to the user, client, and
agent, and redirects the user-agent back to the client's
redirect_uri.
3. The client receives the Authorization Code (via the user-agent
redirect). The client then typically passes this code to the
agent.
Senarath Expires 3 November 2025 [Page 4]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
4. The agent requests a Delegated Access Token from the
Authorization Server's token endpoint using the new
urn:ietf:params:oauth:grant-type:agent-authorization_code grant
type. This request includes the Authorization Code, the PKCE
code_verifier, and the agent token.
5. The Authorization Server validates the request, including
verifying the Authorization Code, the PKCE code_verifier, and the
Agent Token. It ensures the Agent Token corresponds to the
requested_agent approved by the user.
6. Upon successful validation, the Authorization Server issues a
Delegated Access Token to the agent. This token is typically a
JWT containing claims identifying the user (sub), the client
(azp), and the agent (act claim).
4.2. Sequence Diagram
Senarath Expires 3 November 2025 [Page 5]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
+------------+ +--------+ +--------+ +--------------------+ +----------------+
| User-Agent | | Client | | Agent | | Authorization | | Resource |
| | | | | | | Server | | Server |
+------------+ +--------+ +--------+ +--------------------+ +----------------+
| | | | |
| | (A) Need to act on behalf of user | |
| |<----------------| | |
| | | | |
(B) Open browser with authorization url + code challenge + requested_agent |
|<--------------------| | | |
| | | | |
| (C) Request to authorization endpoint | |
|-------------------------------------------------------------->| |
| | | | |
| (D) User authenticates and consents (show agent + scopes) | |
|<------------------------------------------------------------->| |
| | | | |
| (E) Redirect with Authorization Code | |
|<--------------------------------------------------------------| |
| | | | |
| (F) Authorization Code | | |
|-------------------->| | | |
| | (G) POST /token (code + verifier + agent token) |
| |---------------------------------------->| |
| | | | |
| | (H) Delegated Access Token (JWT) | |
| |<----------------------------------------| |
| | | |
| | (I) Access Resource with Delegated Access Token |
| |------------------------------------------------------------------->|
| | | |(J) JWKS Token validation |
| | | |<-------------------------|
| | | | |
| | (K) Protected Resource Response | |
| |<-------------------------------------------------------------------|
| | | | |
| | (L) Response with Resource Data | |
| |---------------->| | |
The steps in the sequence diagram are as follows:
A. Agent requests to access protected resources on behalf of the
user.
B. Client initiates Authorization Request via user-agent, including
requested_agent and PKCE challenge.
Senarath Expires 3 November 2025 [Page 6]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
C. User-agent is redirected to the Authorization Server's
authorization endpoint.
D. User authenticates and grants consent for the specific agent and
requested scopes at the Authorization Server.
E. Authorization Server issues Authorization Code and redirects
user-agent back to client.
F. Client receives the code.
G. Client requests Delegated Access Token using the
urn:ietf:params:oauth:grant-type:agent-authorization_code grant type,
presenting the code, PKCE verifier, and its Agent Token.
H. Authorization Server validates the request (code, verifier, and
agent token) and issues the Delegated Access Token.
I. Client accesses protected resources using the Delegated Access
Token.
J. Resource Server validates the token (e.g., by verifying the
signature and claims offline).
K. Resource Server processes the request and returns the requested
resource.
L. Agent receives the resource data.
5. Detailed Protocol Steps
5.1. User Authorization Request
The client initiates the flow by directing the user's user-agent to
the authorization server's authorization endpoint. This request is
an extension of the standard Authorization Code Grant request
(Section 4.1.1 of [RFC6749]) and SHOULD include the requested_agent
parameter.
GET /authorize?response_type=code&
client_id=<client_id>&
redirect_uri=<redirect_uri>&
scope=<scope>&
state=<state>&
code_challenge=<code_challenge>&
code_challenge_method=S256&
requested_agent=<agent_id> HTTP/1.1
Senarath Expires 3 November 2025 [Page 7]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
5.1.1. Parameters
requested_agent: REQUIRED. The unique identifier of the agent for
which the client is requesting delegated access on behalf of the
user. This identifier MUST uniquely identify the agent within the
system and MUST be understood by the Authorization Server.
other parameters: The request MUST also include the standard OAuth
2.0 parameters such as response_type, client_id, redirect_uri,
scope, state, and PKCE parameters (code_challenge and
code_challenge_method).
5.1.2. Authorization Server Processing
Upon receiving the authorization request, the Authorization Server
MUST perform the following steps:
1. Validate the request parameters according to the OAuth 2.0
Authorization Code Grant (Section 4.1.1 of [RFC6749]).
2. Validate the requested_agent. The Authorization Server MUST
verify that the provided requested_agent corresponds to a
recognized agent identity. The nature of this verification is
outside the scope of this document but might involve checking an
internal registry of agents.
3. Authroization server MAY Display a consent screen to the User.
This screen SHOULD clearly indicate:
* The name or identity of the client application initiating the
request.
* The identity of the agent (requested_agent) for which
delegation is being requested.
* The specific scopes of access being requested.
If the request is valid and the user grants consent, the
Authorization Server proceeds to issue an Authorization Code. If the
request is invalid, the Authorization Server returns an Error
Response.
5.1.3. Authorization Code Response
If the user grants consent, the Authorization Server issues an
Authorization Code and redirects the user-agent back to the client's
redirect_uri (if provided in the request) or a pre-registered
redirect URI.
Senarath Expires 3 November 2025 [Page 8]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
HTTP/1.1 302 Found
Location: <redirect_uri>?code=<authorization_code>&state=<state>
5.1.3.1. Parameters
Similar to the standard Authorization Code Grant (Section 4.1.2 of
[RFC6749]), the response includes:
code: REQUIRED. The Authorization Code issued by the Authorization
Server. This code is a short-lived, single-use code that the
client will pass to the agent.
state: OPTIONAL. The state parameter passed in the initial request,
if present. This value MUST be included in the redirect URI to
maintain state between the request and callback.
5.1.4. Error Response
If the request fails, the Authorization Server redirects the user-
agent back to the client's redirect_uri with error parameters.
HTTP/1.1 302 Found
Location: <redirect_uri>?error=<error_code>&state=<state>
5.2. Delegated Access Token Request
Upon receiving the Authorization Code, the client then requests a
Delegated Access Token from the Authorization Server's token endpoint
using the urn:ietf:params:oauth:grant-type:agent-authorization_code
grant type.
POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:agent-authorization_code&
client_id=<client_id>&
code=<authorization_code>&
code_verifier=<code_verifier>&
redirect_uri=<redirect_uri>&
agent_token=<agent_token>
5.2.1. Parameters
agent_token: REQUIRED. The agent token used to authenticate the
agent. This token MUST be a valid token issued to the agent and
MUST include the sub claim identifying the agent.
Senarath Expires 3 November 2025 [Page 9]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
other parameters: The request MUST also include the standard OAuth
2.0 parameters such as client_id, code, code_verifier, and
redirect_uri.
5.2.2. Authorization Server Processing
Upon receiving the token request, the Authorization Server MUST
perform the following steps:
1. Validate the request parameters according to the OAuth 2.0 Token
Endpoint (Section 4.1.3 of [RFC6749]).
2. The Authorization Server MUST verify that the agent token is
valid, not expired.
3. Verify that the authenticated agent identity (obtained from the
Agent Token's sub claim) matches the requested_agent value that
the user consented to during the initial Authorization Request
and which is associated with the code.
If all validations pass, the Authorization Server issues a Delegated
Access Token. If any validation fails, the Authorization Server
returns an Error Response.
5.2.3. Delegated Access Token Response
If the Token Request is valid, the Authorization Server issues a
Delegated Access Token to the agent. This token SHOULD be a JSON Web
Token (JWT) [RFC7519] to include claims that document the delegation.
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "<delegated_access_token>",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "<granted_scope>"
}
5.2.3.1. Parameters
Similar to the standard Authorization Code Grant (Section 4.1.4 of
[RFC6749])
Senarath Expires 3 November 2025 [Page 10]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
5.2.4. Error Response
If the request is invalid, the Authorization Server returns an error
response with an HTTP 400 (Bad Request) status code.
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error": "invalid_grant"
}
6. Delegated Access Token Structure and Claims
The Delegated Access Token SHOULD be a JWT Profile for OAuth 2.0
Access Tokens [RFC9068]. It SHOULD carry claims that explicitly
document the delegation chain.
In addition to standard JWT claims (e.g., iss, aud, exp, iat, jti), a
Delegated Access Token issued via this flow MUST contain the
following claims:
act: REQUIRED. Actor - represents the party acting on behalf of the
subject (Section 4.1 of [RFC8693]). In a Delegated Access Token
issued via this flow, this claim MUST contain a JSON object with
at least the following member: * sub: REQUIRED. The unique
identifier of the Agent that is acting on behalf of the user. *
Additional members MAY be included in the act claim.
Example Decoded JWT Payload:
{
"iss": "https://authorization-server.com/oauth2/token",
"aud": "resource_server",
"sub": "user-456",
"azp": "s6BhdRkqt3",
"scope": "read:email write:calendar",
"exp": 1746009896,
"iat": 1746006296,
"jti": "unique-token-id",
"act": {
"sub": "agent-finance-v1",
"aut": "APPLICATION_AGENT"
},
"aut": "APPLICATION_USER"
}
Senarath Expires 3 November 2025 [Page 11]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
Resource Servers consuming this token can inspect the sub claim to
identify the user and the act.sub claim to identify the specific
agent that is performing the action. This provides a clear and
auditable delegation path.
7. Security Considerations
Agent Authentication: The security of this flow relies heavily on
the Authorization Server's ability to securely authenticate the
agent during the Token Request using the Agent Token. The method
by which agents obtain and secure their Agent Tokens is critical
and outside the scope of this specification but MUST be
implemented securely.
Proof Key for Code Exchange (PKCE): PKCE [RFC7636] is REQUIRED to
prevent authorization code interception attacks, especially
relevant if the client (and thus the agent receiving the code) is
a public client or runs in an environment where the redirect URI
cannot be strictly protected.
Single-Use and Short-Lived Authorization Codes: Authorization Codes
MUST be single-use and have a short expiration time to minimize
the window for compromise.
Binding Code to Agent and Client: The Authorization Server MUST bind
the Authorization Code to the specific user, client (client_id),
and requested agent (requested_agent) during issuance and verify
this binding during the Token Request.
Clear User Consent: The consent screen presented to the user SHOULD
clearly identify the agent and the requested scopes to ensure the
user understands exactly what authority they are delegating and to
whom.
Auditability: The claims in the Delegated Access Token (sub, act)
provide essential information for auditing actions performed using
the token, clearly showing who (user) authorized the action, which
application (client) facilitated it, and which entity (agent)
performed it.
Token Revocation: Mechanisms for revoking Delegated Access Tokens
are essential. Revocation could be triggered by: * The user
revoking consent. * The agent's Agent Token being revoked. * The
user's account being disabled. * The agent's identity being
disabled. * The client application being disabled.
Resource Servers or Authorization Servers MUST have mechanisms to
check the revocation status of tokens.
Senarath Expires 3 November 2025 [Page 12]
Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User A May 2025
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/rfc/rfc7636>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/rfc/rfc9068>.
8.2. Informative References
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/rfc/rfc7662>.
Author's Address
Thilina Shashimal Senarath
WSO2
Email: thilinasenarath97@gmail.com
Senarath Expires 3 November 2025 [Page 13]