Archive for the 'OAuth' Category

August 21, 2018
It’s Time for Token Binding

IETF logoCheck out Alex Simons’ and Pamela Dingle’s blog post “It’s Time for Token Binding”. Now that the IETF Token Binding specs are essentially done, it’s time to ask those who write TLS software you use to ship Token Binding support soon, if they haven’t already done so.

Token Binding in a nutshell: When an attacker steals a bearer token sent over TLS, he can use it; when an attacker steals a Token Bound token, it’s useless to him.

June 28, 2018
OAuth 2.0 Authorization Server Metadata is now RFC 8414

OAuth logoThe OAuth 2.0 Authorization Server Metadata specification is now RFC 8414. The abstract describes the specification as:

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.

The specification defines a JSON metadata representation for OAuth 2.0 authorization servers that is compatible with OpenID Connect Discovery 1.0. This specification is a true instance of standardizing existing practice. OAuth 2.0 deployments have been using the OpenID Connect metadata format to describe their endpoints and capabilities for years. This RFC makes this existing practice a standard.

Having a standard OAuth metadata format makes it easier for OAuth clients to configure connections to OAuth authorization servers. See https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata for the initial set of registered metadata values.

Thanks to all of you who helped make this standard a reality!

June 1, 2018
OAuth Device Flow spec addressing initial IETF last call feedback

OAuth logoThe OAuth Device Flow specification (full name “OAuth 2.0 Device Flow for Browserless and Input Constrained Devices”) has been updated to address comments received to date from the IETF last call. Thanks to William Denniss for taking the pen for this set of revisions. Changes were:

  • Added a missing definition of access_denied for use on the token endpoint.
  • Corrected text documenting which error code should be returned for expired tokens (it’s “expired_token”, not “invalid_grant”).
  • Corrected section reference to RFC 8252 (the section numbers had changed after the initial reference was made).
  • Fixed line length of one diagram (was causing xml2rfc warnings).
  • Added line breaks so the URN grant_type is presented on an unbroken line.
  • Typos fixed and other stylistic improvements.

The specification is available at:

An HTML-formatted version is also available at:

May 9, 2018
JWT BCP updates addressing WGLC feedback

OAuth logoThe JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to address the Working Group Last Call (WGLC) feedback received. Thanks to Neil Madden for his numerous comments and to Carsten Bormann and Brian Campbell for their reviews.

Assuming the chairs concur, the next step should be to request publication.

The specification is available at:

An HTML-formatted version is also available at:

April 24, 2018
Late-breaking changes to OAuth Token Exchange syntax

OAuth logoThe syntax of two JWT claims registered by the OAuth Token Exchange specification has been changed as a result of developer feedback. Developers pointed out that the OAuth Token Introspection specification [RFC 7662] uses a “scope” string to represent scope values, whereas Token Exchange was defining an array-valued “scp” claim to represent scope values. The former also uses a “client_id” element to represent OAuth Client ID values, whereas the latter was using a “cid” claim for the same purpose.

After consulting with the working group, the OAuth Token Exchange claim names have been changed to “scope” and “client_id”. Thanks to Torsten Lodderstedt for pointing out the inconsistencies and to Brian Campbell for seeking consensus and making the updates.

The specification is available at:

An HTML-formatted version is also available at:

April 23, 2018
OAuth Device Flow spec addressing Area Director comments

OAuth logoThe OAuth 2.0 Device Flow for Browserless and Input Constrained Devices specification has been updated to address feedback by Security Area Director Eric Rescorla about the potential of a confused deputy attack. Thanks to John Bradley for helping work out the response to Eric and to William Denniss for reviewing and publishing the changes to the draft.

The specification is available at:

An HTML-formatted version is also available at:

March 28, 2018
What Does Logout Mean?

OAuth logoDigital identity systems almost universally support end-users logging into applications and many also support logging out of them. But while login is reasonable well understood, there are many different kinds of semantics for “logout” in different use cases and a wide variety of mechanisms for effecting logouts.

