TBD J. Kahrer Internet-Draft Curity Intended status: Standards Track 19 May 2026 Expires: 20 November 2026 OAuth Client Challenge Protocol draft-kahrer-oauth-client-challenge-protocol-00 Abstract This document extends the OAuth 2.0 token endpoint error response (RFC 6749) with a new error code that indicates to the client that it must provide additional input for the authorization server to authorize it and accept its request. This mechanism enables just-in-time authorization flows in which the authorization server dynamically challenges the client during a request and the client tries to satisfy it. For example, the authorization server can ask the client mid-flow to provide an assertion, a verifiable presentation, or other proof-of-possession material. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kahrer-oauth-client-challenge- protocol/. Source for this draft and an issue tracker can be found at https://github.com/curityio/ietf-draft-oauth-client-challenge- protocol. 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/. Kahrer Expires 20 November 2026 [Page 1] Internet-Draft OAuth Client Challenge Protocol May 2026 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 20 November 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 1.1. Motivation and Use Cases . . . . . . . . . . . . . . . . 3 1.1.1. Just-in-Time Authorization . . . . . . . . . . . . . 3 1.1.2. Client Authentication Step-Up . . . . . . . . . . . . 4 1.1.3. Continuos Authorization . . . . . . . . . . . . . . . 4 1.2. Comparison with OAuth 2.0 First-Party Applications . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Insufficient Client Authorization Response . . . . . . . . . 5 5. The authorization_requirement Object . . . . . . . . . . . . 7 6. Providing Authorization Requirement . . . . . . . . . . . . . 7 7. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8.1. Sender-Constrained Tokens . . . . . . . . . . . . . . . . 8 8.2. Challenge Session . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9.1. OAuth Parameters Registration . . . . . . . . . . . . . . 9 9.2. OAuth Error Codes . . . . . . . . . . . . . . . . . . . . 9 9.3. OAuth Client Metadata Registration . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Example with Authorization Details . . . . . . . . . 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Document History . . . . . . . . . . . . . . . . . . . . . . . . 13 Kahrer Expires 20 November 2026 [Page 2] Internet-Draft OAuth Client Challenge Protocol May 2026 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The OAuth 2.0 Authorization Framework [RFC6749] assumes that a single grant signaled through the grant_type parameter is sufficient for the authorization server to authorize the client. It does not define how the authorization server signals to the client to provide additional input for it to make a decision - like an additional grant from the Resource Owner or an attestation artifact to prove the client's provenance. Real-world deployments increasingly require the authorization server to apply dynamic, contextual authorization policies — for example: * Demanding a freshly signed client attestation when risk signals indicate an elevated threat level. * Requiring the client to prove its mandate before a high-value token is issued. This document introduces a way for the authorization server to start a challenge session where it defines requirements that it expects from the client. It extends the OAuth 2.0 Authorization Framework by introducing the following parameters: 1. A new error code insufficient_client_authorization for token error responses that the authorization server returns when it cannot proceed without additional client-supplied material. 2. A companion response parameter authorization_requirement — a typed JSON object that describes what the authorization server requires. 3. Processing rules for both parties, including the requirement to return unauthorized_client when subsequently provided input fails validation. 1.1. Motivation and Use Cases 1.1.1. Just-in-Time Authorization Whether and in which form an authorization server may return an access token to a client depends not only on the presented grant and requested access but also on the capabilities of the client, e.g., whether it is a public client or a confidential client, whether it is a first-party client or a third-party client. Just-in-time authorization means that the authorization server can, dynamically Kahrer Expires 20 November 2026 [Page 3] Internet-Draft OAuth Client Challenge Protocol May 2026 and on demand, evaluate necessary data from different sources to understand the context of a request and use that information to accept or deny a token request from a client. In a just-in-time flow, the authorization server defers its final authorization decision, challenges the client for supplemental proof material, and only then either grants or denies the request. 1.1.2. Client Authentication Step-Up An authorization server may accept client authentication for low- assurance tokens but require an attestation for tokens granting elevated privileges (see ([I-D.ietf-oauth-attestation-based-client-auth])). The insufficient_client_authorization mechanism allows the authorization server to escalate the authentication requirement without the client needing to speculatively include high-assurance credentials on every request. It allows, for example, public clients to increase their trust profile. 1.1.3. Continuos Authorization The security state of a system can change at any time. Systems may communicate via signals about certain security-relevant events that they observed for other systems to adopt. In such an environment the authorization server may receive signals that constitute the need for additional input for authorization to e.g., mitigate attacks and prevent misuse. 1.2. Comparison with OAuth 2.0 First-Party Applications OAuth 2.0 First-Party Applications [I-D.ietf-oauth-first-party-apps] defines an API for user authentication where the authorization server challenges the OAuth 2.0 client to provide data from the user. The proposed API is similar to the mechanism defined in this document. However, there is a subtle difference: OAuth 2.0 First-Party Applications defines a new error code for the client to provide more data from the end-user (Resource Owner). Its main purpose is to enable clients to control the user experience. For that it makes two important assumptions: * The client can interact with an end-user. * The client is trusted to handle sensitive data like the end-user's credentials, i.e., the client is a first-party application. Kahrer Expires 20 November 2026 [Page 4] Internet-Draft OAuth Client Challenge Protocol May 2026 The extension in this document is different because it assumes that the client can satisfy the challenge from the Authorization Requirement itself. It is applicable for both first- and third-party use cases where the authorization server challenges the client to provide additional input for the authorization grant. The client does not have to handle end-user credentials. What's more, it does not require an additional endpoint but extends the token response. 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. Terminology This document uses the terms "access token", "authorization server", "client", "client authentication", "token response", "token request" and "token endpoint" as defined by the OAuth 2.0 Authorization Framework [RFC6749], unless otherwise specified by this document. In addition, the document uses the following terms: *Insufficient Client Authorization Response*: A token error response from the OAuth 2.0 token endpoint that indicates to the client that the authorization server requires additional input for it to authorize the client. *Authorization Requirement*: A typed JSON object returned by the authorization server in an Insufficient Client Authorization Response that specifies the additional material the client must supply. *Challenge Session*: A string managed by the authorization server that serves as the nonce in the challenge-response pattern. It associates an Insufficient Client Authorization Response with the subsequent request that satisfies it. 4. Insufficient Client Authorization Response This document registers the error code insufficient_client_authorization for use in OAuth 2.0 token endpoint error responses as defined in Section 5.2 of [RFC6749]. The following content applies to the Insufficient Client Authorization Response. Kahrer Expires 20 November 2026 [Page 5] Internet-Draft OAuth Client Challenge Protocol May 2026 error: REQUIRED. The error parameter MUST be insufficient_client_authorization. authorization_requirement: REQUIRED. The authorization_requirement parameter is a typed JSON object as defined in Section 5. challenge_session: REQUIRED. An opaque identifier generated by the authorization server that binds this authorization challenge to the follow-up request. The client MUST include this value in the subsequent request to the authorization server if it receives one along with the insufficient_client_authorization error response. expires_in: OPTIONAL. A JSON number that defines the number of seconds from the time of the Insufficient Client Authorization Response until the challenge_session expires. The client MUST NOT submit a response after this time. The authorization server MUST comply with Section 5.2 of [RFC6749]. The authorization server SHOULD respond with HTTP status code 403 (Forbidden). It MAY include other parameters in the response. The client MUST ignore any parameters it does not understand. If the client does not understand or cannot satisfy the Authorization Requirement, it MUST treat the Insufficient Client Authorization Response as if the authorization server returned an unauthorized_client error. The Insufficient Client Authorization Response indicates the following: 1. The authorization server has determined that it cannot yet authorize the client or issue an access token. 2. The condition is resolvable: the authorization server knows what additional input would allow it to proceed. 3. The authorization server wishes to challenge the client to supply that input. The following represents a non-normative example of an Insufficient Client Authorization Response. Kahrer Expires 20 November 2026 [Page 6] Internet-Draft OAuth Client Challenge Protocol May 2026 HTTP/1.1 403 Forbidden Content-Type: application/json Cache-Control: no-store { "error": "insufficient_client_authorization", "authorization_requirement": { "type": "verifiable_presentation", "challenge_session": "7f3d9e2a-4c1b-4f8e-b5a0-1e6c8d2f0a9b", "presentation_definition": { ... } } } 5. The authorization_requirement Object The authorization_requirement parameter holds a JSON object that indicates what type of input the authorization server requires for the client to satisfy the insufficient client authorization. The following member is defined for all authorization_requirement types: type: REQUIRED. An absolute URI or a string identifying the authorization requirement type. The value determines the semantics of other members in the object. 6. Providing Authorization Requirement Each profile of this document that specifies a type of Authorization Requirement also MUST define how the client can fulfill the challenge and provide the required input to the authorization server. If the client does not understand the type of the authorization_requirement of an Insufficient Client Authorization Response or if it cannot satisfy the requirement, the client MUST treat the Insufficient Client Authorization Response as if the authorization server returned an unauthorized_client error as defined in Section 5.2 in [RFC6749], see also Section 4. The client MUST include the challenge_session parameter with the same value as it received in the Insufficient Client Authorization Response in its subsequent request and attempt to resolve the challenge. Kahrer Expires 20 November 2026 [Page 7] Internet-Draft OAuth Client Challenge Protocol May 2026 Some extensions to OAuth 2.0, notably Pushed Authorization Requests [RFC9126], make use of the token endpoint response outside a token endpoint request. A profile that defines an Authorization Requirement type SHOULD define mechanisms to fulfill the requirements that are applicable to authorization and token requests alike. If the authorization server deems the supplied input from the client in response to an Authorization Requirement challenge as invalid and if there is no other way for the client to resolve the insufficient_authorization error, the authorization server MUST respond with an unauthorized_client error. 7. Client Metadata Clients that communicate their client metadata, for example via dynamic client registration [RFC7591] or client ID metadata document [I-D.ietf-oauth-client-id-metadata-document] can signal support for this specification. To do so, they MUST include the following property in their client metadata: insufficient_client_authorization_supported: OPTIONAL. JSON boolean value specifying whether the client supports this specification. This enables authorization servers to apply this specification without breaking integrations. 8. Security Considerations 8.1. Sender-Constrained Tokens The authorization server SHOULD issue sender-constrained tokens as a result of a successfully resolved client authorization challenge. In this way, the authorization server can mitigate the risk of token theft and replay. The idea is that the authorization server binds the token to a public key that the client controls. For the token to be valid, the client MUST provide a proof-of-possession that satisfies that key binding. The exact methods on how the authorization server binds the token to the client's key and how the client provides a proof-of-possession are out of scope of this document. Demonstrating Proof-of-Possession (DPoP) [RFC9449] and certificate-bound access tokens [RFC8705] are two examples, and there may be others. Kahrer Expires 20 November 2026 [Page 8] Internet-Draft OAuth Client Challenge Protocol May 2026 8.2. Challenge Session The challenge_session parameter associates a Insufficient Client Authorization Response with follow-up resolution attempts. To mitigate session hijacking and replay, the authorization server SHOULD bind the challenge_session to the device requesting tokens, for example via DPoP. Similar to sender-constrained tokens, the binding prevents other devices from replaying a captured challenge_session and thus prevents other devices from taking over sessions (session hijacking). 9. IANA Considerations 9.1. OAuth Parameters Registration This document defines the following values for the IANA "OAuth Parameters" registry of [IANA.oauth-parameters] established by [RFC6749]. *Parameter Name*: challenge_session *Parameter Usage Location*: token response, token request *Change Controller*: IETF *Specification Document*: Section 4 of [draft-kahrer-oauth-client- challenge-protocol-00] 9.2. OAuth Error Codes This document defines the following values for the IANA "OAuth Extensions Error" registry of [IANA.oauth-parameters]. *Error Name*: insufficient_client_authorization *Error Usage Location*: token endpoint *Related Protocol Extension*: n/a *Change Controller*: IETF *Specification Document*: Section 4 of [draft-kahrer-oauth-client- challenge-protocol-00] Kahrer Expires 20 November 2026 [Page 9] Internet-Draft OAuth Client Challenge Protocol May 2026 9.3. OAuth Client Metadata Registration This document defines the following values for the IANA "OAuth Dynamic Client Registration Metadata" registry of [IANA.oauth-parameters] established by [RFC7591]. *Client Metadata Name*: insufficient_client_authorization_supported *Client Metadata Description*: JSON boolean value that specifies whether the OAuth client supports insufficient client authorization error in token error responses. *Change Controller*: IESG *Specification Document*: Section 7 of [draft-kahrer-oauth-client- challenge-protocol-00] 10. References 10.1. Normative References [IANA.oauth-parameters] IANA, "OAuth Parameters", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [I-D.ietf-oauth-attestation-based-client-auth] Looker, T., Bastian, P., and C. Bormann, "OAuth 2.0 Attestation-Based Client Authentication", Work in Kahrer Expires 20 November 2026 [Page 10] Internet-Draft OAuth Client Challenge Protocol May 2026 Progress, Internet-Draft, draft-ietf-oauth-attestation- based-client-auth-08, 2 March 2026, . [I-D.ietf-oauth-client-id-metadata-document] Parecki, A. and E. Smith, "OAuth Client ID Metadata Document", Work in Progress, Internet-Draft, draft-ietf- oauth-client-id-metadata-document-01, 1 March 2026, . [I-D.ietf-oauth-first-party-apps] Parecki, A., Fletcher, G., and P. Kasselman, "OAuth 2.0 for First-Party Applications", Work in Progress, Internet- Draft, draft-ietf-oauth-first-party-apps-03, 27 February 2026, . [Mastercard.VI] Group, V. I. W., "Verifiable Intent (VI) — Specification Overview", February 2026, . [OpenID.Native-SSO] Fletcher, G., "OpenID Connect Native SSO for Mobile Apps", November 2022, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . Kahrer Expires 20 November 2026 [Page 11] Internet-Draft OAuth Client Challenge Protocol May 2026 [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . Appendix A. Example with Authorization Details The following is an example that illustrates a token request using authorization_details as defined in [RFC9396]. The authorization details indicate that the client aims to operate in an open banking ecosystem that has certain requirements. POST /token HTTP/1.1 Host: authorization-server.example Content-Type: application/x-www-form-urlencoded OAuth-Client-Attestation: eyJ0eXAiOiJvYX... DPoP: eyJ0eXAiOiJkcG9... grant_type=client_credentials& resource=https://api.openbanking.example& authorization_details=%5B%7B%22type%22%3A%22payment_initiation%22%2C%22actions%22%3A%5B%22initiate%22%2C%22status%22%2C%22cancel%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fapi.openbanking.example%2Fpayments%22%5D%2C%22instructedAmount%22%3A%7B%22currency%22%3A%22EUR%22%2C%22amount%22%3A%22123.50%22%7D%2C%22creditorName%22%3A%22Merchant%20A%22%2C%22creditorAccount%22%3A%7B%22iban%22%3A%22DE02100100109307118603%22%7D%2C%22remittanceInformationUnstructured%22%3A%22Ref%20Number%20Merchant%22%7D%5D While the client authentication already provides some information about the provenance of the running software, the client also needs to prove that it complies with the requirements. Therefore, the authorization server challenges the client and responds with a Insufficient Client Authorization Response. The authorization server requests from the client the presentation of a verifiable credentials, e.g., a verifiable intent [Mastercard.VI]. HTTP/1.1 403 Forbidden Content-Type: application/json Cache-Control: no-store { "error": "insufficient_client_authorization", "authorization_requirement": { "type": "verifiable_presentation", "challenge_session": "7f3d9e2a-4c1b-4f8e-b5a0-1e6c8d2f0a9b", "presentation_definition": { ... } } } Acknowledgments The author wants to thank the following people for their feedback, input and contributions to this document: Kahrer Expires 20 November 2026 [Page 12] Internet-Draft OAuth Client Challenge Protocol May 2026 Jacob Ideskog, Michał Trojanowski Document History -00 * Initial draft Author's Address Judith Kahrer Curity Email: judith.kahrer@curity.io Kahrer Expires 20 November 2026 [Page 13]