Mike Jones: self-issued

Musings on Digital Identity

Category: OAuth Page 10 of 12

OAuth 2.0 Multiple Response Type Encoding Practices

By

On November 19, 2012

In OAuth, OpenID, Specifications

IETF logoOAuth 2.0 (a.k.a. RFC 6749) has an extension point for defining additional response_type values beyond the code and token values defined within the specification. The OAuth 2.0 Multiple Response Type Encoding Practices specification uses this extension point to define the additional response_type values id_token and none, as well as values for the combinations of code, token, and id_token. These response_type values are used by OpenID Connect, as well as other systems using OAuth 2.0.

I’m writing this now because I just updated the Multiple Response Types spec to add an IANA Considerations section to make IANA’s job easier when registering these additional response_type values. No normative changes were made.

The specification is available at:

JOSE and JWT specs updated for IETF 85 working group meetings

By

On November 8, 2012

In Claims, Cryptography, JSON, OAuth, Specifications

IETF logoI’ve made a small set of updates to the JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) specs in preparation for the JOSE and OAuth working group meetings at IETF 85. These updates incorporate resolutions to issues that have been discussed by the working groups since publication of the previous drafts.

Normative changes to the working group specs were to add length fields for PartyUInfo and PartyVInfo values for key derivation calculations and to change the JWK field identifiers for RSA keys from (mod, xpo) to (n, e). Fields for representing the RSA private key values needed for Chinese Remainder Theorem (CRT) calculations were added to the JSON Private Key specification.

The updated specs are available at:

HTML formatted versions are available at:

See the history entries in the specs for detailed change descriptions.

OAuth 2.0 RFCs Completed

By

On October 12, 2012

In JSON, OAuth, Specifications

OAuth logoThe OAuth 2.0 Core and Bearer specifications are now RFC 6749 and RFC 6750. This completes the journey to standardize a pair of simple identity specifications that are already in very widespread use for Web, enterprise, cloud, and mobile applications. They make things better by enabling access to resources to be granted without giving the password for the resource to the party being granted access (a pattern that used to be all too common).

I believe that the completion of these RFCs will only accelerate the momentum behind the adoption of simple REST/JSON based identity solutions. Some of the related standards that are already well under way and in use include the OAuth Assertion Framework, the OAuth SAML 2.0 Assertion Profile and OAuth JWT Assertion Profile, JSON Web Token (JWT), the JSON Object Signing and Encryption (JOSE) specs — JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Algorithms (JWA), and OpenID Connect. Watch this space for future developments. Like OAuth 2.0, all of these are the product of collaboration by numerous people around the world and in many industries to build and deploy simple, usable identity solutions that solve real-world problems.

The goal of all these specs is to standardize functionality that is not only useful, but is simple enough that it will actually be used. OAuth 2.0 is an early success story in this regard. While the number of words in the spec has increased since early drafts, most of that is due to doing a more complete job of describing things not to do (adding security considerations), rather than adding bells and whistles. It doesn’t get much simpler than a couple of HTTP GETs and replies with simple request parameters and responses.

Dick Hardt deserves special thanks for his role both in starting what became OAuth 2.0 and seeing it through to completion. I recommend his post on the process that brought us the OAuth 2.0 RFCs.

Updated OAuth Assertion Specifications

By

On September 18, 2012

In Claims, JSON, OAuth, Specifications

OAuth logoUpdated drafts of all three OAuth Assertion specifications have been published. These specs define how to use assertions/security tokens as OAuth 2.0 authorization grants and for client authentication. They are: Assertion Framework for OAuth 2.0, SAML 2.0 Bearer Assertion Profiles for OAuth 2.0, and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0.

Language was added to all three explicitly clarifying that an assertion grant type can be used with or without client authentication via an assertion and that client authentication using an assertion is nothing more than an alternative way for a client to authenticate to the token endpoint. Two new examples were added to the SAML and JWT profile drafts to illustrate the use of assertions/security tokens in both cases. Thanks to Brian Campbell for making these updates.

The authors believe that draft-ietf-oauth-assertions and draft-ietf-oauth-saml2-bearer are now ready for Working Group Last Call.

The drafts are available at:

HTML-formatted versions are available at:

OAuth Assertion Framework draft -05

By

On September 10, 2012

In Claims, OAuth, Specifications

OAuth logoDraft 05 of the Assertion Framework for OAuth 2.0 has been published. It contains non-normative editorial changes to improve readability.

The draft is available at:

An HTML-formatted version is available at:

