Archive for the 'OAuth' Category

January 24, 2017
“amr” Values specification addressing IETF last call comments

OAuth logoDraft -05 of the Authentication Method Reference Values specification addresses the IETF last call comments received. Changes were:

  • Specified characters allowed in “amr” values, reusing the IANA Considerations language on this topic from RFC 7638.
  • Added several individuals to the acknowledgements.

Thanks to Linda Dunbar, Catherine Meadows, and Paul Kyzivat for their reviews.

The specification is available at:

An HTML-formatted version is also available at:

January 19, 2017
OAuth Authorization Server Metadata decoupled from OAuth Protected Resource Metadata

OAuth logoThe IETF OAuth working group decided at IETF 97 to proceed with standardizing the OAuth Authorization Server Metadata specification, which is already in widespread use, and to stop work on the OAuth Protected Resource Metadata specification, which is more speculative. Accordingly, a new version of the AS Metadata spec has been published that removes its dependencies upon the Resource Metadata spec. In particular, the “protected_resources” AS Metadata element has been removed. Its definition has been moved to the Resource Metadata spec for archival purposes. Note that the Resource Metadata specification authors intend to let it expire unless the working group decides to resume work on it at some point in the future.

The specifications are available at:

HTML-formatted versions are also available at:

November 13, 2016
“amr” Values specification addressing area director comments

OAuth logoDraft -04 of the Authentication Method Reference Values specification addresses comments by our security area director Kathleen Moriarty. Changes were:

  • Added “amr” claim examples with both single and multiple values.
  • Clarified that the actual credentials referenced are not part of this specification to avoid additional privacy concerns for biometric data.
  • Clarified that the OAuth 2.0 Threat Model [RFC6819] applies to applications using this specification.

The specification is available at:

An HTML-formatted version is also available at:

October 14, 2016
“amr” Values specification addressing shepherd comments

OAuth logoDraft -03 of the Authentication Method Reference Values specification addresses the shepherd comments. It changes the references providing information about specific “amr” values to be informative, rather than normative. A reference to ISO/IEC 29115 was also added. No normative changes were made.

The specification is available at:

An HTML-formatted version is also available at:

September 20, 2016
Using Referred Token Binding ID for Token Binding of Access Tokens

OAuth logoThe OAuth Token Binding specification has been revised to use the Referred Token Binding ID when performing token binding of access tokens. This was enabled by the Implementation Considerations in the Token Binding HTTPS specification being added to make it clear that Token Binding implementations will enable using the Referred Token Binding ID in this manner. Protected Resource Metadata was also defined.

Thanks to Brian Campbell for clarifications on the differences between token binding of access tokens issued from the authorization endpoint versus those issued from the token endpoint.

The specification is available at:

An HTML-formatted version is also available at:

September 9, 2016
“amr” Values specification addressing WGLC comments

OAuth logoDraft -02 of the Authentication Method Reference Values specification addresses the Working Group Last Call (WGLC) comments received. It adds an example to the multiple-channel authentication description and moves the “amr” definition into the introduction. No normative changes were made.

The specification is available at:

An HTML-formatted version is also available at:

September 8, 2016
Initial Working Group Draft of OAuth Token Binding Specification

OAuth logoThe initial working group draft of the OAuth Token Binding specification has been published. It has the same content as draft-jones-oauth-token-binding-00, but with updated references. This specification defines how to perform token binding for OAuth access tokens and refresh tokens. Note that the access token mechanism is expected to change shortly to use the Referred Token Binding, per working group discussions at IETF 96 in Berlin.

The specification is available at:

An HTML-formatted version is also available at:

August 3, 2016
OAuth Metadata Specifications Enhanced

OAuth logoThe existing OAuth 2.0 Authorization Server Metadata specification has now been joined by a related OAuth 2.0 Protected Resource Metadata specification. This means that JSON metadata formats are now defined for all the OAuth 2.0 parties: clients, authorization servers, and protected resources.

The most significant addition to the OAuth 2.0 Authorization Server Metadata specification is enabling signed metadata, represented as claims in a JSON Web Token (JWT). This is analogous to the role that the Software Statement plays in OAuth Dynamic Client Registration. Signed metadata can also be used for protected resource metadata.

For use cases in which the set of protected resources used with an authorization server are enumerable, the authorization server metadata specification now defines the “protected_resources” metadata value to list them. Likewise, the protected resource metadata specification defines an “authorization_servers” metadata value to list the authorization servers that can be used with a protected resource, for use cases in which those are enumerable.

The specifications are available at:

HTML-formatted versions are also available at:

July 8, 2016
“amr” Values specification distinguishing between iris and retina scan biometrics

OAuth logoThis draft distinguishes between iris and retina scan biometrics, as requested by NIST, and adds a paragraph providing readers more context at the end of the introduction, which was requested by the chairs during the call for adoption. The OpenID Connect MODRNA Authentication Profile 1.0 specification, which uses “amr” values defined by this specification, is now also referenced.

The specification is available at:

An HTML formatted version is also available at:

July 7, 2016
Terminology updates in OAuth Mix-Up Mitigation specification

OAuth logoThe only change to the new draft is to use terminology more consistently. Specifically, it changes the terms “issuer URL” and “configuration information location” to “issuer identifier” so that consistent terminology is used for this. (This is the terminology used by OpenID Connect.)

This is being posted in preparation for discussions at the upcoming OAuth Security Workshop in Trier, Germany and the IETF 96 meeting in Berlin.

The specification is available at:

An HTML-formatted version is also available at:

July 4, 2016
Token Binding for Access Tokens, Refresh Tokens, and ID Tokens