I led a discussion on the topic “What Does Logout Mean?” at the 2018 OAuth Security Workshop in Trento, Italy, which was held the week before IETF 101, to explore this topic. The session was intentionally a highly interactive conversation, gathering information from the experts at the workshop to expand our collective understanding of the topic. Brock Allen – a practicing application security architect (and MVP for ASP.NET/IIS) – significantly contributed to the materials used to seed the discussion. And Nat Sakimura took detailed notes to record what we learned during the discussion.

Feedback on the discussion was uniformly positive. It seemed that all the participants learned things about logout use cases, mechanisms, and limitations that they previously hadn’t previously considered.

Materials related to the session are:

March 23, 2018
JWT BCP draft adding Nested JWT guidance

OAuth logoThe JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to add guidance on how to explicitly type Nested JWTs. Thanks to Brian Campbell for suggesting the addition.

The specification is available at:

An HTML-formatted version is also available at:

March 4, 2018
OAuth Authorization Server Metadata spec addressing additional IESG feedback

OAuth logoThe OAuth Authorization Server Metadata specification has been updated to address additional IESG feedback. The only change was to clarify the meaning of “case-insensitive”, as suggested by Alexey Melnikov.

The specification is available at:

An HTML-formatted version is also available at:

February 28, 2018
Security Event Token (SET) spec addressing 2nd WGLC and shepherd comments

IETF logoA new draft of the Security Event Token (SET) specification has published that addresses review comments from the second Working Group Last Call and shepherd comments from Yaron Sheffer. Changes were:

  • Changed “when the event was issued” to “when the SET was issued” in the “iat” description, as suggested by Annabelle Backman.
  • Applied editorial improvements that improve the consistency of the specification that were suggested by Annabelle Backman, Marius Scurtescu, and Yaron Sheffer.

The specification is available at:

An HTML-formatted version is also available at:

February 27, 2018
OAuth Authorization Server Metadata spec addressing IESG feedback

OAuth logoThe OAuth Authorization Server Metadata specification has been updated to address feedback received from IESG members. Changes were:

  • Revised the transformation between the issuer identifier and the authorization server metadata location to conform to BCP 190, as suggested by Adam Roach.
  • Defined the characters allowed in registered metadata names and values, as suggested by Alexey Melnikov.
  • Changed to using the RFC 8174 boilerplate instead of the RFC 2119 boilerplate, as suggested by Ben Campbell.
  • Acknowledged additional reviewers.

The specification is available at:

An HTML-formatted version is also available at:

January 19, 2018
OAuth Token Exchange spec addressing Area Director feedback

OAuth logoA new draft of the OAuth 2.0 Token Exchange specification has been published that addresses feedback from Security Area Director Eric Rescorla. The acknowledgements were also updated. Thanks to Brian Campbell for doing the editing for this version.

The specification is available at:

An HTML-formatted version is also available at:

November 30, 2017
OAuth Token Exchange spec adding URIs for SAML assertions

OAuth logoA new draft of the OAuth 2.0 Token Exchange specification has been published that adds token type URIs for SAML 1.1 and SAML 2.0 assertions. They were added in response to actual developer use cases. These parallel the existing token type URI for JWT tokens.

The specification is available at:

An HTML-formatted version is also available at:

November 15, 2017
OAuth Authorization Server Metadata spec incorporating IETF last call feedback

OAuth logoThe OAuth Authorization Server Metadata specification has been updated to incorporate feedback received during IETF last call. Thanks to Shwetha Bhandari, Brian Carpenter, Donald Eastlake, Dick Hardt, and Mark Nottingham for their reviews. See the Document History appendix for clarifications applied. No normative changes were made.

The specification is available at:

An HTML-formatted version is also available at:

October 26, 2017
OAuth and OpenID Connect Token Binding specs updated

OAuth logoThe OAuth 2.0 Token Binding specification has been updated to enable Token Binding of JWT Authorization Grants and JWT Client Authentication. The discussion of phasing in Token Binding was improved and generalized. See the Document History section for other improvements applied.

The specification is available at:

An HTML-formatted version is also available at:

An update to the closely-related OpenID Connect Token Bound Authentication 1.0 specification was also simultaneously published. Its discussion of phasing in Token Binding was correspondingly updated.