OAuth Core -31 and OAuth Bearer -23 specs published

By

On August 1, 2012

In OAuth, Specifications

OAuth logoHopefully final versions of the OAuth Core and Bearer specs have been published. These versions correct an editorial issue with the security clarification made in Core -30 and remove David Recordon from the author lists, at his request.

The specifications are available at:

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-31 are:

  • Clarify that any client can send client_id but that sending it is only required when using the code flow if the client is not otherwise authenticated.
  • Removed David Recordon’s name from the author list, at his request.

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-23 are:

  • Removed David Recordon’s name from the author list, at his request.

HTML-formatted versions are available at:

OAuth Core draft -30 published

By

On July 15, 2012

In OAuth, Specifications

OAuth logoDraft -30 of the OAuth Core spec has been published. The only change was:

  • Added text explaining why the server_error and temporarily_unavailable error codes are needed.

The draft is available at:

An HTML-formatted version is available at:

Thanks to Dick Hardt for quickly resolving this issue.

OAuth Core -29 and OAuth Bearer -22 specs published

By

On July 12, 2012

In OAuth, Specifications

OAuth logoNew versions of the OAuth Core and Bearer specs have been published that are intended to address all outstanding issues. (Although see Dick Hardt’s forwarded note from Charles Honton, which may result in an additional issue.)

The specifications are available at:

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-29 are:

  • Added “MUST” to “A public client that was not issued a client password MUST use the client_id request parameter to identify itself when sending requests to the token endpoint” and added text explaining why this must be so.
  • Added that the authorization server MUST “ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the client_id in the request”.
  • Added Security Considerations section “Misuse of Access Token to Impersonate Resource Owner in Implicit Flow”.
  • Added references in the “Implicit” and “Implicit Grant” sections to particularly pertinent security considerations.
  • Added appendix “Use of application/x-www-form-urlencoded Media Type” and referenced it in places that this encoding is used.
  • Deleted “;charset=UTF-8” from examples formerly using “Content-Type: application/x-www-form-urlencoded;charset=UTF-8”.
  • Added the phrase “with a character encoding of UTF-8” when describing how to send requests using the HTTP request entity-body.
  • For symmetry when using HTTP Basic authentication, also apply the application/x-www-form-urlencoded encoding to the client password, just as was already done for the client identifier.
  • Added “The ABNF below is defined in terms of Unicode code points [W3C.REC xml 20081126]; these characters are typically encoded in UTF-8”.
  • Replaced UNICODENOCTRLCHAR in ABNF with UNICODECHARNOCRLF = %x09 / %x20-7E / %x80-D7FF / %xE000-FFFD / %x10000-10FFFF.
  • Corrected incorrect uses of “which”.
  • Reduced multiple blank lines around artwork elements to single blank lines.
  • Removed Eran Hammer’s name from the author list, at his request. Dick Hardt is now listed as the editor.

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-22 are:

  • Removed uses of HTTPbis in favor of RFC 2616 and RFC 2617, since HTTPbis is not an approved standard.
  • Match formatting of artwork elements with OAuth core specification.

HTML-formatted versions are available at:

Thanks to Dick Hardt for editing the Core specification. Thanks to Julian Reschke for supplying the text in Core Appendix B on the use of the application/x-www-form-urlencoded encoding.

Updated JWT Bearer Token Profiles for OAuth 2.0

By

On July 6, 2012

In Claims, JSON, OAuth, Specifications

OAuth logoI’ve updated the OAuth JWT Profile document to track minor changes to some of the underling documents. No normative changes were made.

The updated specification is available at:

Changes made were:

  • Tracked specification name changes: “The OAuth 2.0 Authorization Protocol” to “The OAuth 2.0 Authorization Framework” and “OAuth 2.0 Assertion Profile” to “Assertion Framework for OAuth 2.0”.
  • Merged in changes between draft-ietf-oauth-saml2-bearer-11 and draft-ietf-oauth-saml2-bearer-13. All changes were strictly editorial.

An HTML formatted version is available at:

OAuth Core -28 and Bearer -21 Specifications

By

On June 19, 2012

In OAuth, Specifications

OAuth logoOAuth Core draft -28 has been published. Changes were:

  • Updated the ABNF in the manner discussed by the working group, allowing username and password to be Unicode and restricting client_id and client_secret to ASCII.
  • Specifies the use of the application/x-www-form-urlencoded content-type encoding method to encode the client_id when used as the password for HTTP Basic.

