OpenId Connect Terminologies

Here is the important terminology of OpenId Connect.

Identity token

While discussing OAuth, we discussed the authorization code and access token. In the case of OpenId Connect, there is one more token that we can request. This token is called the identity token, which encodes the user’s authentication information.

In contrast to access tokens, which are only intended to be understood by the resource server, ID tokens are intended to be understood by the client application. The ID token contains the user information in JSON format. The JSON is wrapped into a JWT.

When a client receives the identity token, it should validate it first. The client must validate the following fields:

1. iss - Client must validate that the issuer of this token is the Authorization Server.
2. aud - Client must validate that the token is meant for the client itself.
3. exp - Client must validate that the token is not expired.

Here is some sample user information in the form of JSON present in an identity token.

{
  "iss": "https://server.example.com",
  "sub": "24400320",
  "aud": "s6BhdRkqt3",
  "nonce": "n-0S6_WzA2Mj",
  "exp": 1311281970,
  "iat": 1311280970,
  "auth_time": 1311280969,
  "acr": "urn:mace:incommon:iap:silver"
}

Let’s look at what these values mean:

1. iat - The iat claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value must be a number containing a NumericDate value.
2. auth_time - Time when the End-User authentication occurred. Its value is a JSON number representing the number of seconds from 1970–01–01T0:0:0Z as measured in UTC until the date/time.
3. nonce - ID token requests may come with a nonce request parameter to protect from replay attacks. When the request parameter is included, the server will embed a nonce claim in the issued ID token with the same value of the request parameter.

The Identity token contains only basic information about the user. To get the complete user information, the client must send the access token (please note access token should be sent not identity token) to UserInfo endpoint.

Scope

The Identity Provider may have a lot of information about a user. Some of this information can be shared freely with the client apps and some information might be shared under special circumstances.

The client app must also tell the Identity Provider about what user information it is looking for. This information can be provided through the scope field. There are four types of scopes defined in OpenID Connect. Each of these scopes defines certain attributes.

When a particular scope is requested, then all the attributes defined under that scope are returned.

Scope	Purpose
email	Fetch the user’s email information.
phone	Fetch the user’s phone details.
profile	Fetch the user’s default information.
address	Fetch the user’s address.

Please note that there is one more scope value, i.e. openid. This value is mandatory if the client app needs an identity token in the response.