An Introduction to Open ID Connect

Introduction

Ever since the first OpenID specification emerged there has been a movement to create a truly federated and distributed model for single sign-on (SSO) in websites. But there are two obstacles that need to be addressed; firstly, how to create a simple, effective and secure model for SSO and secondly, how to allow users to choose their own SSO provider independently of websites. The original OpenID specification led towards creating OAuth protocol. Later, OAuth 2.0 was used for SSO. OAuth 2.0 provides a simple model for seamless sign-on using a third-party identity provider, but it requires each website to hard-code which identity providers they support. OpenID Connect is the latest standard to solve this problem.

What is OpenID Connect?

OpenID Connect is an identity framework built on top of OAuth 2.0 protocol which extends the authorization process of OAuth 2.0 to implement its authentication mechanism. Since it is built on OAuth 2.0 it standardizes the use of OAuth 2.0 for login and adds a discovery process that enables users to use whichever identity provider they want with any website that supports OpenID Connect. In other words, we can support SSO for any website and any identity provider.

OAuth 2.0 is an authorization framework which is capable of providing a way for clients to access a resource with restricted access on behalf of the resource owner. OAuth 2.0 is capable of authorizing the flows for web applications, desktop applications and mobile applications among others.

With OAuth as its base, OpenID Connect allows many types of clients such as web based clients, mobile clients and javascript clients to verify the users with an authorization server based authentication. It communicates on basic information about the user using the claims.

OpenID Connect and authorization

There are two main parties involved in the authentication process of OpenID Connect. They are the OpenID Providers (OPs) and the Relying Parties (RPs). The OAuth 2.0 authentication servers which implement the OpenID Connect are considered as the OPs and the clients who are using OpenID Connect are known as the RPs. To authenticate with OpenID Connect the RP should have information about the OP; information such as authorization endpoint, token endpoint and so on. But the beauty is that the RP should not know this information beforehand. The RPs need to use OpenID Connect Discovery, which is a main part of OpenID Connect, to obtain these details. The RP still needs to have sufficient credentials and information required to use the OpenID provider which can be obtained using dynamic registration which again comes with OpenID Connect itself.

What’s so special about OpenID Connect?

The special features of OpenID Connect are as follows;

• The tokens used are “ID Tokens” of JSON Web Tokens which can be cryptographically signed
• It is capable of performing ad-hoc registration
• It supports emerging technologies such as JWT, JWS and SWD
• Its OpenID Connect Discovery protocol
• It manages user information endpoints that can be used to retrieve information about the authenticated user

The core components of OpenID Connect

The four basic components in OpenID Connect are as follows;

• Core
• Discovery
• Dynamic Registration
• Session Management

Figure 1

OpenID Connect Core

OpenID Connect Core defines the core functionality of OpenID Connect. This includes the OpenID Connect authentication protocol, the security and privacy concerns when using OpenID Connect and the methods of getting the end user information through the claims. Having OAuth 2.0 as its base, OpenID Connect inherits the ability to generate access tokens and access the resources using those access tokens. Since OAuth does not communicate the identity information of the end user, OpenID Connect extends the OAuth protocol so that the end user information can be communicated with the OP. The ID Token data structure, which is a JSON Web Token (JWT), has been introduced by OpenID Connect for this purpose. This ID Token can be signed as well as encrypted so that it can achieve confidentiality, integrity and non-repudiation. The authentication result is sent back to the relying party (the client) through the ID token.

OpenID Connect Discovery

For a relying party to authenticate an end user against an OpenID provider, they should have the knowledge of the OpenID provider that they are going to contact. Since OpenID Connect Discovery is capable of identifying the OpenID provider for the end user, the relying party doesn’t need have any prior knowledge of its OpenID provider. OpenID Connect uses the WebFinger protocol that provides a mechanism of discovering the information about the entities on the web in order to locate the OpenID provider for the end user.

In this process of discovery, the relying party resolves the resource that the end user needs to access as well as the host by using an identifier received from the end user. Then this information is passed on to the WebFinger endpoint which will return the OpenID provider issuer location.

Using the OpenID Connect Discovery is not a mandatory step if the relying party is capable of determining the location of the OpenID provider with some other mechanism.

OpenID Connect Dynamic Client Registration

For an external client or end user to utilize the resources/services of the OpenID Connect, the relying party used by the end user should be able to register with an OpenID provider. OpenID Connect dynamic client registration manages the process of external relying parties dynamically registering their clients with the OpenID provider.

The relying parties can provide the information required to register with an OpenID provider and retrieve the information that is required to access the OpenID Connect services through the dynamic client registration process.