OAuth Bearer draft -21 has also been published. Changes were:

  • Changed “NOT RECOMMENDED” to “not recommended” in caveat about the URI Query Parameter method.
  • Changed “other specifications may extend this specification for use with other transport protocols” to “other specifications may extend this specification for use with other protocols”.
  • Changed Acknowledgements to use only ASCII characters, per the RFC style guide.

The drafts are available at:

HTML-formatted versions are available at:

Thanks to Eran Hammer for approving the Core draft posting.

OAuth Core -27 and Bearer -20 Specifications

By

On June 18, 2012

In OAuth, Specifications

OAuth logoOn June 8, draft 27 of the OAuth 2.0 Authorization Specification and draft 20 of the OAuth 2.0 Bearer Token Specification were published. They addressed DISCUSS issues and COMMENTs raised for these specifications during IESG review.

Changes made to draft-ietf-oauth-v2 were:

  • Added character set restrictions for error, error_description, and error_uri parameters consistent with the OAuth Bearer spec.
  • Added “resource access error response” as an error usage location in the OAuth Extensions Error Registry.
  • Added an ABNF for all message elements.
  • Corrected editorial issues identified during review.

Changes made to draft-ietf-oauth-v2-bearer were:

  • Added caveat about using a reserved query parameter name being counter to URI namespace best practices.
  • Specified use of Cache-Control options when using the URI Query Parameter method.
  • Changed title to “The OAuth 2.0 Authorization Framework: Bearer Token Usage”.
  • Referenced syntax definitions for the scope, error, error_description, and error_uri parameters in the OAuth 2.0 core spec.
  • Registered the invalid_request, invalid_token, and insufficient_scope error values in the OAuth Extensions Error Registry.
  • Acknowledged additional individuals.

The drafts are available at:

HTML-formatted versions are available at:

Initial Standards Track JSON Web Token (JWT) Specifications

By

On May 23, 2012

In Claims, JSON, OAuth, Specifications

IETF logoThe JSON Web Token (JWT) specification and the OAuth 2.0 JWT Bearer Token Profiles specification are now IETF standards track documents in the OAuth working group. These versions are based upon the individual submission versions draft-jones-json-web-token-10 and draft-jones-oauth-jwt-bearer-04 with no normative changes. The JWT specification builds upon the JWS, JWE, JWK, and JWA specifications in the JOSE working group.

These specifications are available at:

HTML formatted versions are available at:

OAuth 2.0 JWT Bearer Token Profiles Specification Draft -04

By

On April 26, 2012

In Claims, JSON, OAuth, Specifications

OAuth logoDraft 04 of the OAuth 2.0 JWT Bearer Token Profiles Specification has been published. This version tracks changes in the OAuth 2.0 Assertion Profile and SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 specifications made in response to working group last call comments, as announced by Brian Campbell.

Changes made were:

  • Merged in changes between draft-ietf-oauth-saml2-bearer-09 and draft-ietf-oauth-saml2-bearer-11.
  • Added the optional iat (issued at) claim, which was already present in the JWT spec.

The draft is available at:

An HTML-formatted version is available at:

OAuth 2.0 Bearer Token Specification Draft -19

By

On April 24, 2012

In OAuth, Specifications

OAuth logoDraft 19 of the OAuth 2.0 Bearer Token Specification has been published. It addresses DISCUSS issues and COMMENTs raised for which resolutions have been agreed to. No normative changes were made. Changes made were:

  • Use ABNF from RFC 5234.
  • Added sentence “The Bearer authentication scheme is intended primarily for server authentication using the WWW-Authenticate and Authorization HTTP headers, but does not preclude its use for proxy authentication” to the introduction.
  • In the introduction, state that this document also imposes semantic requirements upon the access token.
  • Reference the scope definition in the OAuth core spec.
  • Added scope examples.
  • Reference RFC 6265 for security considerations about cookies.

The draft is available at:

An HTML-formatted version is available at:

OpenID Connect has won the 2012 European Identity Award

By

On April 18, 2012

In Claims, Events, JSON, OAuth, Specifications

OpenID logoI’m thrilled to report that OpenID Connect has won the 2012 European Identity Award for Best Innovation/New Standard. I appreciate the recognition of what we’ve achieved to date with OpenID Connect and its potential to significantly change digital identity for the better. As Dave Kearns wrote in the OpenID Foundation announcement about the award:

I’m pleased that Kuppinger Cole has granted OpenID Connect the award for Best Innovation/New Standard this year. What’s most impressive is that this elegantly simple design resulted from the cooperation of such a diverse global set of contributors. I expect OpenID Connect to have a substantial positive impact on usable, secure identity solutions both for traditional computing platforms and mobile devices. My congratulations to the OpenID Foundation!

