



Web Authorization Protocol                                    A. Parecki
Internet-Draft                                                      Okta
Intended status: Informational                               B. Campbell
Expires: 26 September 2026                                 Ping Identity
                                                                  D. Liu
                                                           Alibaba Group
                                                           25 March 2026


              JWT Authorization Grant Interaction Response
         draft-parecki-oauth-jwt-grant-interaction-response-00

Abstract

   This document defines an extension to the JWT Authorization Grant
   [RFC7523] that enables an authorization server to indicate that user
   interaction is required in order to complete an authorization
   request.  Instead of returning an access token or an error, the
   authorization server returns a URI that the client launches where the
   user can interact with the authorization server, along with a polling
   interval.  The client can then poll for the access token or wait for
   a redirect before retrying the original request.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://aaronpk.github.io/draft-parecki-oauth-jwt-grant-interaction-
   response/draft-parecki-oauth-jwt-grant-interaction-response.html.
   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-parecki-oauth-jwt-grant-
   interaction-response/.

   Discussion of this document takes place on the Web Authorization
   Protocol Working Group mailing list (mailto:oauth@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/oauth/.
   Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.

   Source for this draft and an issue tracker can be found at
   https://github.com/aaronpk/draft-parecki-oauth-jwt-grant-interaction-
   response.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.




Parecki, et al.         Expires 26 September 2026               [Page 1]

Internet-Draft                   JAG-IR                       March 2026


   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Token Request . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Token Endpoint Responses  . . . . . . . . . . . . . . . . . .   4
     4.1.  Interaction Required Response . . . . . . . . . . . . . .   5
     4.2.  Interaction Pending Response  . . . . . . . . . . . . . .   5
     4.3.  Handling the Interaction Response . . . . . . . . . . . .   6
   5.  Authorization Server Behavior . . . . . . . . . . . . . . . .   6
   6.  Complete Flow Diagram . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     7.1.  Interaction URI Security  . . . . . . . . . . . . . . . .   9
     7.2.  Redirect URI Validation . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Appendix . . . . . . . . . . . . . . . . . . . . . .  10
     A.1.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .  10
       A.1.1.  AI Agent with Browser Access  . . . . . . . . . . . .  10
       A.1.2.  High-Risk Transaction Approval  . . . . . . . . . . .  11



Parecki, et al.         Expires 26 September 2026               [Page 2]

Internet-Draft                   JAG-IR                       March 2026


       A.1.3.  Regulatory Compliance . . . . . . . . . . . . . . . .  11
     A.2.  Example Sequence  . . . . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

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.









Parecki, et al.         Expires 26 September 2026               [Page 3]

Internet-Draft                   JAG-IR                       March 2026


   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.







Parecki, et al.         Expires 26 September 2026               [Page 4]

Internet-Draft                   JAG-IR                       March 2026


4.1.  Interaction Required Response

   When the authorization server receives a valid JWT Authorization
   Grant request but determines that user interaction is required before
   an access token can be issued, it responds with an OAuth error
   response as defined in Section 3.2.4 of [OAUTH-2.1] as defined below:

   error  REQUIRED. interaction_required.  Indicates that user
      interaction is required, and the following additional parameters
      are defined in the response.

   interaction_uri  REQUIRED.  The URI that the client MUST launch
      (typically in the user's browser) to allow the user to interact
      with the authorization server.  The URI MUST use the "https"
      scheme.

   interval  OPTIONAL.  The minimum number of seconds that the client
      SHOULD wait between polling requests to the token endpoint.  If no
      value is provided, the default is 5 seconds.

   expires_in  OPTIONAL.  The number of seconds after which the
      interaction URI and the associated authorization session will
      expire.

   The response MUST include a Content-Type header field set to
   application/json.

   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
   }

4.2.  Interaction Pending Response

   When user interaction is pending, and the client makes a subsequent
   token endpoint request, the authorization server responds with an
   OAuth error response as defined in Section 3.2.4 of [OAUTH-2.1] with
   one of the values defined below:

   interaction_pending  The authorization request is still pending as
      the end user hasn't yet completed the user-interaction steps.  The
      client SHOULD repeat the access token request to the token
      endpoint.  Before each new request, the client MUST wait at least



Parecki, et al.         Expires 26 September 2026               [Page 5]

Internet-Draft                   JAG-IR                       March 2026


      the number of seconds specified by the interval parameter defined
      in Section 4.1, or 5 seconds if none was provided, and respect any
      increase in the polling interval required by the "slow_down"
      error.

   slow_down  A variant of authorization_pending, the authorization
      request is still pending and polling should continue, but the
      interval MUST be increased by 5 seconds for this and all
      subsequent requests.

   access_denied  The authorization request was denied.

4.3.  Handling the Interaction Response

   Upon receiving an interaction response as defined in Section 4, the
   client MUST:

   1.  Launch or redirect a browser to the interaction_uri.

   2.  Wait for the interaction to complete using one or both of the
       following mechanisms:

       *  *Polling:* The client re-sends its original token request
          (including the same JWT assertion and parameters) to the token
          endpoint, waiting at least interval seconds between each
          request.  The authorization server will continue to return the
          interaction response until the user interaction is complete,
          at which point it will return an access token response or an
          error response as defined in Section 3.2 of [OAUTH-2.1].

       *  *Redirect notification:* If the client included a redirect_uri
          in its original request, it MAY wait for the authorization
          server to redirect the user's browser to that URI.  Upon
          receiving the redirect, the client SHOULD immediately retry
          its original token request.  No authorization code or other
          parameters are included in the redirect; the redirect serves
          solely as a signal that the interaction is complete.

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.






Parecki, et al.         Expires 26 September 2026               [Page 6]

Internet-Draft                   JAG-IR                       March 2026


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























Parecki, et al.         Expires 26 September 2026               [Page 7]

Internet-Draft                   JAG-IR                       March 2026


    +--------+     +--------+     +--------+     +----------+
    |  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  |               |
        |               |<------------------------------|





Parecki, et al.         Expires 26 September 2026               [Page 8]

Internet-Draft                   JAG-IR                       March 2026


   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

7.1.  Interaction URI Security

   The interaction_uri MUST be an "https" URI.  The URI SHOULD contain
   sufficient entropy to prevent guessing or brute-force attacks.  The
   authorization server SHOULD bind the interaction session to the
   client identity from the original token request.

7.2.  Redirect URI Validation

   If the client provides a redirect_uri, the authorization server MUST
   validate it against the client's registered redirect URIs, consistent
   with Section 2.3.1 of [OAUTH-2.1].

8.  IANA Considerations

   TBD

9.  References



Parecki, et al.         Expires 26 September 2026               [Page 9]

Internet-Draft                   JAG-IR                       March 2026


9.1.  Normative References

   [OAUTH-2.1]
              Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
              Authorization Framework", Work in Progress, Internet-
              Draft, draft-ietf-oauth-v2-1-15, 2 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              v2-1-15>.

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

   [RFC7523]  Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
              (JWT) Profile for OAuth 2.0 Client Authentication and
              Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
              2015, <https://www.rfc-editor.org/rfc/rfc7523>.

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

9.2.  Informative References

   [I-D.draft-ietf-oauth-identity-assertion-authz-grant]
              Parecki, A., McGuinness, K., and B. Campbell, "Identity
              Assertion JWT Authorization Grant", Work in Progress,
              Internet-Draft, draft-ietf-oauth-identity-assertion-authz-
              grant-02, 2 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              identity-assertion-authz-grant-02>.

   [RFC8628]  Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
              "OAuth 2.0 Device Authorization Grant", RFC 8628,
              DOI 10.17487/RFC8628, August 2019,
              <https://www.rfc-editor.org/rfc/rfc8628>.

Appendix A.  Appendix

A.1.  Use Cases

A.1.1.  AI Agent with Browser Access

   An AI agent needs to perform operations on behalf of a user at a
   third-party service.  The agent can redirect the user's browser to a
   consent page, then receive a callback when consent is complete.




Parecki, et al.         Expires 26 September 2026              [Page 10]

Internet-Draft                   JAG-IR                       March 2026


   This differs from the Device Authorization Grant (RFC 8628) in that
   no polling is required - the redirect/callback model provides lower
   latency.

A.1.2.  High-Risk Transaction Approval

   A client presents a valid JWT assertion but requests authorization
   for a high-value financial transaction.  The AS determines that step-
   up consent is required before issuing the token.

A.1.3.  Regulatory Compliance

   A client requests access to sensitive data.  Regulatory requirements
   mandate that explicit, auditable consent must be obtained and
   recorded before access is granted.

A.2.  Example Sequence

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Aaron Parecki
   Okta
   Email: aaron@parecki.com


   Brian Campbell
   Ping Identity
   Email: bcampbell@pingidentity.com


   Dapeng Liu
   Alibaba Group
   Email: max.ldp@alibaba-inc.com














Parecki, et al.         Expires 26 September 2026              [Page 11]
