The Basic Idea of OpenID Connect

OpenID Connect is a simple identity layer that sits on top of the OAuth 2.0 protocol.

It allows clients to verify the identity of the end-user(resource owner) based on the authentication performed by an authorized server.

The OpenID Connect obtains basic profile information about the end-user using the REST API’s.

OpenID Connect is needed because even though OAuth provides authorization, it does not provide authentication!

With OAuth, the user authenticated and it has been confirmed that the user was present to the authentication server, but the sole purpose here is to create and issue an access token to the client application.

The user is not directly authenticated with the client application itself.

OAuth provides a level of pseudo-authentication.

OAuth provides a grant or licenses to access resources rather than provide information about the authentication itself.

Ex: Using OAuth for authentication is like

an authorized person giving someone who wants to know your identity, a temporary key to your room.
The key only implies a right to enter the apartment for a specific length of time.
It does not imply that the individual is the owner.
There’s no identity implication at all.

OAuth pseudo authentication also has other limitations.

It can’t provide

• When
• Where
• How

the authentication actually occurred.

It doesn’t allow federated single sign-on.

OpenID Connect can extend OAuth so,

• Cloud-based applications can get identity information,
• Retrieve details about the authentication event,
• Allow federated single sign-on.

To understand how OpenID Connect works, we’ll review basic concepts,

1. Participants
2. Identity Tokens
3. Claims and Scopes
4. Endpoints

Participants

1. The End User is the entity for whom we are requesting identity information.(e.g. Niluka)

In OAuth 2.0 this refers to the resource owner and one of the resources they own is their own identity.

2. The Relying Party is an OAuth 2.0 client that relies on the Identity Provider to authenticate users and request claims about that user. (e.g. Medium)

3. The Identity Provider is an OAuth 2.0 authorization server that offers authentication as a service. (e.g. WSO2 identity server)

It ensures the End-User is authenticated and provides claims about the End-User and the authentication event to the Relying Party.

Identity Tokens

So how does the Identity Provider provide the Relying Party information about the identity of the End User?

The answer is through an Identity Token.

The identity token is similar to an ID card or passport.

It contains a number of required attributes or claims about that end User but also how the End-User was authenticated.

The ID token statements, or claims, are packaged in a simple JSON object

These claims are:

1. Subject(sub): The Subject is a unique identifier assigned to a user by the Identity provider, e.g. a username.
2. Issuing Authority(iss): The Identity provider that issued the token. (https://localhost:9443/oauth2/token)
3. Audience(aud): Identifies the Relying Party who can use this token. This must contain the client_ID of the Relying Party.
4. Issue Date(iat): The date and time the token was issued.
5. Expiration Date(exp): The date and time the token will expire. After this time the ID_Token should not be accepted.

There are also a number of optional claims that help the relying party validate the ID token.

5. Authentication time(auth_time): Which shows the time the End-User was authenticated.

6. Nonce(nonce): Values that mitigate replay attacks.

The token may also contain additional requested claims about the subject such as name and email address.

Like Access Tokens, the ID token is encoded as a JSON web token or JWT.

1. The claims in the token form part of the payload.
2. Like an access token, the ID token is also digitally signed using JSON Web Signature to achieve integrity and non-repudiation.
3. The Header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.
4. The Header, Payload, and Signature are combined into a JWT and may also be encrypted with JSON Web Encryption for confidentiality.

Claims and Scopes

OpenID Connect uses claims to retrieve information, but it can also use scopes.

The OpenID Connect specification contains around 20 standard claims and four standard scopes that are used to supply the client application with consented user details.

A claim is an individual piece of information, for example, a family name or email address.

Scopes are used to requesting that specific sets of information are made available as claim values.

“openid” scope is a mandatory scope to specify that OpenID Connect is required. In addition, there are four standard scopes predefined in OpenID Connect:

* profile

• email
• address

* phone

For example, the scope “profile”, requests access to the End-Users default profile claims.

In the initial authentication request, the client application can request scopes or claims to be returned in the Identity Token.

Endpoints

Alternatively, scopes or claims can be requested using an access token through a REST API call to the UserInfo endpoint.

The OpenID Connect Identity Provider has a number of End Points with which the End-User and Client Application interact.

These are the Endpoints,

• Authorization Endpoint: Where the End-User is asked to authenticate and grant the client application consent to access their identity, and any other required information such as email, or address.

This extra information is called UserInfo claims.

Once consent is given, this endpoint passes back an Authorization code.

This is the endpoint in which the End-User indirectly interacts with the Identity Provider through a user agent, for example, a browser.

• Token Endpoint: Authenticates the client application.

It also exchanges the authorization code from the Authorization endpoint, for an ID token, an access token, and an optional refresh token.

• UserInfo endpoint is an OAuth 2.0 protected resource that is used by the Identity Provider to return consented user information or claims to the client application, provided that a valid access token is presented.

These are the basic concepts of OpenID Connect.

Thanks for reading ….…...😄