In the previous post we talked about delegated authorization with OAuth 2.0. After the success of OAuth 2.0, many companies tried using OAuth as an authorization method, which has known pitfalls. The main issue is that if a malicious application manages to steal an access token, it can use it to impersonate the user. Many OAuth 2.0 providers modified the OAuth protocol to implement authorization, which made them less interoperable and possibly even vulnerable to impersonation attacks. Since OpenID was an existent standard for federated identity, there was interest in combining these two protocols, so the third generation of the OpenID protocol was built as an OAuth 2.0 extension.

OpenID Connect

OpenID Connect is an identity layer built on top of OAuth 2.0. It specifies a RESTfull HTTP API that is interoperable (it uses JSON as the data format), simple, mobile friendly and secure.

Since identity is an overloaded term, OpenID Connect defines identity  as a set of claims (attributes) related to a an entity (person, service, machine).

Actors

These are the actors that take part in the OpenID Connect authentication flow:

An OpenID Identity Provider (IDP or OP) is an  OAuth 2.0 authorization server that offers authentication as a service.

A Relying Party (RP) is an OAuth 2.0 client that relies on the IDP in order to authenticate users and request claims.

The End-User is the entity for which we request identity information. In OAuth 2.0 terms, this is the resource owner, and the resource that he owns is his own identity.

ID Token

The OpenID Connect protocol specifies a new type of token – the ID Token – that encapsulates the user’s identity. The main attributes (claims) that a token contains are:

• Issuer  – the authorization server that issued this token
• Subject – an identifier for the End-User
• Audience – who can use this token; the client (Relying Pary) of the token must be in the audience of the token
• Expiration  -the token’s expiration time

OpenID Connect mandates the use of JSON Web Token (JWT) as the format of the token. The token must be signed by the Authorization Server using JSON Web Signature (JWS), in order to achieve integrity and non repudiation. It may also be encrypted with JSON Web Encryption (JWE) for confidentiality.

Claims

OpenID Connect defines 20 standard claims (name, email, address, phone, etc.), but you can also define custom claims. The OpenID Connect specs also defines four standard scopes – profile, email, address and phone – which are groups of standard claims (e.g. the email scope contains the email and email_verified claims) .

The client application can request claims either in the initial authentication request or with an API call to the UserInfo endpoint.

Passport Control Analogy

OpenID can easily be explained by comparing it with the border control check that you have to go through in airports. When you (the End-User) go through passport control, you authenticate to the airport security personnel (the Relying Party) by showing them your Passport (ID token). The Passport is issued by a national authority (Identity Provider) that the airport employees trust and contains claims about you (name, age, nationality, etc.).

Registration

The OpenID Connect registration process is similar to the OAuth one: after a relying party registers with an OpenID provider, it receives a client ID – which is public – and a client secret – which should be kept private.

Authorization Flows

OpenID Connect defines three types of flows: Code, Implicit and Hybrid.

Authorization Code Flow

The OpenID Connect authorization code flow is very similar to the OAuth 2.0 server side flow. The End-User gets redirected to the Authorization Server, which must authenticate the user and request consent for the client to access the user’s identity. After this step, the End-User is redirected to the client with an authorization code as a query string parameter. The client can then exchange the authorization code and the client’s credentials for an ID token and an access token through a server side (back channel) call to the token endpoint. Before using the ID token, the client must validate it.

 

Implicit Flow

The Implicit flow is very similar to the OAuth 2.0 client side flow and it is best suited for client side applications. The ID token and, optionally, an access token are returned from the authorization endpoint. Before using the ID token, the client must validate it.

Hybrid Flow

The Hybrid flow is a combination of the Authorization Code and Implicit flows. It allows the backend of the client to receive an authorization code, while the frontend can receive an ID token and/or an access token.

Endpoints

An endpoint is simply an HTTP resource. OpenID Connect defines 4 core endpoints: 3 authorization server endpoints – authorization endpoint, token endpoint and UserInfo endpoint, and 1 client endpoint – the redirect endpoint.

The Authorization Endpoint is used to ensure the user is authenticated and optionally grants access to other claims about his identity. If the user is not authenticated, then he will be redirected to the Identity Provider in order to authenticate.

The Token Endpoint is used to exchange the authorization grant for an ID token and an access token. This endpoint may accept other OAuth 2.0 grant types in order to issue access tokens.

The UserInfo Endpoint is an OAuth 2.0-protected resource. It can be used to request claims about the user, given that a valid access token is passed in the request.

The Redirect Endpoint is used to redirect the End-User’s browser back to the client application. Tokens are also passed to the client through query string parameters or hash code URL fragments.

Apart from these 4 primary endpoints, the OpenID Connect specification also defines the following optional endpoints:

• The Session Management Endpoint can be used by clients to check if a user has an active session or for logging out.
• The Discovery Endpoint can be used by the Relying Party in order to find out the OpenID Provider behind a given user (usually this can be infered from the user’s email address).  OpenID Connect mandates the use of the WebFinger protocol for this use case.
• The Identity Provider Metadata Endpoint can be used to request information about the OpenID Identity Provider. This metadata can contain endpoint URLs and supported capabilities (grant types, scopes, claims, signing and encryption algorithms, etc.)
• The Dynamic Client Registration Endpoint can be used in order to dynamically register Relying Parties.

The last three endpoints enable a seamless integration and registration with an OpenID Provider – when an End-User tries to login for the first time using a Relying Party, the client can get the URL of the IDP by using the Discovery Endpoint, then use the Identity Provider Metadata Endpoint to get the registration URL of the provider and then automatically register using the Dynamic Client Registration Endpoint.

JWT

JSON Web Token is a compact JSON format useful for exchanging information between parties. The OpenID Connect specification mandates the use of JWT as the format of the ID token.

The entire JWT is Base64Url encoded and is split in three parts, separated by dots:

• Header – contains the type of the token – JWT – and the cryptographic operation applied on the body
• Body – contains the claims set – the real business data. There are three types of claims: reserved (a set of predefined claims like issuer, subject, audience, expiration, etc.), public (these can be defined by those using JWT, but must be collision-resistant, either by being registered with IANA or by namespacing them with an URI) and private (these are private claims, known only by parties that agree on using them)
• Signature – the Header, Body and a secret are signed using the cryptographic operation specified in the header.

Conclusion

OpenID Connect is the emerging standard for federated identity. It’s an identity layer on top of OAuth 2.0, built using REST endpoints and JSON messages. It is more interoperable than previous solutions based on OAuth 2.0 and its adoption rate is growing more rapidly than for previous versions of OpenID.

Being a newer standard than SAML, OpenID Connect has some advantages: it is simpler, more interoperable and mobile friendly, meaning OpenID Connect will gain more traction in the enterprise space.

If you want to find out more, check out these resources:

• Advanced API Security: Securing APIs with OAuth 2.0, OpenID Connect, JWS, and JWE by Prabath Siriwardena
• OpenID Connect Specifications