The OpenID Connect Token Binding specification is available in HTML and text versions at:

Thanks to Brian Campbell for doing the bulk of the editing for both sets of revisions.

September 7, 2017
OAuth Authorization Server Metadata spec incorporating Area Director feedback

OAuth logoThe OAuth Authorization Server Metadata specification has been updated to incorporate feedback from Security Area Director Eric Rescorla. Thanks to EKR for his useful review. A number of defaults and restrictions are now better specified.

The specification is available at:

An HTML-formatted version is also available at:

July 27, 2017
Initial working group draft of JSON Web Token Best Current Practices

OAuth logoI’m happy to announce that the OAuth working group adopted the JSON Web Token Best Current Practices (JWT BCP) draft that Yaron Sheffer, Dick Hardt, and I had worked on, following discussions at IETF 99 in Prague and on the working group mailing list.

The specification is available at:

An HTML-formatted version is also available at:

July 4, 2017
JSON Web Token Best Current Practices draft describing Explicit Typing

OAuth logoThe JWT BCP draft has been updated to describe the use of explicit typing of JWTs as one of the ways to prevent confusion among different kinds of JWTs. This is accomplished by including an explicit type for the JWT in the “typ” header parameter. For instance, the Security Event Token (SET) specification now uses the “application/secevent+jwt” content type to explicitly type SETs.

The specification is available at:

An HTML-formatted version is also available at:

June 16, 2017
Authentication Method Reference Values is now RFC 8176

IETF logoThe Authentication Method Reference Values specification is now RFC 8176. The abstract describes the specification as:

The amr (Authentication Methods References) claim is defined and registered in the IANA “JSON Web Token Claims” registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values.

The specification defines and registers some Authentication Method Reference values such as the following, which are already in use by some Google and Microsoft products and OpenID specifications:

  • face” – Facial recognition
  • fpt” – Fingerprint
  • hwk” – Proof-of-possession of a hardware-secured key
  • otp” – One-time password
  • pin” – Personal Identification Number
  • pwd” – Password
  • swk” – Proof-of-possession of a software-secured key
  • sms” – Confirmation using SMS
  • user” – User presence test
  • wia” – Windows Integrated Authentication

See https://www.iana.org/assignments/authentication-method-reference-values/ for the full list of registered values.

Thanks to Caleb Baker, Phil Hunt, Tony Nadalin, and William Denniss, all of whom substantially contributed to the specification. Thanks also to the OAuth working group members, chairs, area directors, and other IETF members who helped refine the specification.

June 4, 2017
Initial JSON Web Token Best Current Practices Draft

OAuth logoJSON Web Tokens (JWTs) and the JSON Object Signing and Encryption (JOSE) functions underlying them are now being widely used in diverse sets of applications. During IETF 98 in Chicago, we discussed reports of people implementing and using JOSE and JWTs insecurely, the causes of these problems, and ways to address them. Part of this discussion was an invited JOSE/JWT Security Update presentation that I gave to two working groups, which included links to problem reports and described mitigations. Citing the widespread use of JWTs in new IETF applications, Security Area Director Kathleen Moriarty suggested during these discussions that a Best Current Practices (BCP) document be written for JSON Web Tokens (JWTs).

I’m happy to report that Yaron Sheffer, Dick Hardt, and myself have produced an initial draft of a JWT BCP. Its abstract is:

JSON Web Tokens, also known as JWTs [RFC7519], 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. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs.

In Section 2, we describe threats and vulnerabilities. In Section 3, we describe best practices addressing those threats and vulnerabilities. We believe that the best practices in Sections 3.1 through 3.8 are ready to apply today. Section 3.9 (Use Mutually Exclusive Validation Rules for Different Kinds of JWTs) describes several possible best practices on that topic to serve as a starting point for a discussion on which of them we want to recommend under what circumstances.

We invite input from the OAuth Working Group and other interested parties on what best practices for JSON Web Tokens and the JOSE functions underlying them should be. We look forward to hearing your thoughts and working on this specification together.

The specification is available at:

An HTML-formatted version is also available at:

Next »