From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9449.txt | 2067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2067 insertions(+) create mode 100644 doc/rfc/rfc9449.txt (limited to 'doc/rfc/rfc9449.txt') diff --git a/doc/rfc/rfc9449.txt b/doc/rfc/rfc9449.txt new file mode 100644 index 0000000..b3c521b --- /dev/null +++ b/doc/rfc/rfc9449.txt @@ -0,0 +1,2067 @@ + + + + +Internet Engineering Task Force (IETF) D. Fett +Request for Comments: 9449 Authlete +Category: Standards Track B. Campbell +ISSN: 2070-1721 Ping Identity + J. Bradley + Yubico + T. Lodderstedt + Tuconic + M. Jones + Self-Issued Consulting + D. Waite + Ping Identity + September 2023 + + + OAuth 2.0 Demonstrating Proof of Possession (DPoP) + +Abstract + + This document describes a mechanism for sender-constraining OAuth 2.0 + tokens via a proof-of-possession mechanism on the application level. + This mechanism allows for the detection of replay attacks with access + and refresh tokens. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9449. + +Copyright Notice + + Copyright (c) 2023 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 + 1.1. Conventions and Terminology + 2. Objectives + 3. Concept + 4. DPoP Proof JWTs + 4.1. The DPoP HTTP Header + 4.2. DPoP Proof JWT Syntax + 4.3. Checking DPoP Proofs + 5. DPoP Access Token Request + 5.1. Authorization Server Metadata + 5.2. Client Registration Metadata + 6. Public Key Confirmation + 6.1. JWK Thumbprint Confirmation Method + 6.2. JWK Thumbprint Confirmation Method in Token Introspection + 7. Protected Resource Access + 7.1. The DPoP Authentication Scheme + 7.2. Compatibility with the Bearer Authentication Scheme + 7.3. Client Considerations + 8. Authorization Server-Provided Nonce + 8.1. Nonce Syntax + 8.2. Providing a New Nonce Value + 9. Resource Server-Provided Nonce + 10. Authorization Code Binding to a DPoP Key + 10.1. DPoP with Pushed Authorization Requests + 11. Security Considerations + 11.1. DPoP Proof Replay + 11.2. DPoP Proof Pre-generation + 11.3. DPoP Nonce Downgrade + 11.4. Untrusted Code in the Client Context + 11.5. Signed JWT Swapping + 11.6. Signature Algorithms + 11.7. Request Integrity + 11.8. Access Token and Public Key Binding + 11.9. Authorization Code and Public Key Binding + 11.10. Hash Algorithm Agility + 11.11. Binding to Client Identity + 12. IANA Considerations + 12.1. OAuth Access Token Types Registration + 12.2. OAuth Extensions Error Registration + 12.3. OAuth Parameters Registration + 12.4. HTTP Authentication Schemes Registration + 12.5. Media Type Registration + 12.6. JWT Confirmation Methods Registration + 12.7. JSON Web Token Claims Registration + 12.7.1. "nonce" Registration Update + 12.8. Hypertext Transfer Protocol (HTTP) Field Name Registration + 12.9. OAuth Authorization Server Metadata Registration + 12.10. OAuth Dynamic Client Registration Metadata + 13. References + 13.1. Normative References + 13.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + Demonstrating Proof of Possession (DPoP) is an application-level + mechanism for sender-constraining OAuth [RFC6749] access and refresh + tokens. It enables a client to prove the possession of a public/ + private key pair by including a DPoP header in an HTTP request. The + value of the header is a JSON Web Token (JWT) [RFC7519] that enables + the authorization server to bind issued tokens to the public part of + a client's key pair. Recipients of such tokens are then able to + verify the binding of the token to the key pair that the client has + demonstrated that it holds via the DPoP header, thereby providing + some assurance that the client presenting the token also possesses + the private key. In other words, the legitimate presenter of the + token is constrained to be the sender that holds and proves + possession of the private part of the key pair. + + The mechanism specified herein can be used in cases where other + methods of sender-constraining tokens that utilize elements of the + underlying secure transport layer, such as [RFC8705] or + [TOKEN-BINDING], are not available or desirable. For example, due to + a sub-par user experience of TLS client authentication in user agents + and a lack of support for HTTP token binding, neither mechanism can + be used if an OAuth client is an application that is dynamically + downloaded and executed in a web browser (sometimes referred to as a + "single-page application"). Additionally, applications that are + installed and run directly on a user's device are well positioned to + benefit from DPoP-bound tokens that guard against the misuse of + tokens by a compromised or malicious resource. Such applications + often have dedicated protected storage for cryptographic keys. + + DPoP can be used to sender-constrain access tokens regardless of the + client authentication method employed, but DPoP itself is not used + for client authentication. DPoP can also be used to sender-constrain + refresh tokens issued to public clients (those without authentication + credentials associated with the client_id). + +1.1. Conventions and Terminology + + 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. + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234]. + + This specification uses the terms "access token", "refresh token", + "authorization server", "resource server", "authorization endpoint", + "authorization request", "authorization response", "token endpoint", + "grant type", "access token request", "access token response", + "client", "public client", and "confidential client" defined by "The + OAuth 2.0 Authorization Framework" [RFC6749]. + + The terms "request", "response", "header field", and "target URI" are + imported from [RFC9110]. + + The terms "JOSE" and "JOSE Header" are imported from [RFC7515]. + + This document contains non-normative examples of partial and complete + HTTP messages. Some examples use a single trailing backslash to + indicate line wrapping for long values, as per [RFC8792]. The + character and leading spaces on wrapped lines are not part of the + value. + +2. Objectives + + The primary aim of DPoP is to prevent unauthorized or illegitimate + parties from using leaked or stolen access tokens, by binding a token + to a public key upon issuance and requiring that the client proves + possession of the corresponding private key when using the token. + This constrains the legitimate sender of the token to only the party + with access to the private key and gives the server receiving the + token added assurances that the sender is legitimately authorized to + use it. + + Access tokens that are sender-constrained via DPoP thus stand in + contrast to the typical bearer token, which can be used by any party + in possession of such a token. Although protections generally exist + to prevent unintended disclosure of bearer tokens, unforeseen vectors + for leakage have occurred due to vulnerabilities and implementation + issues in other layers in the protocol or software stack (see, e.g., + Compression Ratio Info-leak Made Easy (CRIME) [CRIME], Browser + Reconnaissance and Exfiltration via Adaptive Compression of Hypertext + (BREACH) [BREACH], Heartbleed [Heartbleed], and the Cloudflare parser + bug [Cloudbleed]). There have also been numerous published token + theft attacks on OAuth implementations themselves ([GitHub.Tokens] is + just one high-profile example). DPoP provides a general defense in + depth against the impact of unanticipated token leakage. DPoP is + not, however, a substitute for a secure transport and MUST always be + used in conjunction with HTTPS. + + The very nature of the typical OAuth protocol interaction + necessitates that the client discloses the access token to the + protected resources that it accesses. The attacker model in + [SECURITY-TOPICS] describes cases where a protected resource might be + counterfeit, malicious, or compromised and plays received tokens + against other protected resources to gain unauthorized access. + Audience-restricted access tokens (e.g., using the JWT [RFC7519] aud + claim) can prevent such misuse. However, doing so in practice has + proven to be prohibitively cumbersome for many deployments (despite + extensions such as [RFC8707]). Sender-constraining access tokens is + a more robust and straightforward mechanism to prevent such token + replay at a different endpoint, and DPoP is an accessible + application-layer means of doing so. + + Due to the potential for cross-site scripting (XSS), browser-based + OAuth clients bring to bear added considerations with respect to + protecting tokens. The most straightforward XSS-based attack is for + an attacker to exfiltrate a token and use it themselves completely + independent of the legitimate client. A stolen access token is used + for protected resource access, and a stolen refresh token is used for + obtaining new access tokens. If the private key is non-extractable + (as is possible with [W3C.WebCryptoAPI]), DPoP renders exfiltrated + tokens alone unusable. + + XSS vulnerabilities also allow an attacker to execute code in the + context of the browser-based client application and maliciously use a + token indirectly through the client. That execution context has + access to utilize the signing key; thus, it can produce DPoP proofs + to use in conjunction with the token. At this application layer, + there is most likely no feasible defense against this threat except + generally preventing XSS; therefore, it is considered out of scope + for DPoP. + + Malicious XSS code executed in the context of the browser-based + client application is also in a position to create DPoP proofs with + timestamp values in the future and exfiltrate them in conjunction + with a token. These stolen artifacts can later be used independent + of the client application to access protected resources. To prevent + this, servers can optionally require clients to include a server- + chosen value into the proof that cannot be predicted by an attacker + (nonce). In the absence of the optional nonce, the impact of pre- + computed DPoP proofs is limited somewhat by the proof being bound to + an access token on protected resource access. Because a proof + covering an access token that does not yet exist cannot feasibly be + created, access tokens obtained with an exfiltrated refresh token and + pre-computed proofs will be unusable. + + Additional security considerations are discussed in Section 11. + +3. Concept + + The main data structure introduced by this specification is a DPoP + proof JWT that is sent as a header in an HTTP request, as described + in detail below. A client uses a DPoP proof JWT to prove the + possession of a private key corresponding to a certain public key. + + Roughly speaking, a DPoP proof is a signature over: + + * some data of the HTTP request to which it is attached, + + * a timestamp, + + * a unique identifier, + + * an optional server-provided nonce, and + + * a hash of the associated access token when an access token is + present within the request. + + +--------+ +---------------+ + | |--(A)-- Token Request ------------------->| | + | Client | (DPoP Proof) | Authorization | + | | | Server | + | |<-(B)-- DPoP-Bound Access Token ----------| | + | | (token_type=DPoP) +---------------+ + | | + | | + | | +---------------+ + | |--(C)-- DPoP-Bound Access Token --------->| | + | | (DPoP Proof) | Resource | + | | | Server | + | |<-(D)-- Protected Resource ---------------| | + | | +---------------+ + +--------+ + + Figure 1: Basic DPoP Flow + + The basic steps of an OAuth flow with DPoP (without the optional + nonce) are shown in Figure 1. + + A. In the token request, the client sends an authorization grant + (e.g., an authorization code, refresh token, etc.) to the + authorization server in order to obtain an access token (and + potentially a refresh token). The client attaches a DPoP proof + to the request in an HTTP header. + + B. The authorization server binds (sender-constrains) the access + token to the public key claimed by the client in the DPoP proof; + that is, the access token cannot be used without proving + possession of the respective private key. If a refresh token is + issued to a public client, it is also bound to the public key of + the DPoP proof. + + C. To use the access token, the client has to prove possession of + the private key by, again, adding a header to the request that + carries a DPoP proof for that request. The resource server needs + to receive information about the public key to which the access + token is bound. This information may be encoded directly into + the access token (for JWT-structured access tokens) or provided + via token introspection endpoint (not shown). The resource + server verifies that the public key to which the access token is + bound matches the public key of the DPoP proof. It also verifies + that the access token hash in the DPoP proof matches the access + token presented in the request. + + D. The resource server refuses to serve the request if the signature + check fails or if the data in the DPoP proof is wrong, e.g., the + target URI does not match the URI claim in the DPoP proof JWT. + The access token itself, of course, must also be valid in all + other respects. + + The DPoP mechanism presented herein is not a client authentication + method. In fact, a primary use case of DPoP is for public clients + (e.g., single-page applications and applications on a user's device) + that do not use client authentication. Nonetheless, DPoP is designed + to be compatible with private_key_jwt and all other client + authentication methods. + + DPoP does not directly ensure message integrity, but it relies on the + TLS layer for that purpose. See Section 11 for details. + +4. DPoP Proof JWTs + + DPoP introduces the concept of a DPoP proof, which is a JWT created + by the client and sent with an HTTP request using the DPoP header + field. Each HTTP request requires a unique DPoP proof. + + A valid DPoP proof demonstrates to the server that the client holds + the private key that was used to sign the DPoP proof JWT. This + enables authorization servers to bind issued tokens to the + corresponding public key (as described in Section 5) and enables + resource servers to verify the key-binding of tokens that it receives + (see Section 7.1), which prevents said tokens from being used by any + entity that does not have access to the private key. + + The DPoP proof demonstrates possession of a key and, by itself, is + not an authentication or access control mechanism. When presented in + conjunction with a key-bound access token as described in + Section 7.1, the DPoP proof provides additional assurance about the + legitimacy of the client to present the access token. However, a + valid DPoP proof JWT is not sufficient alone to make access control + decisions. + +4.1. The DPoP HTTP Header + + A DPoP proof is included in an HTTP request using the following + request header field. + + DPoP: A JWT that adheres to the structure and syntax of Section 4.2. + + Figure 2 shows an example DPoP HTTP header field. The example uses + "\" line wrapping per [RFC8792]. + + DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\ + VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\ + nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\ + QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\ + oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\ + WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\ + 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg + + Figure 2: Example DPoP Header + + Note that per [RFC9110], header field names are case insensitive; + thus, DPoP, DPOP, dpop, etc., are all valid and equivalent header + field names. However, case is significant in the header field value. + + The DPoP HTTP header field value uses the token68 syntax defined in + Section 11.2 of [RFC9110] and is repeated below in Figure 3 for ease + of reference. + + DPoP = token68 + token68 = 1*( ALPHA / DIGIT / + "-" / "." / "_" / "~" / "+" / "/" ) *"=" + + Figure 3: DPoP Header Field ABNF + +4.2. DPoP Proof JWT Syntax + + A DPoP proof is a JWT [RFC7519] that is signed (using JSON Web + Signature (JWS) [RFC7515]) with a private key chosen by the client + (see below). The JOSE Header of a DPoP JWT MUST contain at least the + following parameters: + + typ: A field with the value dpop+jwt, which explicitly types the + DPoP proof JWT as recommended in Section 3.11 of [RFC8725]. + + alg: An identifier for a JWS asymmetric digital signature algorithm + from [IANA.JOSE.ALGS]. It MUST NOT be none or an identifier for a + symmetric algorithm (Message Authentication Code (MAC)). + + jwk: Represents the public key chosen by the client in JSON Web Key + (JWK) [RFC7517] format as defined in Section 4.1.3 of [RFC7515]. + It MUST NOT contain a private key. + + The payload of a DPoP proof MUST contain at least the following + claims: + + jti: Unique identifier for the DPoP proof JWT. The value MUST be + assigned such that there is a negligible probability that the same + value will be assigned to any other DPoP proof used in the same + context during the time window of validity. Such uniqueness can + be accomplished by encoding (base64url or any other suitable + encoding) at least 96 bits of pseudorandom data or by using a + version 4 Universally Unique Identifier (UUID) string according to + [RFC4122]. The jti can be used by the server for replay detection + and prevention; see Section 11.1. + + htm: The value of the HTTP method (Section 9.1 of [RFC9110]) of the + request to which the JWT is attached. + + htu: The HTTP target URI (Section 7.1 of [RFC9110]) of the request + to which the JWT is attached, without query and fragment parts. + + iat: Creation timestamp of the JWT (Section 4.1.6 of [RFC7519]). + + When the DPoP proof is used in conjunction with the presentation of + an access token in protected resource access (see Section 7), the + DPoP proof MUST also contain the following claim: + + ath: Hash of the access token. The value MUST be the result of a + base64url encoding (as defined in Section 2 of [RFC7515]) the + SHA-256 [SHS] hash of the ASCII encoding of the associated access + token's value. + + When the authentication server or resource server provides a DPoP- + Nonce HTTP header in a response (see Sections 8 and 9), the DPoP + proof MUST also contain the following claim: + + nonce: A recent nonce provided via the DPoP-Nonce HTTP header. + + A DPoP proof MAY contain other JOSE Header Parameters or claims as + defined by extension, profile, or deployment-specific requirements. + + Figure 4 is a conceptual example showing the decoded content of the + DPoP proof in Figure 2. The JSON of the JWT header and payload are + shown, but the signature part is omitted. As usual, line breaks and + extra spaces are included for formatting and readability. + + { + "typ":"dpop+jwt", + "alg":"ES256", + "jwk": { + "kty":"EC", + "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs", + "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA", + "crv":"P-256" + } + } + . + { + "jti":"-BwC3ESc6acc2lTc", + "htm":"POST", + "htu":"https://server.example.com/token", + "iat":1562262616 + } + + Figure 4: Example JWT Content of a DPoP Proof + + Of the HTTP request, only the HTTP method and URI are included in the + DPoP JWT; therefore, only these two message parts are covered by the + DPoP proof. The idea is to sign just enough of the HTTP data to + provide reasonable proof of possession with respect to the HTTP + request. This design approach of using only a minimal subset of the + HTTP header data is to avoid the substantial difficulties inherent in + attempting to normalize HTTP messages. Nonetheless, DPoP proofs can + be extended to contain other information of the HTTP request (see + also Section 11.7). + +4.3. Checking DPoP Proofs + + To validate a DPoP proof, the receiving server MUST ensure the + following: + + 1. There is not more than one DPoP HTTP request header field. + 2. The DPoP HTTP request header field value is a single and well- + formed JWT. + 3. All required claims per Section 4.2 are contained in the JWT. + 4. The typ JOSE Header Parameter has the value dpop+jwt. + 5. The alg JOSE Header Parameter indicates a registered asymmetric + digital signature algorithm [IANA.JOSE.ALGS], is not none, is + supported by the application, and is acceptable per local + policy. + 6. The JWT signature verifies with the public key contained in the + jwk JOSE Header Parameter. + 7. The jwk JOSE Header Parameter does not contain a private key. + 8. The htm claim matches the HTTP method of the current request. + 9. The htu claim matches the HTTP URI value for the HTTP request in + which the JWT was received, ignoring any query and fragment + parts. + 10. If the server provided a nonce value to the client, the nonce + claim matches the server-provided nonce value. + 11. The creation time of the JWT, as determined by either the iat + claim or a server managed timestamp via the nonce claim, is + within an acceptable window (see Section 11.1). + 12. If presented to a protected resource in conjunction with an + access token, + * ensure that the value of the ath claim equals the hash of + that access token, and + * confirm that the public key to which the access token is + bound matches the public key from the DPoP proof. + + To reduce the likelihood of false negatives, servers SHOULD employ + syntax-based normalization (Section 6.2.2 of [RFC3986]) and scheme- + based normalization (Section 6.2.3 of [RFC3986]) before comparing the + htu claim. + + These checks may be performed in any order. + +5. DPoP Access Token Request + + To request an access token that is bound to a public key using DPoP, + the client MUST provide a valid DPoP proof JWT in a DPoP header when + making an access token request to the authorization server's token + endpoint. This is applicable for all access token requests + regardless of grant type (e.g., the common authorization_code and + refresh_token grant types and extension grants such as the JWT + authorization grant [RFC7523]). The HTTP request shown in Figure 5 + illustrates such an access token request using an authorization code + grant with a DPoP proof JWT in the DPoP header. Figure 5 uses "\" + line wrapping per [RFC8792]. + + POST /token HTTP/1.1 + Host: server.example.com + Content-Type: application/x-www-form-urlencoded + DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\ + VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\ + nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\ + QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\ + oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\ + WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\ + 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg + + grant_type=authorization_code\ + &client_id=s6BhdRkqt\ + &code=SplxlOBeZQQYbYS6WxSbIA + &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb\ + &code_verifier=bEaL42izcC-o-xBk0K2vuJ6U-y1p9r_wW2dFWIWgjz- + + Figure 5: Token Request for a DPoP Sender-Constrained Token Using an + Authorization Code + + The DPoP HTTP header field MUST contain a valid DPoP proof JWT. If + the DPoP proof is invalid, the authorization server issues an error + response per Section 5.2 of [RFC6749] with invalid_dpop_proof as the + value of the error parameter. + + To sender-constrain the access token after checking the validity of + the DPoP proof, the authorization server associates the issued access + token with the public key from the DPoP proof, which can be + accomplished as described in Section 6. A token_type of DPoP MUST be + included in the access token response to signal to the client that + the access token was bound to its DPoP key and can be used as + described in Section 7.1. The example response shown in Figure 6 + illustrates such a response. + + HTTP/1.1 200 OK + Content-Type: application/json + Cache-Control: no-store + + { + "access_token": "Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU", + "token_type": "DPoP", + "expires_in": 2677, + "refresh_token": "Q..Zkm29lexi8VnWg2zPW1x-tgGad0Ibc3s3EwM_Ni4-g" + } + + Figure 6: Access Token Response + + The example response in Figure 6 includes a refresh token that the + client can use to obtain a new access token when the previous one + expires. Refreshing an access token is a token request using the + refresh_token grant type made to the authorization server's token + endpoint. As with all access token requests, the client makes it a + DPoP request by including a DPoP proof, as shown in Figure 7. + Figure 7 uses "\" line wrapping per [RFC8792]. + + POST /token HTTP/1.1 + Host: server.example.com + Content-Type: application/x-www-form-urlencoded + DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\ + VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\ + nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\ + QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\ + oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\ + WF0IjoxNTYyMjY1Mjk2fQ.pAqut2IRDm_De6PR93SYmGBPXpwrAk90e8cP2hjiaG5Qs\ + GSuKDYW7_X620BxqhvYC8ynrrvZLTk41mSRroapUA + + grant_type=refresh_token\ + &client_id=s6BhdRkqt\ + &refresh_token=Q..Zkm29lexi8VnWg2zPW1x-tgGad0Ibc3s3EwM_Ni4-g + + Figure 7: Token Request for a DPoP-Bound Token Using a Refresh Token + + When an authorization server supporting DPoP issues a refresh token + to a public client that presents a valid DPoP proof at the token + endpoint, the refresh token MUST be bound to the respective public + key. The binding MUST be validated when the refresh token is later + presented to get new access tokens. As a result, such a client MUST + present a DPoP proof for the same key that was used to obtain the + refresh token each time that refresh token is used to obtain a new + access token. The implementation details of the binding of the + refresh token are at the discretion of the authorization server. + Since the authorization server both produces and validates its + refresh tokens, there is no interoperability consideration in the + specific details of the binding. + + An authorization server MAY elect to issue access tokens that are not + DPoP bound, which is signaled to the client with a value of Bearer in + the token_type parameter of the access token response per [RFC6750]. + For a public client that is also issued a refresh token, this has the + effect of DPoP-binding the refresh token alone, which can improve the + security posture even when protected resources are not updated to + support DPoP. + + If the access token response contains a different token_type value + than DPoP, the access token protection provided by DPoP is not given. + The client MUST discard the response in this case if this protection + is deemed important for the security of the application; otherwise, + the client may continue as in a regular OAuth interaction. + + Refresh tokens issued to confidential clients (those having + established authentication credentials with the authorization server) + are not bound to the DPoP proof public key because they are already + sender-constrained with a different existing mechanism. The OAuth + 2.0 Authorization Framework [RFC6749] already requires that an + authorization server bind refresh tokens to the client to which they + were issued and that confidential clients authenticate to the + authorization server when presenting a refresh token. As a result, + such refresh tokens are sender-constrained by way of the client + identifier and the associated authentication requirement. This + existing sender-constraining mechanism is more flexible (e.g., it + allows credential rotation for the client without invalidating + refresh tokens) than binding directly to a particular public key. + +5.1. Authorization Server Metadata + + This document introduces the following authorization server metadata + [RFC8414] parameter to signal support for DPoP in general and the + specific JWS alg values the authorization server supports for DPoP + proof JWTs. + + dpop_signing_alg_values_supported: A JSON array containing a list of + the JWS alg values (from the [IANA.JOSE.ALGS] registry) supported + by the authorization server for DPoP proof JWTs. + +5.2. Client Registration Metadata + + The Dynamic Client Registration Protocol [RFC7591] defines an API for + dynamically registering OAuth 2.0 client metadata with authorization + servers. The metadata defined by [RFC7591], and registered + extensions to it, also imply a general data model for clients that is + useful for authorization server implementations even when the Dynamic + Client Registration Protocol isn't in play. Such implementations + will typically have some sort of user interface available for + managing client configuration. + + This document introduces the following client registration metadata + [RFC7591] parameter to indicate that the client always uses DPoP when + requesting tokens from the authorization server. + + dpop_bound_access_tokens: A boolean value specifying whether the + client always uses DPoP for token requests. If omitted, the + default value is false. + + If the value is true, the authorization server MUST reject token + requests from the client that do not contain the DPoP header. + +6. Public Key Confirmation + + Resource servers MUST be able to reliably identify whether an access + token is DPoP-bound and ascertain sufficient information to verify + the binding to the public key of the DPoP proof (see Section 7.1). + Such a binding is accomplished by associating the public key with the + token in a way that can be accessed by the protected resource, such + as embedding the JWK hash in the issued access token directly, using + the syntax described in Section 6.1, or through token introspection + as described in Section 6.2. Other methods of associating a public + key with an access token are possible per an agreement by the + authorization server and the protected resource; however, they are + beyond the scope of this specification. + + Resource servers supporting DPoP MUST ensure that the public key from + the DPoP proof matches the one bound to the access token. + +6.1. JWK Thumbprint Confirmation Method + + When access tokens are represented as JWTs [RFC7519], the public key + information is represented using the jkt confirmation method member + defined herein. To convey the hash of a public key in a JWT, this + specification introduces the following JWT Confirmation Method + [RFC7800] member for use under the cnf claim. + + jkt: JWK SHA-256 Thumbprint confirmation method. The value of the + jkt member MUST be the base64url encoding (as defined in + [RFC7515]) of the JWK SHA-256 Thumbprint (according to [RFC7638]) + of the DPoP public key (in JWK format) to which the access token + is bound. + + The following example JWT in Figure 8 with a decoded JWT payload + shown in Figure 9 contains a cnf claim with the jkt JWK Thumbprint + confirmation method member. The jkt value in these examples is the + hash of the public key from the DPoP proofs in the examples shown in + Section 5. The example uses "\" line wrapping per [RFC8792]. + + eyJhbGciOiJFUzI1NiIsImtpZCI6IkJlQUxrYiJ9.eyJzdWIiOiJzb21lb25lQGV4YW1\ + wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJuYmYiOjE\ + 1NjIyNjI2MTEsImV4cCI6MTU2MjI2NjIxNiwiY25mIjp7ImprdCI6IjBaY09DT1JaTll\ + 5LURXcHFxMzBqWnlKR0hUTjBkMkhnbEJWM3VpZ3VBNEkifX0.3Tyo8VTcn6u_PboUmAO\ + YUY1kfAavomW_YwYMkmRNizLJoQzWy2fCo79Zi5yObpIzjWb5xW4OGld7ESZrh0fsrA + + Figure 8: JWT Containing a JWK SHA-256 Thumbprint Confirmation + + { + "sub":"someone@example.com", + "iss":"https://server.example.com", + "nbf":1562262611, + "exp":1562266216, + "cnf": + { + "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" + } + } + + Figure 9: JWT Claims Set with a JWK SHA-256 Thumbprint Confirmation + +6.2. JWK Thumbprint Confirmation Method in Token Introspection + + "OAuth 2.0 Token Introspection" [RFC7662] defines a method for a + protected resource to query an authorization server about the active + state of an access token. The protected resource also determines + metainformation about the token. + + For a DPoP-bound access token, the hash of the public key to which + the token is bound is conveyed to the protected resource as + metainformation in a token introspection response. The hash is + conveyed using the same cnf content with jkt member structure as the + JWK Thumbprint confirmation method, described in Section 6.1, as a + top-level member of the introspection response JSON. Note that the + resource server does not send a DPoP proof with the introspection + request, and the authorization server does not validate an access + token's DPoP binding at the introspection endpoint. Rather, the + resource server uses the data of the introspection response to + validate the access token binding itself locally. + + If the token_type member is included in the introspection response, + it MUST contain the value DPoP. + + The example introspection request in Figure 10 and corresponding + response in Figure 11 illustrate an introspection exchange for the + example DPoP-bound access token that was issued in Figure 6. + + POST /as/introspect.oauth2 HTTP/1.1 + Host: server.example.com + Content-Type: application/x-www-form-urlencoded + Authorization: Basic cnM6cnM6TWt1LTZnX2xDektJZHo0ZnNON2tZY3lhK1Rp + + token=Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU + + Figure 10: Example Introspection Request + + HTTP/1.1 200 OK + Content-Type: application/json + Cache-Control: no-store + + { + "active": true, + "sub": "someone@example.com", + "iss": "https://server.example.com", + "nbf": 1562262611, + "exp": 1562266216, + "cnf": + { + "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" + } + } + + Figure 11: Example Introspection Response for a DPoP-Bound Access + Token + +7. Protected Resource Access + + Requests to DPoP-protected resources MUST include both a DPoP proof + as per Section 4 and the access token as described in Section 7.1. + The DPoP proof MUST include the ath claim with a valid hash of the + associated access token. + + Binding the token value to the proof in this way prevents a proof to + be used with multiple different access token values across different + requests. For example, if a client holds tokens bound to two + different resource owners, AT1 and AT2, and uses the same key when + talking to the authorization server, it's possible that these tokens + could be swapped. Without the ath field to bind it, a captured + signature applied to AT1 could be replayed with AT2 instead, changing + the rights and access of the intended request. This same + substitution prevention remains for rotated access tokens within the + same combination of client and resource owner -- a rotated token + value would require the calculation of a new proof. This binding + additionally ensures that a proof intended for use with the access + token is not usable without an access token, or vice-versa. + + The resource server is required to calculate the hash of the token + value presented and verify that it is the same as the hash value in + the ath field as described in Section 4.3. Since the ath field value + is covered by the DPoP proof's signature, its inclusion binds the + access token value to the holder of the key used to generate the + signature. + + Note that the ath field alone does not prevent replay of the DPoP + proof or provide binding to the request in which the proof is + presented, and it is still important to check the time window of the + proof as well as the included message parameters, such as htm and + htu. + +7.1. The DPoP Authentication Scheme + + A DPoP-bound access token is sent using the Authorization request + header field per Section 11.6.2 of [RFC9110] with an authentication + scheme of DPoP. The syntax of the Authorization header field for the + DPoP scheme uses the token68 syntax defined in Section 11.2 of + [RFC9110] for credentials and is repeated below for ease of + reference. The ABNF notation syntax for DPoP authentication scheme + credentials is as follows: + + token68 = 1*( ALPHA / DIGIT / + "-" / "." / "_" / "~" / "+" / "/" ) *"=" + + credentials = "DPoP" 1*SP token68 + + Figure 12: DPoP Authentication Scheme ABNF + + For such an access token, a resource server MUST check that a DPoP + proof was also received in the DPoP header field of the HTTP request, + check the DPoP proof according to the rules in Section 4.3, and check + that the public key of the DPoP proof matches the public key to which + the access token is bound per Section 6. + + The resource server MUST NOT grant access to the resource unless all + checks are successful. + + Figure 13 shows an example request to a protected resource with a + DPoP-bound access token in the Authorization header and the DPoP + proof in the DPoP header. The example uses "\" line wrapping per + [RFC8792]. Figure 14 shows the decoded content of that DPoP proof. + The JSON of the JWT header and payload are shown, but the signature + part is omitted. As usual, line breaks and indentation are included + for formatting and readability. + + GET /protectedresource HTTP/1.1 + Host: resource.example.org + Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU + DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\ + VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\ + nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\ + QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj\ + oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z\ + WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOCwiYXRoIjoiZlVIeU8ycjJaM0RaNTNF\ + c05yV0JiMHhXWG9hTnk1OUlpS0NBcWtzbVFFbyJ9.2oW9RP35yRqzhrtNP86L-Ey71E\ + OptxRimPPToA1plemAgR6pxHF8y6-yqyVnmcw6Fy1dqd-jfxSYoMxhAJpLjA + + Figure 13: DPoP-Protected Resource Request + + { + "typ":"dpop+jwt", + "alg":"ES256", + "jwk": { + "kty":"EC", + "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs", + "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA", + "crv":"P-256" + } + } + . + { + "jti":"e1j3V_bKic8-LAEB", + "htm":"GET", + "htu":"https://resource.example.org/protectedresource", + "iat":1562262618, + "ath":"fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo" + } + + Figure 14: Decoded Content of the DPoP Proof JWT in Figure 13 + + Upon receipt of a request to a protected resource within the + protection space requiring DPoP authentication, the server can + respond with a challenge to the client to provide DPoP authentication + information if the request does not include valid credentials or does + not contain an access token sufficient for access. Such a challenge + is made using the 401 (Unauthorized) response status code ([RFC9110], + Section 15.5.2) and the WWW-Authenticate header field ([RFC9110], + Section 11.6.1). The server MAY include the WWW-Authenticate header + in response to other conditions as well. + + In such challenges: + + * The scheme name is DPoP. + * The authentication parameter realm MAY be included to indicate the + scope of protection in the manner described in [RFC9110], + Section 11.5. + * A scope authentication parameter MAY be included as defined in + [RFC6750], Section 3. + * An error parameter ([RFC6750], Section 3) SHOULD be included to + indicate the reason why the request was declined, if the request + included an access token but failed authentication. The error + parameter values described in [RFC6750], Section 3.1 are suitable, + as are any appropriate values defined by extension. The value + use_dpop_nonce can be used as described in Section 9 to signal + that a nonce is needed in the DPoP proof of a subsequent + request(s). Additionally, invalid_dpop_proof is used to indicate + that the DPoP proof itself was deemed invalid based on the + criteria of Section 4.3. + * An error_description parameter ([RFC6750], Section 3) MAY be + included along with the error parameter to provide developers a + human-readable explanation that is not meant to be displayed to + end-users. + * An algs parameter SHOULD be included to signal to the client the + JWS algorithms that are acceptable for the DPoP proof JWT. The + value of the parameter is a space-delimited list of JWS alg + (Algorithm) header values ([RFC7515], Section 4.1.1). + * Additional authentication parameters MAY be used, and unknown + parameters MUST be ignored by recipients. + + Figure 15 shows a response to a protected resource request without + authentication. + + HTTP/1.1 401 Unauthorized + WWW-Authenticate: DPoP algs="ES256 PS256" + + Figure 15: HTTP 401 Response to a Protected Resource Request without + Authentication + + Figure 16 shows a response to a protected resource request that was + rejected due to the failed confirmation of the DPoP binding in the + access token. Figure 16 uses "\" line wrapping per [RFC8792]. + + HTTP/1.1 401 Unauthorized + WWW-Authenticate: DPoP error="invalid_token", \ + error_description="Invalid DPoP key binding", algs="ES256" + + Figure 16: HTTP 401 Response to a Protected Resource Request with + an Invalid Token + + Note that browser-based client applications using Cross-Origin + Resource Sharing (CORS) [WHATWG.Fetch] only have access to CORS- + safelisted response HTTP headers by default. In order for the + application to obtain and use the WWW-Authenticate HTTP response + header value, the server needs to make it available to the + application by including WWW-Authenticate in the Access-Control- + Expose-Headers response header list value. + + This authentication scheme is for origin-server authentication only. + Therefore, this authentication scheme MUST NOT be used with the + Proxy-Authenticate or Proxy-Authorization header fields. + + Note that the syntax of the Authorization header field for this + authentication scheme follows the usage of the Bearer scheme defined + in Section 2.1 of [RFC6750]. While it is not the preferred + credential syntax of [RFC9110], it is compatible with the general + authentication framework therein and is used for consistency and + familiarity with the Bearer scheme. + +7.2. Compatibility with the Bearer Authentication Scheme + + Protected resources simultaneously supporting both the DPoP and + Bearer schemes need to update how the evaluation process is performed + for bearer tokens to prevent downgraded usage of a DPoP-bound access + token. Specifically, such a protected resource MUST reject a DPoP- + bound access token received as a bearer token per [RFC6750]. + + Section 11.6.1 of [RFC9110] allows a protected resource to indicate + support for multiple authentication schemes (i.e., Bearer and DPoP) + with the WWW-Authenticate header field of a 401 (Unauthorized) + response. + + A protected resource that supports only [RFC6750] and is unaware of + DPoP would most presumably accept a DPoP-bound access token as a + bearer token (JWT [RFC7519] says to ignore unrecognized claims, + Introspection [RFC7662] says that other parameters might be present + while placing no functional requirements on their presence, and + [RFC6750] is effectively silent on the content of the access token + since it relates to validity). As such, a client can send a DPoP- + bound access token using the Bearer scheme upon receipt of a WWW- + Authenticate: Bearer challenge from a protected resource (or it can + send a DPoP-bound access token if it has prior knowledge of the + capabilities of the protected resource). The effect of this likely + simplifies the logistics of phased upgrades to protected resources in + their support DPoP or prolonged deployments of protected resources + with mixed token type support. + + If a protected resource supporting both Bearer and DPoP schemes + elects to respond with multiple WWW-Authenticate challenges, + attention should be paid to which challenge(s) should deliver the + actual error information. It is RECOMMENDED that the following rules + be adhered to: + + * If no authentication information has been included with the + request, then the challenges SHOULD NOT include an error code or + other error information, as per Section 3.1 of [RFC6750] + (Figure 17). + + * If the mechanism used to attempt authentication could be + established unambiguously, then the corresponding challenge SHOULD + be used to deliver error information (Figure 18). + + * Otherwise, both Bearer and DPoP challenges MAY be used to deliver + error information (Figure 19). + + The following examples use "\" line wrapping per [RFC8792]. + + GET /protectedresource HTTP/1.1 + Host: resource.example.org + + HTTP/1.1 401 Unauthorized + WWW-Authenticate: Bearer, DPoP algs="ES256 PS256" + + Figure 17: HTTP 401 Response to a Protected Resource Request without + Authentication + + GET /protectedresource HTTP/1.1 + Host: resource.example.org + Authorization: Bearer INVALID_TOKEN + + HTTP/1.1 401 Unauthorized + WWW-Authenticate: Bearer error="invalid_token", \ + error_description="Invalid token", DPoP algs="ES256 PS256" + + Figure 18: HTTP 401 Response to a Protected Resource Request with + Invalid Authentication + + GET /protectedresource HTTP/1.1 + Host: resource.example.org + Authorization: Bearer Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU + Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU + + HTTP/1.1 400 Bad Request + WWW-Authenticate: Bearer error="invalid_request", \ + error_description="Multiple methods used to include access token", \ + DPoP algs="ES256 PS256", error="invalid_request", \ + error_description="Multiple methods used to include access token" + + Figure 19: HTTP 400 Response to a Protected Resource Request with + Ambiguous Authentication + +7.3. Client Considerations + + Authorization including a DPoP proof may not be idempotent (depending + on server enforcement of jti, iat, and nonce claims). Consequently, + all previously idempotent requests for protected resources that were + previously idempotent may no longer be idempotent. It is RECOMMENDED + that clients generate a unique DPoP proof, even when retrying + idempotent requests in response to HTTP errors generally understood + as transient. + + Clients that encounter frequent network errors may experience + additional challenges when interacting with servers with stricter + nonce validation implementations. + +8. Authorization Server-Provided Nonce + + This section specifies a mechanism using opaque nonces provided by + the server that can be used to limit the lifetime of DPoP proofs. + Without employing such a mechanism, a malicious party controlling the + client (potentially including the end-user) can create DPoP proofs + for use arbitrarily far in the future. + + Including a nonce value contributed by the authorization server in + the DPoP proof MAY be used by authorization servers to limit the + lifetime of DPoP proofs. The server determines when to issue a new + DPoP nonce challenge and if it is needed, thereby requiring the use + of the nonce value in subsequent DPoP proofs. The logic through + which the server makes that determination is out of scope of this + document. + + An authorization server MAY supply a nonce value to be included by + the client in DPoP proofs sent. In this case, the authorization + server responds to requests that do not include a nonce with an HTTP + 400 (Bad Request) error response per Section 5.2 of [RFC6749] using + use_dpop_nonce as the error code value. The authorization server + includes a DPoP-Nonce HTTP header in the response supplying a nonce + value to be used when sending the subsequent request. Nonce values + MUST be unpredictable. This same error code is used when supplying a + new nonce value when there was a nonce mismatch. The client will + typically retry the request with the new nonce value supplied upon + receiving a use_dpop_nonce error with an accompanying nonce value. + + For example, in response to a token request without a nonce when the + authorization server requires one, the authorization server can + respond with a DPoP-Nonce value such as the following to provide a + nonce value to include in the DPoP proof: + + HTTP/1.1 400 Bad Request + DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v + + { + "error": "use_dpop_nonce", + "error_description": + "Authorization server requires nonce in DPoP proof" + } + + Figure 20: HTTP 400 Response to a Token Request without a Nonce + + Other HTTP headers and JSON fields MAY also be included in the error + response, but there MUST NOT be more than one DPoP-Nonce header. + + Upon receiving the nonce, the client is expected to retry its token + request using a DPoP proof including the supplied nonce value in the + nonce claim of the DPoP proof. An example unencoded JWT payload of + such a DPoP proof including a nonce is shown below. + + { + "jti": "-BwC3ESc6acc2lTc", + "htm": "POST", + "htu": "https://server.example.com/token", + "iat": 1562262616, + "nonce": "eyJ7S_zG.eyJH0-Z.HX4w-7v" + } + + Figure 21: DPoP Proof Payload including a Nonce Value + + The nonce is opaque to the client. + + If the nonce claim in the DPoP proof does not exactly match a nonce + recently supplied by the authorization server to the client, the + authorization server MUST reject the request. The rejection response + MAY include a DPoP-Nonce HTTP header providing a new nonce value to + use for subsequent requests. + + The intent is that clients need to keep only one nonce value and + servers need to keep a window of recent nonces. That said, transient + circumstances may arise in which the stored nonce values for the + server and the client differ. However, this situation is self- + correcting. With any rejection message, the server can send the + client the nonce value it wants to use to the client, and the client + can store that nonce value and retry the request with it. Even if + the client and/or server discard their stored nonce values, that + situation is also self-correcting because new nonce values can be + communicated when responding to or retrying failed requests. + + Note that browser-based client applications using CORS [WHATWG.Fetch] + only have access to CORS-safelisted response HTTP headers by default. + In order for the application to obtain and use the DPoP-Nonce HTTP + response header value, the server needs to make it available to the + application by including DPoP-Nonce in the Access-Control-Expose- + Headers response header list value. + +8.1. Nonce Syntax + + The nonce syntax in ABNF as used by [RFC6749] (which is the same as + the scope-token syntax) is shown below. + + nonce = 1*NQCHAR + + Figure 22: Nonce ABNF + +8.2. Providing a New Nonce Value + + It is up to the authorization server when to supply a new nonce value + for the client to use. The client is expected to use the existing + supplied nonce in DPoP proofs until the server supplies a new nonce + value. + + The authorization server MAY supply the new nonce in the same way + that the initial one was supplied: by using a DPoP-Nonce HTTP header + in the response. The DPoP-Nonce HTTP header field uses the nonce + syntax defined in Section 8.1. Each time this happens, it requires + an extra protocol round trip. + + A more efficient manner of supplying a new nonce value is also + defined by including a DPoP-Nonce HTTP header in the HTTP 200 (OK) + response from the previous request. The client MUST use the new + nonce value supplied for the next token request and for all + subsequent token requests until the authorization server supplies a + new nonce. + + Responses that include the DPoP-Nonce HTTP header should be + uncacheable (e.g., using Cache-Control: no-store in response to a GET + request) to prevent the response from being used to serve a + subsequent request and a stale nonce value from being used as a + result. + + An example 200 OK response providing a new nonce value is shown + below. + + HTTP/1.1 200 OK + Cache-Control: no-store + DPoP-Nonce: eyJ7S_zG.eyJbYu3.xQmBj-1 + + Figure 23: HTTP 200 Response Providing the Next Nonce Value + +9. Resource Server-Provided Nonce + + Resource servers can also choose to provide a nonce value to be + included in DPoP proofs sent to them. They provide the nonce using + the DPoP-Nonce header in the same way that authorization servers do + as described in Sections 8 and 8.2. The error signaling is performed + as described in Section 7.1. Resource servers use an HTTP 401 + (Unauthorized) error code with an accompanying WWW-Authenticate: DPoP + value and DPoP-Nonce value to accomplish this. + + For example, in response to a resource request without a nonce when + the resource server requires one, the resource server can respond + with a DPoP-Nonce value such as the following to provide a nonce + value to include in the DPoP proof. The example below uses "\" line + wrapping per [RFC8792]. + + HTTP/1.1 401 Unauthorized + WWW-Authenticate: DPoP error="use_dpop_nonce", \ + error_description="Resource server requires nonce in DPoP proof" + DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v + + Figure 24: HTTP 401 Response to a Resource Request without a Nonce + + Note that the nonces provided by an authorization server and a + resource server are different and should not be confused with one + another since nonces will be only accepted by the server that issued + them. Likewise, should a client use multiple authorization servers + and/or resource servers, a nonce issued by any of them should be used + only at the issuing server. Developers should also be careful to not + confuse DPoP nonces with the OpenID Connect [OpenID.Core] ID Token + nonce. + +10. Authorization Code Binding to a DPoP Key + + Binding the authorization code issued to the client's proof-of- + possession key can enable end-to-end binding of the entire + authorization flow. This specification defines the dpop_jkt + authorization request parameter for this purpose. The value of the + dpop_jkt authorization request parameter is the JWK Thumbprint + [RFC7638] of the proof-of-possession public key using the SHA-256 + hash function, which is the same value as used for the jkt + confirmation method defined in Section 6.1. + + When a token request is received, the authorization server computes + the JWK Thumbprint of the proof-of-possession public key in the DPoP + proof and verifies that it matches the dpop_jkt parameter value in + the authorization request. If they do not match, it MUST reject the + request. + + An example authorization request using the dpop_jkt authorization + request parameter is shown below and uses "\" line wrapping per + [RFC8792]. + + GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz\ + &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb\ + &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM\ + &code_challenge_method=S256\ + &dpop_jkt=NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs HTTP/1.1 + Host: server.example.com + + Figure 25: Authorization Request Using the dpop_jkt Parameter + + Use of the dpop_jkt authorization request parameter is OPTIONAL. + Note that the dpop_jkt authorization request parameter MAY also be + used in combination with Proof Key for Code Exchange (PKCE) + [RFC7636], which is recommended by [SECURITY-TOPICS] as a + countermeasure to authorization code injection. The dpop_jkt + authorization request parameter only provides similar protections + when a unique DPoP key is used for each authorization request. + +10.1. DPoP with Pushed Authorization Requests + + When Pushed Authorization Requests (PARs) [RFC9126] are used in + conjunction with DPoP, there are two ways in which the DPoP key can + be communicated in the PAR request: + + * The dpop_jkt parameter can be used as described in Section 10 to + bind the issued authorization code to a specific key. In this + case, dpop_jkt MUST be included alongside other authorization + request parameters in the POST body of the PAR request. + * Alternatively, the DPoP header can be added to the PAR request. + In this case, the authorization server MUST check the provided + DPoP proof JWT as defined in Section 4.3. It MUST further behave + as if the contained public key's thumbprint was provided using + dpop_jkt, i.e., reject the subsequent token request unless a DPoP + proof for the same key is provided. This can help to simplify the + implementation of the client, as it can "blindly" attach the DPoP + header to all requests to the authorization server regardless of + the type of request. Additionally, it provides a stronger + binding, as the DPoP header contains a proof of possession of the + private key. + + Both mechanisms MUST be supported by an authorization server that + supports PAR and DPoP. If both mechanisms are used at the same time, + the authorization server MUST reject the request if the JWK + Thumbprint in dpop_jkt does not match the public key in the DPoP + header. + + Allowing both mechanisms ensures that clients using dpop_jkt do not + need to distinguish between front-channel and pushed authorization + requests, and at the same time, clients that only have one code path + for protecting all calls to authorization server endpoints do not + need to distinguish between requests to the PAR endpoint and the + token endpoint. + +11. Security Considerations + + In DPoP, the prevention of token replay at a different endpoint (see + Section 2) is achieved through authentication of the server per + [RFC6125] and the binding of the DPoP proof to a certain URI and HTTP + method. However, DPoP has a somewhat different nature of protection + than TLS-based methods such as OAuth Mutual TLS [RFC8705] or OAuth + Token Binding [TOKEN-BINDING] (see also Sections 11.1 and 11.7). + TLS-based mechanisms can leverage a tight integration between the TLS + layer and the application layer to achieve strong message integrity, + authenticity, and replay protection. + +11.1. DPoP Proof Replay + + If an adversary is able to get hold of a DPoP proof JWT, the + adversary could replay that token at the same endpoint (the HTTP + endpoint and method are enforced via the respective claims in the + JWTs). To limit this, servers MUST only accept DPoP proofs for a + limited time after their creation (preferably only for a relatively + brief period on the order of seconds or minutes). + + In the context of the target URI, servers can store the jti value of + each DPoP proof for the time window in which the respective DPoP + proof JWT would be accepted to prevent multiple uses of the same DPoP + proof. HTTP requests to the same URI for which the jti value has + been seen before would be declined. When strictly enforced, such a + single-use check provides a very strong protection against DPoP proof + replay, but it may not always be feasible in practice, e.g., when + multiple servers behind a single endpoint have no shared state. + + In order to guard against memory exhaustion attacks, a server that is + tracking jti values should reject DPoP proof JWTs with unnecessarily + large jti values or store only a hash thereof. + + Note: To accommodate for clock offsets, the server MAY accept DPoP + proofs that carry an iat time in the reasonably near future (on the + order of seconds or minutes). Because clock skews between servers + and clients may be large, servers MAY limit DPoP proof lifetimes by + using server-provided nonce values containing the time at the server + rather than comparing the client-supplied iat time to the time at the + server. Nonces created in this way yield the same result even in the + face of arbitrarily large clock skews. + + Server-provided nonces are an effective means for further reducing + the chances for successful DPoP proof replay. Unlike cryptographic + nonces, it is acceptable for clients to use the same nonce multiple + times and for the server to accept the same nonce multiple times. As + long as the jti value is tracked and duplicates are rejected for the + lifetime of the nonce, there is no additional risk of token replay. + +11.2. DPoP Proof Pre-generation + + An attacker in control of the client can pre-generate DPoP proofs for + specific endpoints arbitrarily far into the future by choosing the + iat value in the DPoP proof to be signed by the proof-of-possession + key. Note that one such attacker is the person who is the legitimate + user of the client. The user may pre-generate DPoP proofs to + exfiltrate from the machine possessing the proof-of-possession key + upon which they were generated and copy them to another machine that + does not possess the key. For instance, a bank employee might pre- + generate DPoP proofs on a bank computer and then copy them to another + machine for use in the future, thereby bypassing bank audit controls. + When DPoP proofs can be pre-generated and exfiltrated, all that is + actually being proved in DPoP protocol interactions is possession of + a DPoP proof -- not of the proof-of-possession key. + + Use of server-provided nonce values that are not predictable by + attackers can prevent this attack. By providing new nonce values at + times of its choosing, the server can limit the lifetime of DPoP + proofs, preventing pre-generated DPoP proofs from being used. When + server-provided nonces are used, possession of the proof-of- + possession key is being demonstrated -- not just possession of a DPoP + proof. + + The ath claim limits the use of pre-generated DPoP proofs to the + lifetime of the access token. Deployments that do not utilize the + nonce mechanism SHOULD NOT issue long-lived DPoP constrained access + tokens, preferring instead to use short-lived access tokens and + refresh tokens. Whilst an attacker could pre-generate DPoP proofs to + use the refresh token to obtain a new access token, they would be + unable to realistically pre-generate DPoP proofs to use a newly + issued access token. + +11.3. DPoP Nonce Downgrade + + A server MUST NOT accept any DPoP proofs without the nonce claim when + a DPoP nonce has been provided to the client. + +11.4. Untrusted Code in the Client Context + + If an adversary is able to run code in the client's execution + context, the security of DPoP is no longer guaranteed. Common issues + in web applications leading to the execution of untrusted code are + XSS and remote code inclusion attacks. + + If the private key used for DPoP is stored in such a way that it + cannot be exported, e.g., in a hardware or software security module, + the adversary cannot exfiltrate the key and use it to create + arbitrary DPoP proofs. The adversary can, however, create new DPoP + proofs as long as the client is online and uses these proofs + (together with the respective tokens) either on the victim's device + or on a device under the attacker's control to send arbitrary + requests that will be accepted by servers. + + To send requests even when the client is offline, an adversary can + try to pre-compute DPoP proofs using timestamps in the future and + exfiltrate these together with the access or refresh token. + + An adversary might further try to associate tokens issued from the + token endpoint with a key pair under the adversary's control. One + way to achieve this is to modify existing code, e.g., by replacing + cryptographic APIs. Another way is to launch a new authorization + grant between the client and the authorization server in an iframe. + This grant needs to be "silent", i.e., not require interaction with + the user. With code running in the client's origin, the adversary + has access to the resulting authorization code and can use it to + associate their own DPoP keys with the tokens returned from the token + endpoint. The adversary is then able to use the resulting tokens on + their own device even if the client is offline. + + Therefore, protecting clients against the execution of untrusted code + is extremely important even if DPoP is used. Besides secure coding + practices, Content Security Policy [W3C.CSP] can be used as a second + layer of defense against XSS. + +11.5. Signed JWT Swapping + + Servers accepting signed DPoP proof JWTs MUST verify that the typ + field is dpop+jwt in the headers of the JWTs to ensure that + adversaries cannot use JWTs created for other purposes. + +11.6. Signature Algorithms + + Implementers MUST ensure that only asymmetric digital signature + algorithms (such as ES256) that are deemed secure can be used for + signing DPoP proofs. In particular, the algorithm none MUST NOT be + allowed. + +11.7. Request Integrity + + DPoP does not ensure the integrity of the payload or headers of + requests. The DPoP proof only contains claims for the HTTP URI and + method, but not the message body or general request headers, for + example. + + This is an intentional design decision intended to keep DPoP simple + to use, but as described, it makes DPoP potentially susceptible to + replay attacks where an attacker is able to modify message contents + and headers. In many setups, the message integrity and + confidentiality provided by TLS is sufficient to provide a good level + of protection. + + Note: While signatures covering other parts of requests are out of + the scope of this specification, additional information to be signed + can be added into DPoP proofs. + +11.8. Access Token and Public Key Binding + + The binding of the access token to the DPoP public key, as specified + in Section 6, uses a cryptographic hash of the JWK representation of + the public key. It relies on the hash function having sufficient + second-preimage resistance so as to make it computationally + infeasible to find or create another key that produces to the same + hash output value. The SHA-256 hash function was used because it + meets the aforementioned requirement while being widely available. + + Similarly, the binding of the DPoP proof to the access token uses a + hash of that access token as the value of the ath claim in the DPoP + proof (see Section 4.2). This relies on the value of the hash being + sufficiently unique so as to reliably identify the access token. The + collision resistance of SHA-256 meets that requirement. + +11.9. Authorization Code and Public Key Binding + + Cryptographic binding of the authorization code to the DPoP public + key is specified in Section 10. This binding prevents attacks in + which the attacker captures the authorization code and creates a DPoP + proof using a proof-of-possession key other than the one held by the + client and redeems the authorization code using that DPoP proof. By + ensuring end to end that only the client's DPoP key can be used, this + prevents captured authorization codes from being exfiltrated and used + at locations other than the one to which the authorization code was + issued. + + Authorization codes can, for instance, be harvested by attackers from + places where the HTTP messages containing them are logged. Even when + efforts are made to make authorization codes one-time-use, in + practice, there is often a time window during which attackers can + replay them. For instance, when authorization servers are + implemented as scalable replicated services, some replicas may + temporarily not yet have the information needed to prevent replay. + DPoP binding of the authorization code solves these problems. + + If an authorization server does not (or cannot) strictly enforce the + single-use limitation for authorization codes and an attacker can + access the authorization code (and if PKCE is used, the + code_verifier), the attacker can create a forged token request, + binding the resulting token to an attacker-controlled key. For + example, using XSS, attackers might obtain access to the + authorization code and PKCE parameters. Use of the dpop_jkt + parameter prevents this attack. + + The binding of the authorization code to the DPoP public key uses a + JWK Thumbprint of the public key, just as the access token binding + does. The same JWK Thumbprint considerations apply. + +11.10. Hash Algorithm Agility + + The jkt confirmation method member, the ath JWT claim, and the + dpop_jkt authorization request parameter defined herein all use the + output of the SHA-256 hash function as their value. The use of a + single hash function by this specification was intentional and aimed + at simplicity and avoidance of potential security and + interoperability issues arising from common mistakes implementing and + deploying parameterized algorithm agility schemes. However, the use + of a different hash function is not precluded if future circumstances + change and make SHA-256 insufficient for the requirements of this + specification. Should that need arise, it is expected that a short + specification will be produced that updates this one. Using the + output of an appropriate hash function as the value, that + specification will likely define a new confirmation method member, a + new JWT claim, and a new authorization request parameter. These + items will be used in place of, or alongside, their respective + counterparts in the same message structures and flows of the larger + protocol defined by this specification. + +11.11. Binding to Client Identity + + In cases where DPoP is used with client authentication, it is only + bound to authentication by being coincident in the same TLS tunnel. + Since the DPoP proof is not directly bound to the authentication + cryptographically, it's possible that the authentication or the DPoP + messages were copied into the tunnel. While including the URI in the + DPoP can partially mitigate some of this risk, modifying the + authentication mechanism to provide cryptographic binding between + authentication and DPoP could provide better protection. However, + providing additional binding with authentication through the + modification of authentication mechanisms or other means is beyond + the scope of this specification. + +12. IANA Considerations + +12.1. OAuth Access Token Types Registration + + IANA has registered the following access token type in the "OAuth + Access Token Types" registry [IANA.OAuth.Params] established by + [RFC6749]. + + Name: DPoP + + Additional Token Endpoint Response Parameters: (none) + + HTTP Authentication Scheme(s): DPoP + + Change Controller: IETF + + Reference: RFC 9449 + +12.2. OAuth Extensions Error Registration + + IANA has registered the following error values in the "OAuth + Extensions Error" registry [IANA.OAuth.Params] established by + [RFC6749]. + + Invalid DPoP proof: + + Name: invalid_dpop_proof + + Usage Location: token error response, resource access error + response + + Protocol Extension: Demonstrating Proof of Possession (DPoP) + + Change Controller: IETF + + Reference: RFC 9449 + + Use DPoP nonce: + + Name: use_dpop_nonce + + Usage Location: token error response, resource access error + response + + Protocol Extension: Demonstrating Proof of Possession (DPoP) + + Change Controller: IETF + + Reference: RFC 9449 + +12.3. OAuth Parameters Registration + + IANA has registered the following authorization request parameter in + the "OAuth Parameters" registry [IANA.OAuth.Params] established by + [RFC6749]. + + Name: dpop_jkt + + Parameter Usage Location: authorization request + + Change Controller: IETF + + Reference: Section 10 of RFC 9449 + +12.4. HTTP Authentication Schemes Registration + + IANA has registered the following scheme in the "HTTP Authentication + Schemes" registry [IANA.HTTP.AuthSchemes] established by [RFC9110], + Section 16.4.1. + + Authentication Scheme Name: DPoP + + Reference: Section 7.1 of RFC 9449 + +12.5. Media Type Registration + + IANA has registered the application/dpop+jwt media type [RFC2046] in + the "Media Types" registry [IANA.MediaTypes] in the manner described + in [RFC6838], which is used to indicate that the content is a DPoP + JWT. + + Type name: application + + Subtype name: dpop+jwt + + Required parameters: n/a + + Optional parameters: n/a + + Encoding considerations: binary. A DPoP JWT is a JWT; JWT values + are encoded as a series of base64url-encoded values (some of which + may be the empty string) separated by period ('.') characters. + + Security considerations: See Section 11 of RFC 9449 + + Interoperability considerations: n/a + + Published specification: RFC 9449 + + Applications that use this media type: Applications using RFC 9449 + for application-level proof of possession + + Fragment identifier considerations: n/a + + Additional information: + + File extension(s): n/a + Macintosh file type code(s): n/a + + Person & email address to contact for further information: Michael + B. Jones, michael_b_jones@hotmail.com + + Intended usage: COMMON + + Restrictions on usage: none + + Author: Michael B. Jones, michael_b_jones@hotmail.com + + Change controller: IETF + +12.6. JWT Confirmation Methods Registration + + IANA has registered the following JWT cnf member value in the "JWT + Confirmation Methods" registry [IANA.JWT] established by [RFC7800]. + + Confirmation Method Value: jkt + + Confirmation Method Description: JWK SHA-256 Thumbprint + + Change Controller: IETF + + Reference: Section 6 of RFC 9449 + +12.7. JSON Web Token Claims Registration + + IANA has registered the following Claims in the "JSON Web Token + Claims" registry [IANA.JWT] established by [RFC7519]. + + HTTP method: + + Claim Name: htm + + Claim Description: The HTTP method of the request + + Change Controller: IETF + + Reference: Section 4.2 of RFC 9449 + + HTTP URI: + + Claim Name: htu + + Claim Description: The HTTP URI of the request (without query and + fragment parts) + + Change Controller: IETF + + Reference: Section 4.2 of RFC 9449 + + Access token hash: + + Claim Name: ath + + Claim Description: The base64url-encoded SHA-256 hash of the + ASCII encoding of the associated access token's value + + Change Controller: IETF + + Reference: Section 4.2 of RFC 9449 + +12.7.1. "nonce" Registration Update + + The Internet Security Glossary [RFC4949] provides a useful definition + of nonce as a random or non-repeating value that is included in data + exchanged by a protocol, usually for the purpose of guaranteeing + liveness and thus detecting and protecting against replay attacks. + + However, the initial registration of the nonce claim by [OpenID.Core] + used language that was contextually specific to that application, + which was potentially limiting to its general applicability. + + Therefore, IANA has updated the entry for nonce in the "JSON Web + Token Claims" registry [IANA.JWT] with an expanded definition to + reflect that the claim can be used appropriately in other contexts + and with the addition of this document as a reference, as follows. + + Claim Name: nonce + + Claim Description: Value used to associate a Client session with an + ID Token (MAY also be used for nonce values in other applications + of JWTs) + + Change Controller: OpenID Foundation Artifact Binding Working Group, + openid-specs-ab@lists.openid.net + + Specification Document(s): Section 2 of [OpenID.Core] and RFC 9449 + +12.8. Hypertext Transfer Protocol (HTTP) Field Name Registration + + IANA has registered the following HTTP header fields, as specified by + this document, in the "Hypertext Transfer Protocol (HTTP) Field Name + Registry" [IANA.HTTP.Fields] established by [RFC9110]: + + DPoP: + + Field Name: DPoP + + Status: permanent + + Reference: RFC 9449 + + DPoP-Nonce: + + Field Name: DPoP-Nonce + + Status: permanent + + Reference: RFC 9449 + +12.9. OAuth Authorization Server Metadata Registration + + IANA has registered the following value in the "OAuth Authorization + Server Metadata" registry [IANA.OAuth.Params] established by + [RFC8414]. + + Metadata Name: dpop_signing_alg_values_supported + + Metadata Description: JSON array containing a list of the JWS + algorithms supported for DPoP proof JWTs + + Change Controller: IETF + + Reference: Section 5.1 of RFC 9449 + +12.10. OAuth Dynamic Client Registration Metadata + + IANA has registered the following value in the IANA "OAuth Dynamic + Client Registration Metadata" registry [IANA.OAuth.Params] + established by [RFC7591]. + + Client Metadata Name: dpop_bound_access_tokens + + Client Metadata Description: Boolean value specifying whether the + client always uses DPoP for token requests + + Change Controller: IETF + + Reference: Section 5.2 of RFC 9449 + +13. References + +13.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, + . + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + . + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March + 2011, . + + [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", + RFC 6749, DOI 10.17487/RFC6749, October 2012, + . + + [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization + Framework: Bearer Token Usage", RFC 6750, + DOI 10.17487/RFC6750, October 2012, + . + + [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web + Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May + 2015, . + + [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, + DOI 10.17487/RFC7517, May 2015, + . + + [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token + (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, + . + + [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) + Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September + 2015, . + + [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- + Possession Key Semantics for JSON Web Tokens (JWTs)", + RFC 7800, DOI 10.17487/RFC7800, April 2016, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [SHS] National Institute of Standards and Technology, "Secure + Hash Standard (SHS)", FIPS PUB 180-4, + DOI 10.6028/NIST.FIPS.180-4, August 2015, + . + +13.2. Informative References + + [BREACH] CVE, "CVE-2013-3587", . + + [Cloudbleed] + Graham-Cumming, J., "Incident report on memory leak caused + by Cloudflare parser bug", February 2017, + . + + [CRIME] CVE, "CVE-2012-4929", . + + [GitHub.Tokens] + Hanley, M., "Security alert: Attack campaign involving + stolen OAuth user tokens issued to two third-party + integrators", April 2022, . + + [Heartbleed] + "CVE-2014-0160", . + + [IANA.HTTP.AuthSchemes] + IANA, "Hypertext Transfer Protocol (HTTP) Authentication + Scheme Registry", + . + + [IANA.HTTP.Fields] + IANA, "Hypertext Transfer Protocol (HTTP) Field Name + Registry", + . + + [IANA.JOSE.ALGS] + IANA, "JSON Web Signature and Encryption Algorithms", + . + + [IANA.JWT] IANA, "JSON Web Token Claims", + . + + [IANA.MediaTypes] + IANA, "Media Types", + . + + [IANA.OAuth.Params] + IANA, "OAuth Parameters", + . + + [OpenID.Core] + Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and + C. Mortimore, "OpenID Connect Core 1.0 incorporating + errata set 1", November 2014, + . + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + DOI 10.17487/RFC2046, November 1996, + . + + [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally + Unique IDentifier (UUID) URN Namespace", RFC 4122, + DOI 10.17487/RFC4122, July 2005, + . + + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", + FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, + . + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + . + + [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, . + + [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, + . + + [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, + . + + [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", + RFC 7662, DOI 10.17487/RFC7662, October 2015, + . + + [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 + Authorization Server Metadata", RFC 8414, + DOI 10.17487/RFC8414, June 2018, + . + + [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, + . + + [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource + Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, + February 2020, . + + [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best + Current Practices", BCP 225, RFC 8725, + DOI 10.17487/RFC8725, February 2020, + . + + [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, + "Handling Long Lines in Content of Internet-Drafts and + RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, + . + + [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Semantics", STD 97, RFC 9110, + DOI 10.17487/RFC9110, June 2022, + . + + [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, + . + + [SECURITY-TOPICS] + Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, + "OAuth 2.0 Security Best Current Practice", Work in + Progress, Internet-Draft, draft-ietf-oauth-security- + topics-23, 5 June 2023, + . + + [TOKEN-BINDING] + Jones, M., Campbell, B., Bradley, J., and W. Denniss, + "OAuth 2.0 Token Binding", Work in Progress, Internet- + Draft, draft-ietf-oauth-token-binding-08, 19 October 2018, + . + + [W3C.CSP] West, M., "Content Security Policy Level 3", W3C Working + Draft, July 2023, . + + [W3C.WebCryptoAPI] + Watson, M., "Web Cryptography API", W3C Recommendation, + January 2017, + . + + [WHATWG.Fetch] + WHATWG, "Fetch Living Standard", July 2023, + . + +Acknowledgements + + We would like to thank Brock Allen, Annabelle Backman, Dominick + Baier, Spencer Balogh, Vittorio Bertocci, Jeff Corrigan, Domingos + Creado, Philippe De Ryck, Andrii Deinega, William Denniss, Vladimir + Dzhuvinov, Mike Engan, Nikos Fotiou, Mark Haine, Dick Hardt, Joseph + Heenan, Bjorn Hjelm, Jacob Ideskog, Jared Jennings, Benjamin Kaduk, + Pieter Kasselman, Neil Madden, Rohan Mahy, Karsten Meyer zu + Selhausen, Nicolas Mora, Steinar Noem, Mark Nottingham, Rob Otto, + Aaron Parecki, Michael Peck, Roberto Polli, Paul Querna, Justin + Richer, Joseph Salowey, Rifaat Shekh-Yusef, Filip Skokan, Dmitry + Telegin, Dave Tonge, Jim Willeke, and others for their valuable + input, feedback, and general support of this work. + + This document originated from discussions at the 4th OAuth Security + Workshop in Stuttgart, Germany. We thank the organizers of this + workshop (Ralf Küsters and Guido Schmitz). + +Authors' Addresses + + Daniel Fett + Authlete + Email: mail@danielfett.de + + + Brian Campbell + Ping Identity + Email: bcampbell@pingidentity.com + + + John Bradley + Yubico + Email: ve7jtb@ve7jtb.com + + + Torsten Lodderstedt + Tuconic + Email: torsten@lodderstedt.net + + + Michael Jones + Self-Issued Consulting + Email: michael_b_jones@hotmail.com + URI: https://self-issued.info/ + + + David Waite + Ping Identity + Email: david@alkaline-solutions.com -- cgit v1.2.3