]> Okta

aaron@parecki.com

Ping Identity

bcampbell@pingidentity.com

Security Web Authorization Protocol oauth device dpop The OAuth 2.0 Device Authorization Grant is an authorization flow for devices with limited input capabilities. Demonstrating Proof of Possession (DPoP) is a mechanism to sender-constrain OAuth 2.0 tokens. This document describes how to use DPoP with the Device Authorization Grant to provide a higher level of security for clients. It binds the DPoP key to the entire transaction, from the initial device authorization request through the lifetime of the issued tokens. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The OAuth 2.0 Device Authorization Grant provides a mechanism for devices that lack a browser or have constrained input capabilities to obtain an OAuth access token. The flow involves the device polling the token endpoint while the user authorizes the request on a separate, more capable device. OAuth 2.0 Demonstrating Proof of Possession (DPoP) introduces a mechanism for sender-constraining access and refresh tokens. It works by requiring the client to prove possession of a cryptographic key with every request, binding the tokens to that key. explicitly details its application with Pushed Authorization Requests (PAR) , a flow that, like the Device Authorization Grant, begins with a direct back-channel request from the client to the authorization server. This specification formally defines the mechanism of using DPoP with the Device Authorization Grant. By requiring a DPoP proof at the beginning of the flow, the authorization server can bind the device_code to a specific public key. This ensures that only the client possessing the corresponding private key can complete the flow by polling the token endpoint, thereby preventing a stolen device_code from being redeemed by a malicious actor. The resulting access and refresh tokens are also DPoP-bound, mitigating the risk of token leakage.

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 when, and only when, they appear in all capitals, as shown here.

Protocol Flow The overall Device Authorization Grant flow remains as defined in , with the addition of the DPoP header and associated validation logic at two key steps: the device authorization request and the device access token (polling) request.

Device Authorization Request To initiate the flow, the client makes a POST request to the device authorization endpoint as specified in Section 3.1 of . When using DPoP, this request MUST include a DPoP header field containing a valid DPoP proof JWT as defined in Section 4 of . The authorization server MUST validate the DPoP proof according to the rules in Section 4.3 of . If the DPoP proof is invalid, the authorization server MUST return an error response, and it is RECOMMENDED that this be a 400 Bad Request with an error code of invalid_dpop_proof. If the DPoP proof is valid, the authorization server proceeds as defined in Section 3.2 of by generating a device_code, user_code, etc. In addition, the authorization server MUST associate the public key from the jwk header of the DPoP proof with the generated device_code and store this association for later verification. For example:

Device Access Token Request After the user authorizes the request, the client begins polling the token endpoint as described in Section 3.4 of . Each access token request (polling request) using the urn:ietf:params:oauth:grant-type:device_code grant type MUST include a DPoP header with DPoP proof JWT. Upon receiving a token request, the authorization server MUST perform the following steps in addition to the processing described in :

• Look up the data associated with the received device_code.
• Retrieve the public key that was associated with the device_code during the device authorization request.
• Validate the DPoP proof JWT in the DPoP header of the current polling request per Section 4.3 of .
• Verify that the public key in the jwk header of the DPoP proof matches the public key associated with the device_code.

If any of these checks fail, the authorization server MUST reject the request with an invalid_grant error. If all checks are successful and the user has approved the grant, the authorization server issues an access token and an optional refresh token. The issued access token MUST be bound to the DPoP public key, and the access token response MUST include "token_type": "DPoP"`, as specified in Section 5 of . Any issued refresh token MUST also be bound to the same DPoP public key.

Security Considerations

Device Code Binding The primary security benefit of this specification is the binding of the DPoP key to the device_code at the start of the authorization flow. In the standard Device Authorization Grant, an attacker who obtains a valid device_code (e.g., through log inspection or a compromised device) can start polling the token endpoint. If the attacker completes the user authorization step (e.g., via a phishing attack that tricks the user into entering the user_code), they can obtain the access token. By binding the device_code to the client's DPoP key, this attack is prevented. The attacker's polling requests to the token endpoint will fail because they cannot produce a valid DPoP proof signed with the private key corresponding to the public key bound to the device_code. Only the legitimate client can successfully redeem the device_code.

Client Impersonation This specification does not prevent a malicious application on a device from initiating a device flow and using DPoP correctly. It protects the integrity of a single authorization flow by ensuring the same cryptographic identity (the DPoP key pair) is used throughout. It is not a client authentication mechanism. As such, the security considerations for public clients in Section 5 of and remain relevant.

General DPoP Considerations All security considerations from apply, including those regarding DPoP proof replay, nonce usage, signature algorithms, and the need to protect the private key on the client device.

IANA Considerations This document has no IANA actions.

References Normative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device. 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. This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.

Acknowledgments The authors would like to thank Emelia Smith for her reply on social media suggesting that this document should exist.

Document History [[ To be removed from the final specification ]] -00

• Initial draft