OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
RFC 8705
Document | Type | RFC - Proposed Standard (February 2020; No errata) | |
---|---|---|---|
Authors | Brian Campbell , John Bradley , Nat Sakimura , Torsten Lodderstedt | ||
Last updated | 2020-03-09 | ||
Replaces | draft-campbell-oauth-mtls | ||
Stream | IETF | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Rifaat Shekh-Yusef | ||
Shepherd write-up | Show (last changed 2019-08-12) | ||
IESG | IESG state | RFC 8705 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Roman Danyliw | ||
Send notices to | Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack |
Internet Engineering Task Force (IETF) B. Campbell Request for Comments: 8705 Ping Identity Category: Standards Track J. Bradley ISSN: 2070-1721 Yubico N. Sakimura Nomura Research Institute T. Lodderstedt YES.com AG February 2020 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens Abstract This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. 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/rfc8705. Copyright Notice Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 1.1. Requirements Notation and Conventions 1.2. Terminology 2. Mutual TLS for OAuth Client Authentication 2.1. PKI Mutual-TLS Method 2.1.1. PKI Method Metadata Value 2.1.2. Client Registration Metadata 2.2. Self-Signed Certificate Mutual-TLS Method 2.2.1. Self-Signed Method Metadata Value 2.2.2. Client Registration Metadata 3. Mutual-TLS Client Certificate-Bound Access Tokens 3.1. JWT Certificate Thumbprint Confirmation Method 3.2. Confirmation Method for Token Introspection 3.3. Authorization Server Metadata 3.4. Client Registration Metadata 4. Public Clients and Certificate-Bound Tokens 5. Metadata for Mutual-TLS Endpoint Aliases 6. Implementation Considerations 6.1. Authorization Server 6.2. Resource Server 6.3. Certificate Expiration and Bound Access Tokens 6.4. Implicit Grant Unsupported 6.5. TLS Termination 7. Security Considerations 7.1. Certificate-Bound Refresh Tokens 7.2. Certificate Thumbprint Binding 7.3. TLS Versions and Best Practices 7.4. X.509 Certificate Spoofing 7.5. X.509 Certificate Parsing and Validation Complexity 8. Privacy Considerations 9. IANA Considerations 9.1. JWT Confirmation Methods Registration 9.2. Authorization Server Metadata Registration 9.3. Token Endpoint Authentication Method Registration 9.4. Token Introspection Response Registration 9.5. Dynamic Client Registration Metadata Registration 10. References 10.1. Normative References 10.2. Informative References Appendix A. Example "cnf" Claim, Certificate, and JWK Appendix B. Relationship to Token Binding Acknowledgements Authors' Addresses 1. Introduction The OAuth 2.0 Authorization Framework [RFC6749] enables third-party client applications to obtain delegated access to protected resources. In the prototypical abstract OAuth flow, illustrated in Figure 1, the client obtains an access token from an entity known as an authorization server and then uses that token when accessing protected resources, such as HTTPS APIs. +--------+ +---------------+Show full document text