OpenID Connect was a hot topic at the Cloud Identity Summit in Keystone, Colo. last month - but what is it?

OpenID Connect is a specification that codifies how parties can use the OAuth 2.0 protocol to communicate about identity. If you have tried to connect to multiple OAuth-enabled cloud providers, you will understand the pain point we want to alleviate with OpenID Connect: Namely that each cloud provider creates a separate, unique API for accessing their own particular silo. Wouldn't it be great if developers could discover typical information about the currently authenticated user using the same ceremony everywhere?

Currently in development at the OpenID Foundation, OpenID Connect 1.0 has been designed to support the use of Javascript and rich-client applications, an area that previous protocols such as OpenID 2.0 did not cover well. OpenID Connect 1.0 is also extensible; while the core specification defines standardized REST endpoints for profile data and for session information, standardization of additional identity-related services such as activity streams and portable contacts are also possible in the future.

The current version of the specification has reached a point where its fundamental operations are agreed upon, and where initial implementers can begin to 'test-drive' the functionality. Focus is starting to shift away from developing the specification towards education and communication in order to grease the wheels of adoption. The documents themselves are likely to change in name, number and order, but the content is quite stable.  Go to to see more information (or click "More" and see a diagram. Click on the boxes themselves to see the listed specification).

The current specifications of OpenID Connect 1.0


Core Functionality

OpenID Connect is a specification that formalizes a standard identity interface and schema for federated parties. OpenID Connect is built on top of OAuth 2.0, a specification currently being ratified at the IETF. The OpenID Connect suite of documents does several things:

  • Profile the exact way that an OpenID 2.0 token endpoint and authorization endpoint should interact when authenticating and authorizing users using OAuth 2.0
  • Describe how additional endpoints, listed below, should interact in order to exchange information (all accessed using an OAuth access token) about the user who owns the OAuth access token, and about the token itself.
  • Describe how parties can interact to dynamically register a client and to manage sessions on behalf of the user.

Critical new elements that you need to know about to understand OpenID Connect are listed below:

1) id_token
An ID token is a signed JSON Web Token (JWT) containing minimal data about the identity and the circumstances of the current authenticated session, distributed to the client at the same time as the OAuth access_token. In the lightest version of OpenID Connect, this token is treated as an opaque artifact (i.e. an unreadable string) and used to gain access to authoritative data from a REST endpoint, thus keeping the security expectations of the client that is handling the id_token to a minimum. In more sophisticated use cases, a client capable of validating signatures can directly scrutinize the id_token.  

2) UserInfo Endpoint
This is an OAuth Resource Service that publishes identity information about the user who owns the token supplied to the service. This is similar information to what might have been included in an OpenID 2.0 response if the AX or SReg extension was used. The client passes an id_token to the endpoint and receives back a JSON object containing a standard set of data describing the user, described using standardized names. Many cloud services today provide a user information RESTful endpoint that is protected by OAuth;  what OpenID Connect does is to create a common paradigm.

3) Token Introspection Endpoint:

The token introspection endpoint publishes information about the circumstances under which the given token was created. Data served includes the expiry date of the token, the intended audience, any assurance level that was associated, and so on.  Think of this endpoint as delivering context about the user's current session.

New Functionality for OpenID Connect

Extended Functionality
OpenID Connect is designed to span the range of API security requirements from simple to secure. In the simple case, identity endpoints are treated no differently than any other resource service, the client simply passes an id_token to a service to get authorized access to information. In more complex use cases, the client itself may need to be uniquely identified, and signing and encryption between service and client may exist. All of these variations and more are possible with OpenID Connect, but are not required.

Specification Documents
The specification documents are available at  Please note that the data at is old and no longer describes the current OpenID Connect efforts.

If you want to get an idea of the activities around this spec, you should subscribe to the Openid-specs-ab mailing list, at  If you want to contribute to that mailing list (rather than just monitoring it),  you will need to sign an IPR agreement. More details are available at

Unless you are a developer or an early implementer, OpenID Connect is not likely to be on your radar until 2012. Still, it can't hurt to know what is coming down the pipe - we at Ping Identity think that this specification has incredible promise.


* Required Fields