JWT Authorization Grant Interaction Response

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 26 September 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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

The JWT Authorization Grant [RFC7523] and Identity Assertion Grant [I-D.draft-ietf-oauth-identity-assertion-authz-grant] enable clients to obtain access tokens without direct user approval at the authorization server. However, certain scenarios may require explicit user consent, even if the initial authorization can be obtained without user interaction:¶

• AI Agent Authorization: Autonomous agents acting on behalf of users need explicit consent for specific operations, not just identity verification.¶

• High-Risk Operations: Financial transactions, data deletion, or other sensitive operations may require step-up consent.¶

• Compliance Requirements: Regulatory frameworks (GDPR, etc.) may require explicit, verifiable consent for certain activities.¶

• Policy-Based Authorization: Fine-grained authorization policies (e.g., "allow purchases up to $50") require user understanding and approval.¶

Currently, if user interaction is needed, the authorization server has no standardized way to communicate this to the client within the JWT Authorization Grant flow. The client would typically receive an error response and would need to fall back to a traditional redirect-based OAuth flow, negating the benefits of using the JWT Authorization Grant.¶

This specification defines an interaction response that the authorization server can return in place of an access token. The interaction response contains a URI that the client opens (typically in a browser) so the user can interact with the authorization server. It also includes a polling interval, similar to the Device Authorization Grant [RFC8628], indicating how frequently the client should re-request the token.¶

The client's token request MAY include a redirect_uri parameter. If provided, the authorization server redirects the user's browser to this URI after the interaction is complete. Unlike the Authorization Code flow, no authorization code is included in the redirect. The redirect serves only as a signal to the client that the user interaction has completed. The client then retries its original JWT Authorization Grant request to obtain the access token.¶

2. Conventions and Definitions

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.¶

3. Token Request

The client makes a token request to the authorization server's token endpoint as defined in [RFC7523], with the addition of an OPTIONAL redirect_uri parameter.¶

redirect_uri

OPTIONAL. The URI to which the authorization server will redirect the user's browser after the interaction is complete. The redirect URI MUST be previously registered with the authorization server or otherwise validated per authorization server policy.¶

An example request:¶

POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJhbGciOi...
&redirect_uri=https://client.example.org/callback

4. Token Endpoint Responses

In addition to the error codes defined in Section 3.2.4 of [OAUTH-2.1], the following error codes are specified for use with the JWT Authorization Grant Interaction Response in token endpoint responses.¶

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "interaction_required",
  "interaction_uri": "https://auth.example.com/interact/abc123",
  "interval": 5,
  "expires_in": 600
}

5. Authorization Server Behavior

When the authorization server receives a JWT Authorization Grant request and determines that user interaction is required, it MUST:¶

1. Generate a unique interaction_uri for the user interaction session.¶

2. Associate the interaction session with the original token request parameters (including the JWT assertion claims, requested scope, any redirect_uri provided by the client, and parameters from any extensions).¶

3. Return the interaction response as defined in Section 4.1.¶

While the user interaction is pending, subsequent token requests from the client with the same JWT assertion SHOULD return the interaction response or an interaction_pending error.¶

After the user has completed the required interaction, the authorization server MUST:¶

1. If a redirect_uri was provided, redirect the user's browser to that URI. The redirect MUST NOT include an authorization code or access token.¶

2. On the next token request from the client with the same JWT assertion, return an access token response as defined in Section 3.2.3 of [OAUTH-2.1] or an error response as defined in Section 3.2.4 of [OAUTH-2.1].¶

6. Complete Flow Diagram

The diagram below is a non-normative example of using this specification in conjunction with the [[I-D.draft-ietf-oauth-identity-assertion-authz-grant]].¶

 +--------+     +--------+     +--------+     +----------+
 |  User  |     | Client |     |  IdP   |     |   AS     |
 |        |     | (Agent)|     |        |     |          |
 +--------+     +--------+     +--------+     +----------+
     |               |               |               |
 (1) | Authenticate  |               |               |
     |-------------->|               |               |
     |               |               |               |
 (2) |               | Token Exchange|               |
     |               | (get ID-JAG)  |               |
     |               |-------------->|               |
     |               |               |               |
 (3) |               | ID-JAG        |               |
     |               |<--------------|               |
     |               |               |               |
 (4) |               | JWT Grant     |               |
     |               | Request       |               |
     |               |------------------------------>|
     |               |               |               |
 (5) |               |               |    Validate   |
     |               |               |    & Decide:  |
     |               |               |    Interaction|
     |               |               |    Required   |
     |               |               |               |
 (6) |               | interaction_required          |
     |               | + interaction_uri             |
     |               |<------------------------------|
     |               |               |               |
 (7) |<--------------| Redirect to   |               |
     |               | interaction   |               |
     |               | page          |               |
     |               |               |               |
 (8) | Review &      |               |               |
     | Approve       |               |               |
     |---------------------------------------------->|
     |               |               |               |
 (9) |               |<------------------------------|
     |               |   Redirect    |               |
     |               | (via browser) |               |
     |               |               |               |
(10) |               | Retry JWT     |               |
     |               | Grant Request |               |
     |               |------------------------------>|
     |               |               |               |
(11) |               | Access Token  |               |
     |               |<------------------------------|

1. User authenticates to the Client through the IdP, typically via OpenID Connect¶

2. The Client exchanges the previously-obtained ID Token for an ID-JAG¶

3. The IdP validates the request against the configured policy and returns an ID-JAG¶

4. The Client presents the ID-JAG to the AS in a JWT Authorization Request¶

5. The AS validates the ID-JAG, and determines that further interaction is required¶

6. The AS returns the interaction_required response¶

7. The client redirects the browser to the specified page¶

8. The user visits the URL and confirms the request¶

9. The AS redirects to the Client's redirect_uri¶

10. The Client retries the JWT Authorization Request¶

11. The AS validates the request, sees the user has confirmed, and issues an access token¶

7. Security Considerations

8. IANA Considerations

TBD¶

9. References

Appendix A. Appendix

Acknowledgments

TODO acknowledge.¶

Authors' Addresses