Clients send registration requests targeting the resources that are protected with OAuth protocol. So the OAuth 2.0 protected resource is considered as the client registration endpoint and the client should be able to register to this endpoint without an OAuth 2.0 access token. In any case where the client registration endpoint requires an access token, it should accept the access tokens according to the OAuth 2.0 bearer token usage specifications.

OpenID Connect Session Management

This component is used to manage the end user session for OpenID Connect. OpenID Connect session management monitors and updates the login status of the end user at the OpenID provider's end so that the relying party can logout an end user who is logged out from the OpenID provider end. Since the relying party is connected to the OpenID provider with respect to a resource or service, the session management should be maintained with respect to their endpoint URLs. The OpenID Connect session manager can also discover these endpoints by using its own OpenID provider's discovery response.

When a relying party tries to communicate with an OpenID provider, the session at the relying party end begins when it validates the end user ID token. Even though this session has an expiration time period like most of the sessions, it is possible for the end user to be logged out from the OpenID provider end before the session is expired. Due to this, after the OpenID provider starts the session, the session details should be communicated with the relying party. For this purpose the OpenID Connect session management follows a polling mechanism.

How the authentication is handled in OpenID Connect

OpenID Connect performs authentication to make sure that the end user is logged in at the OpenID provider’s end. Iit returns the result to the relying party by using an ID token which contains the login status of the end user and the claims with information on the issuer, authentication expiration and so on.

There are three main flows for OpenID Connect to do the authentication which is decided by looking into the 'response_type' value of the authorization request. The three authentication flows are as follows;

• Authorization Code Flow
• Implicit Flow
• Hybrid Flow

Authorization Code Flow

Authorization code flow does not provide any access token to the client. Instead, it gives an authorization code which can be directly exchanged to an ID token and an access token. The authorization server is capable of authorizing the client only after this exchange is complete. This mechanism keeps the channel secure since a other third party cannot get an access token from the authorization server. Due to this secure mechanism, the authorization code flow is suitable only for clients who are capable of maintaining a client secret between itself and the authorization server securely.

Implicit Flow

In Implicit flow the ID token and access token are directly returned to the client. When using the implicit flow authorization, the server does not perform client authentication. This flow is mainly used by web browser clients such as scripting clients. Implicit flow does not use the token endpoint. Instead, it returns all the tokens from the authorization endpoint.

Hybrid Flow

When authentication is done using the hybrid flow, some of the authentication tokens are returned from the authorization endpoint and some of them are returned from the token endpoint.

There are two methods of implementing a relying party for OpenID Connect protocol. These are;

• Basic client profile
• Implicit client profile

With a basic client profile you can implement a basic web based relying party for OpenID Connect. The basic client profile uses OAuth authorization code flow. A basic web based relying party which uses the OAuth implicit workflow can be implemented with the help of the implicit client profile. The basic client who is following the authorization code flow is capable of securely maintaining a client secret between itself and the authorization server. But in some cases the applications and other clients who are not capable of maintaining the client secret value securely use the authorization code flow to obtain a fresh token.

How OpenID Connect protocol works

The following diagram briefly explains how OpenID Connect protocol operates.

Figure 2

1. The relying party sends the request to the OpenID provider to authenticate the end user
2. The OpenID provider authenticates the user
3. The OpenID provider sends the ID token and access token to the relying party
4. The relying party sends a request to the user info endpoint with the access token received from OpenID provider
5. The user info endpoint returns the claims.

WSO2 Identity Server with OpenID Connect

The WSO2 Identity Server supports several SSO authentication mechanisms such as SAML, OpenID, OpenID Connect and passive STS. When considering the OpenID Connect, WSO2 Identity server can act as the OpenID Connect authorization server as well as the relying party. You can simply configure the WSO2 Identity Server to be your authorization server by changing the identity.xml file which resides in the IS directory/repository/conf. directory.

You can deploy your OAuth 2.0 sample into the tomcat server that comes with WSO2 Identity Server and register an application for that by following some simple steps using the IS console.

All information regarding how to configure the WSO2 Identity Server to act as an authorization server for OpenID Connect, how the basic client profile works with WSO2 Identity Server and how to register an application for a OAuth 2.0 app is mentioned in detail here.

Summary

OpenID Connect is an interoperable authentication protocol built on top of OAuth 2.0. Because its based on OAuth 2.0 it is advantageous to the developers as they can easily implement it with simple deployments. The WSO2 Identity Server enables OpenID connect with just a few simple configurations.