]> Self-Issued Consulting

michael_b_jones@hotmail.com https://self-issued.info/

Disney

charliemortimore@gmail.com

Ping Identity

bcampbell@pingidentity.com

Security Web Authorization Protocol OAuth audience JWT client authentication TODO Abstract 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 TODO Introduction that mentions and mayby a bit of context/history and motivation for this doc that will update/patch , , and .

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.

The Updates

JWT Client Authentication aud must solely contain the authorization server's issuer identifier. Explicit typing of the Client Authentication JWT as a good thing to do in general but also allowing for observerability and controle during the transition period.

SAML Client Authentication This hasn't been used in practice and this document will say not to ever use it going forward.

Assertion Based Authorization Grants Advise client to ensure that the audience of the assertion makes sense with respect to where it’s being sent, which might Token endpoint URL, Issuer Identifier, SAML Entity ID.

Security Considerations This specification tightens assertion audience handling directives as a mitigation for potential attacks arising from the exploitation of ambiguities in authorization server identification allowed by , , , and compounded by .

IANA Considerations

OAuth URI Registry Updates IANA is requested to update the "OAuth URI" registry for the following entriest to add [[this specfication]] as an addtional refernce:

• urn:ietf:params:oauth:grant-type:jwt-bearer
• urn:ietf:params:oauth:client-assertion-type:jwt-bearer
• urn:ietf:params:oauth:grant-type:saml2-bearer
• urn:ietf:params:oauth:client-assertion-type:saml2-bearer

Media Type Registration Registration is requested for the following media type in the IANA "Media Types" registry in the manner described in . TODO for application/client-authentication+jwt

References Normative References This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. 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. 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] 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 IANA n.d. IANA n.d. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. Self-Issued Consulting Ping Identity Disney This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication.

Document History

• [[ to be removed by the RFC Editor before publication as an RFC ]]

draft-campbell-oauth-rfc7523redux-00:

• Initial draft proposing a simipler and less distrupitve alternative to

Acknowledgments The authors would like to acknowledge the following people for their contributions to this document: John Bradley, Ralph Bragg, Joseph Heenan, Pedram Hosseyni, Aaron Parecki, Filip Skokan, and Tim Würtele.