OpenID Connect allows Client Applications to verify the identity of the End User based on the authentication performed by an Authorization Server. It also allows the Client to obtain basic profile information about the End User.
There are a number of versions of how OpenID Connect was born, e.g. here, here, here, and officially here. I like the story that after multiple influential companies implemented SAML, WS*, and OpenID 2.0, and also Facebook implemented Facebook Connect, Eran Hammer and David Recordon put forth a one page proposal for what became OpenID Connect. I can’t find this historical one-pager, and even the core spec today is around 100 pages with half a dozen other supporting documents. Some have called it a functional merger of OpenID and Facebook Connect that is layered on OAuth 2.0. Others provide the “formula”:
(Identity, Authentication) + OAuth 2.0 = OpenID Connect
Whoever should be getting historical credit, the basic idea is both simple and brilliant: Take the authorization mechanism of OAuth 2.0, make a couple tiny additions, which I’ll explain in a moment, and viola, we’ve got a authentication mechanism.
As with OAuth 2.0, there is a registration process that is not specified, but it is essentially the same as for OAuth and is described in the spec under OpenID Connect Discovery and under OpenID Connect Dynamic Client Registration. There is a bit of a pas de deux on terminology. What OAuth calls the Authorization Server AS is also referred to as the OP for OpenID Provider, and OP has an Authorization Endpoint and a Token Endpoint. The client obtains these endpoints during registration.
The fundamental new idea is simply to add a new scope value openid to the initial authorization request message (described in my last post on OAuth 2.0) to the Authorization Server AS. Having openid as one of the scope values, makes requests not only for access tokens but also for a new “identity token” and also opens up the possibility to request more information about the end user. Here are some of these request parameters:
- scope: must contain the new value openid and may contain one or more of the scope values of profile, email, address, phone, and offline_access
- response_type: code – means both access and id tokens be returned from the token endpoint in exchange for the code value obtained from the AS
- client_id: obtained during registration at the AS
- redirect_uri: one of the pre-registered redirection URI values for the client
This request asks the AS to authenticate the owner/operator of the browser that is sending the message and to return an id_token as well as access_tokens. The id_token will affirm that the user has authenticated recently. The id_token may contain additional claims or information about the user. The method of authentication is not defined by the spec. The id_token includes a JSON object that includes:
- iss = issuer identifier for the issuer of the response
- sub = subject identifier, a locally unique within the issuer for the end-user
- aud = audience(s) for whom this id_token is intended = array of case sensitive strings or a single such string
- UserInfo Endpoint
- iat = Issue timestamp
- exp = Expiration datetime
- auth_time = time end-user last authenticated
- How the user was authenticated (optional)
- many other optional tags
The user runs a protected application which may make additional GET requests to the UserInfo endpoint for REST APIs for identity attributes. Curiously the spec warns that these claims may not be for the end user (due perhaps to man-in-the-middle attacks)! In addition there are language dependencies on the claim values.
The final OpenID Connect specification is dated Feb 26, 2014; and the certification program was launched April 22, 2015 with Google, Microsoft, Ping Identify, ForgeRock, Nomura Research Institute, and PayPal the first to self-certify.
Multiple companies, in support of OpenID Connect, have announced they will no longer be supporting OpenID 2.0 at some point in the near future.
My next IAM post is about SCIM. It is here.