Musings on Digital Identity

Month: January 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:

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!

Second OAuth 2.0 Mix-Up Mitigation Draft

OAuth logoJohn Bradley and I collaborated to create the second OAuth 2.0 Mix-Up Mitigation draft. Changes were:

  • Simplified by no longer specifying the signed JWT method for returning the mitigation information.
  • Simplified by no longer depending upon publication of a discovery metadata document.
  • Added the “state” token request parameter.
  • Added examples.
  • Added John Bradley as an editor.

The specification is available at:

An HTML-formatted version is also available at:

OAuth 2.0 Mix-Up Mitigation

OAuth logoYesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up. This note announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attacks covered in the advisory. The abstract of the specification is:

This specification defines an extension to The OAuth 2.0 Authorization Framework that enables an authorization server to provide a client using it with a consistent set of metadata about itself. This information is returned in the authorization response. It can be used by the client to prevent classes of attacks in which the client might otherwise be tricked into using inconsistent sets of metadata from multiple authorization servers, including potentially using a token endpoint that does not belong to the same authorization server as the authorization endpoint used. Recent research publications refer to these as “IdP Mix-Up” and “Malicious Endpoint” attacks.

The gist of the mitigation is having the authorization server return the client ID and its issuer identifier (a value defined in the OAuth Discovery specification) so that the client can verify that it is using a consistent set of authorization server configuration information, that the client ID is for that authorization server, and in particular, that the client is not being confused into sending information intended for one authorization server to a different one. Note that these attacks can only be made against clients that are configured to use more than one authorization server.

Please give the draft a quick read and provide feedback to the OAuth working group. This draft is very much a starting point intended to describe both the mitigations and the decisions and analysis remaining before we can be confident in standardizing a solution. Please definitely read the Security Considerations and Open Issues sections, as they contain important information about the choices made and the decisions remaining.

Special thanks go to Daniel Fett (University of Trier), Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University Bochum), and Guido Schmitz (University of Trier) for notifying us of the attacks and working with us both on understanding the attacks and on developing mitigations. Thanks too to Hannes Tschofenig for organizing a meeting on this topic last month and to Torsten Lodderstedt and Deutsche Telekom for hosting the meeting.

The specification is available at:

An HTML-formatted version is also available at:

Powered by WordPress & Theme by Anders Norén