My thanks to all who have contributed to the OpenID Connect specifications to date and especially to the developers who have implemented draft versions, providing essential feedback needed to refine the specs on the road to final standards. I look forward to seeing what people will accomplish with OpenID Connect!

April 10, 2012 OpenID Connect Update Release

By

On April 13, 2012

In Claims, JSON, OAuth, OpenID, Specifications

OpenID logoThe OpenID Connect working group has released an update to the OpenID Connect specifications that continues incorporating significant developer feedback received, while maintaining as much compatibility with the implementer’s drafts as possible. The Connect specs have also been updated to track updates to the OAuth and JOSE specs, which they use. The primary normative changes are as follows:

  • Make changes to allow path in the issuer_identifier, per issue #513
  • Add hash and hash check of access_token and code to id_token, per issue #510
  • Split encrypted response configurations into separate parameters for alg, enc, int
  • Added optional id_token to authorization request parameters, per issue #535
  • Now requested claims add to those requested with scope values, rather than replacing them, per issue #547
  • Added error interaction_required and removed user_mismatched, per issue #523
  • Changed invalid_request_redirect_uri to invalid_redirect_uri, per issue #553
  • Removed “embedded” display type, since its semantics were not well defined, per issue #514

A significant non-normative addition is:

  • Add example JS code for Basic client

Implementers are particularly encouraged to build and provide feedback on the new and modified features.

The new versions are available from http://openid.net/connect/ or at:

OAuth 2.0 Bearer Token Specification Draft -18

By

On March 12, 2012

In OAuth, Specifications

OAuth logoDraft 18 of the OAuth 2.0 Bearer Token Specification has been published. It contains the following changes:

  • Changed example bearer token value from vF9dft4qmT to mF_9.B5f-4.1JqM.
  • Added example access token response returning a Bearer token.

The draft is available at:

An HTML-formatted version is available at:

OAuth 2.0 Bearer Token Specification Draft -17

By

On February 17, 2012

In OAuth, Specifications

OAuth logoDraft 17 of the OAuth 2.0 Bearer Token Specification has been published. This version changes the RFCs referenced for certificate chain verification. The wording was proposed by Alexey Melnikov as part of the Gen-ART review.

It contains the following changes:

  • Restore RFC 2818 reference for server identity verification and add RFC 5280 reference for certificate revocation lists, per Gen-ART review comments.

The draft is available at:

An HTML-formatted version is available at:

OpenID Connect Interop in Progress

By

On February 17, 2012

In Claims, Events, Interoperability, JSON, OAuth, OpenID, Specifications

OSIS logoOpenID logoThe Third OpenID Connect Interop is currently under way — this time based upon approved Implementer’s Drafts. Currently 7 implementations are being tested, with I believe more to be added. The interop is designed to enable people to test the implementations they’ve built against other implementations and verify that specific features that they’ve built are working correctly. This has several benefits: it helps debug implementations, it helps debug the specifications, and it results in greater interoperability among OpenID Connect implementations.

As background, like the other OSIS interops, the OpenID Connect interop is an opportunity for implementers to try their code against one another’s in a systematic way. It is not a conformance test; participants do not “pass” or “fail”. There is no requirement that you must support particular features to participate or that you must participate in all aspects of the interop.

If you’d like to participate in the interop, join the OpenID Connect Interop mailing list and send us a note there saying who your interop contact person will be, the name of your organization (can be an individual), the name of your implementation (can be your name), and a list of the online testing endpoints for your implementation. Testing is performed online on your schedule, with results recorded on the interop wiki. That being said, an in-person meeting of interop participants will also be held on Friday, March 2 in San Francisco (the week of RSA) for those who are able to attend.

OpenID Connect Implementer’s Drafts Approved

By

On February 17, 2012

In Claims, JSON, OAuth, OpenID, Specifications

OpenID logoThe OpenID Foundation members have overwhelmingly voted to approve the OpenID Connect specifications as Implementer’s Drafts. This is an important milestone in the process of completing the OpenID Connect specifications.

Implementer’s Drafts are stable versions of specifications intended for trial implementations and deployments that provide specific IPR protections to those using them. Implementers and deployers are encouraged to continue to provide timely feedback to the working group on the specifications based upon their experiences with them.

Page 10 of 12

Previous

Next

Powered by WordPress & Theme by Anders Norén