IETF logoTwo new related specifications define syntax and semantics for applying Token Binding to OAuth Access Tokens and Refresh Tokens and to OpenID Connect ID Tokens. draft-jones-oauth-token-binding contains the OAuth portions. openid-connect-token-bound-authentication-1_0 contains the OpenID Connect portions.

These are being submitted now to hopefully enable end-to-end implementations and interop testing of Token Bound Access Tokens, Refresh Tokens, and ID Tokens across multiple platforms before the Token Binding specifications are finalized.

The OAuth specification is available at:

The OpenID Connect specification is available at:

Thanks to Andrei Popov, Yordan Rouskov, John Bradley, and Brian Campbell for reviews of earlier versions of these specifications and to Dirk Balfanz and William Denniss for some earlier discussions providing input to these specifications.

April 6, 2016
Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) is now RFC 7800

IETF logoThe Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) specification is now RFC 7800 – an IETF standard. The abstract describes the specification as:

This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of-possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.

Thanks to John Bradley, Hannes Tschofenig, and the OAuth working group for their work on this specification.

March 4, 2016
OAuth 2.0 Token Exchange draft -04

OAuth logoA new draft of “OAuth 2.0 Token Exchange” has been published addressing review comments on the prior draft. The changes from -03 are listed here:

The specification is available at:

An HTML-formatted version is also available at:

Thanks to Brian Campbell for doing most of the edits for this release.

March 3, 2016
Tidied-up OAuth 2.0 Device Flow specification

OAuth logoThe OAuth 2.0 Device Flow specification has been tidied up to apply spelling and grammar corrections and add the Document History appendix. No normative changes were made. Again, if you’re using an OAuth device flow, please let us know whether your implementation matches this specification, and if not, let us know how it differs.

The specification is available at:

An HTML-formatted version is also available at:

February 18, 2016
Initial OAuth working group Device Flow specification

OAuth logoThanks to William Denniss for creating the initial working group version of the OAuth 2.0 Device Flow specification. The abstract of the specification is:

The device flow is suitable for OAuth 2.0 clients executing on devices which do not have an easy data-entry method (e.g., game consoles, TVs, picture frames, and media hubs), but where the end-user has separate access to a user-agent on another computer or device (e.g., desktop computer, a laptop, a smart phone, or a tablet).

Note: This version of the document is a continuation of an earlier, long expired draft. The content of the expired draft has been copied almost unmodified. The goal of the work on this document is to capture deployment experience.

If you’re using an OAuth device flow, please let us know whether this specification matches your usage, and if not, how yours differs.

The specification is available at:

An HTML-formatted version is also available at:

February 17, 2016
OAuth Discovery spec pared down to its essence

OAuth logoIn response to working group input, this version of the OAuth Discovery specification has been pared down to its essence – leaving only the features that are already widely deployed. Specifically, all that remains is the definition of the authorization server discovery metadata document and the metadata values used in it. The WebFinger discovery logic has been removed. The relationship between the issuer identifier URL and the well-known URI path relative to it at which the discovery metadata document is located has also been clarified.

Given that this now describes only features that are in widespread deployment, the editors believe that this version is ready for working group last call.

The specification is available at:

An HTML-formatted version is also available at:

February 11, 2016
Authentication Method Reference Values spec incorporating adoption feedback

OAuth logoThis draft of the Authentication Method Reference Values specification incorporates OAuth working group feedback from the call for adoption. The primary change was to remove the “amr_values” request parameter, so that “amr” values can still be returned as part of an authentication result, but cannot be explicitly requested. Also, noted that OAuth 2.0 is inadequate for authentication without employing appropriate extensions and changed the IANA registration procedure to no longer require a specification.

The specification is available at:

An HTML-formatted version is also available at:

February 9, 2016
Initial OAuth working group Discovery specification

OAuth logoWe have created the initial working group version of OAuth Discovery based on draft-jones-oauth-discovery-01, with no normative changes.

The specification is available at:

An HTML-formatted version is also available at:

January 28, 2016
OAuth Discovery metadata values added for revocation, introspection, and PKCE

OAuth logoThe OAuth Discovery specification has been updated to add metadata values for revocation, introspection, and PKCE. Changes were:

  • Added “revocation_endpoint_auth_methods_supported” and “revocation_endpoint_auth_signing_alg_values_supported” for the revocation endpoint.
  • Added “introspection_endpoint_auth_methods_supported” and “introspection_endpoint_auth_signing_alg_values_supported” for the introspection endpoint.
  • Added “code_challenge_methods_supported” for PKCE.

The specification is available at:

An HTML-formatted version is also available at:

January 27, 2016
Identity Convergence and Microsoft’s Ongoing Commitment to Interoperability

OpenID logoPlease check out this important post today on the Active Directory Team Blog: “For Developers: Important upcoming changes to the v2.0 Auth Protocol”. While the title may not be catchy, it’s content is compelling – particularly for developers.

The post describes the converged identity service being developed by Microsoft that will enable people to log in either with an individual account (Microsoft Account) or an organizational account (Azure Active Directory). This is a big deal, because developers will soon have a single identity service that their applications can use for both kinds of accounts.

The other big deal is that the changes announced are a concrete demonstration of Microsoft’s ongoing commitment to interoperability and support for open identity standards – in this case, OpenID Connect. As the post says:

The primary motivation for introducing these changes is to be compliant with the OpenID Connect standard specification. By being OpenID Connect compliant, we hope to minimize differences between integrating with Microsoft identity services and with other identity services in the industry. We want to make it easy for developers to use their favorite open source authentication libraries without having to alter the libraries to accommodate Microsoft differences.

If you’re a developer, please do heed the request in the post to give the service a try now as it approaches General Availability (GA). Enjoy!

Next »