draft-ietf-oauth-dpop-16
Light
Dark
Auto
Internet-Draft<br>OAuth DPoP<br>April 2023
Fett, et al.<br>Expires 15 October 2023<br>[Page]
Workgroup:<br>Web Authorization Protocol<br>Internet-Draft:<br>draft-ietf-oauth-dpop-16<br>Published:
13 April 2023
Intended Status:<br>Standards Track<br>Expires:<br>15 October 2023<br>Authors:
D. Fett
Authlete
B. Campbell
Ping Identity
J. Bradley
Yubico
T. Lodderstedt
yes.com
M. Jones
independent
D. Waite
Ping Identity
OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)
Abstract
This document describes a mechanism for sender-constraining OAuth 2.0<br>tokens via a proof-of-possession mechanism on the application level.<br>This mechanism allows for the detection of replay attacks with access and refresh<br>tokens.¶
Status of This Memo
This Internet-Draft is submitted in full conformance with the<br>provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task<br>Force (IETF). Note that other groups may also distribute working<br>documents as Internet-Drafts. The list of current Internet-Drafts is<br>at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months<br>and may be updated, replaced, or obsoleted by other documents at any<br>time. It is inappropriate to use Internet-Drafts as reference<br>material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 15 October 2023.¶
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the<br>document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal<br>Provisions Relating to IETF Documents<br>(https://trustee.ietf.org/license-info) in effect on the date of<br>publication of this document. Please review these documents<br>carefully, as they describe your rights and restrictions with<br>respect to this document. Code Components extracted from this<br>document must include Revised BSD License text as described in<br>Section 4.e of the Trust Legal Provisions and are provided without<br>warranty as described in the Revised BSD License.¶
Table of Contents
1. Introduction
DPoP (for Demonstrating Proof-of-Possession at the Application Layer)<br>is an application-level mechanism for<br>sender-constraining OAuth [RFC6749] access and refresh tokens. It enables a client to<br>prove the possession of a public/private key pair by including<br>a DPoP header in an HTTP request. The value of the header is a JSON Web Token<br>(JWT) [RFC7519] that enables the authorization<br>server to bind issued tokens to the public part of a client's<br>key pair. Recipients of such tokens are then able to verify the binding of the<br>token to the key pair that the client has demonstrated that it holds via<br>the DPoP header, thereby providing some assurance that the client presenting<br>the token also possesses the private key.<br>In other words, the legitimate presenter of the token is constrained to be<br>the sender that holds and can prove possession of the private part of the<br>key pair.¶
The mechanism specified herein can be used in cases where other<br>methods of sender-constraining tokens that utilize elements of the underlying<br>secure transport layer, such as [RFC8705] or [I-D.ietf-oauth-token-binding],<br>are not available or desirable. For example, due to a sub-par user experience<br>of TLS client authentication in user agents and a lack of support for HTTP token<br>binding, neither mechanism can be used if an OAuth client is an application that<br>is dynamically downloaded and executed in a web browser (sometimes referred to as a<br>"single-page application"). Applications installed<br>and run directly on a user's device are another example well positioned to benefit<br>from DPoP-bound tokens to guard against misuse of tokens by a compromised<br>or malicious resource. Such applications often have dedicated protected storage<br>for cryptographic keys.¶
DPoP can be used to sender-constrain access tokens regardless of the<br>client authentication method employed, but DPoP itself is not used for client authentication.<br>DPoP can also be used to sender-constrain refresh tokens issued to public clients<br>(those without authentication credentials associated with the client_id).¶
1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL<br>NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",<br>"MAY", and "OPTIONAL" in this document are to be interpreted as<br>described in BCP 14 [RFC2119] [RFC8174] when, and only when, they<br>appear in all capitals, as shown here.¶
This specification uses the Augmented Backus-Naur Form (ABNF) notation<br>of [RFC5234].¶
This specification uses the terms "access token", "refresh token",<br>"authorization server", "resource server", "authorization endpoint",<br>"authorization request", "authorization response", "token endpoint",<br>"grant type", "access token request", "access token response",<br>"client", "public client", and "confidential client" defined by The OAuth 2.0 Authorization Framework [RFC6749].¶
The...