In previous videos in this series we looked at OAuth and how it’s used to provide authorization
in the cloud with consent.
In this video we’ll look at how OpenID Connect provides an Identity Layer to OAuth.
OpenID Connect is a simple identity layer that sits on top of the OAuth 2.0 protocol.
It enables clients to verify the identity of the End-User based on the authentication
performed by an Authorization Server.
Open ID Connect also obtains basic profile information about the End-User using REST API's
OpenID Connect is needed because even though OAuth provides authorization, it does not
provide authentication!
With OAuth, the user authenticated and proved they were present to the Authorization Server,
but the sole purpose of this was to create and grant an access token to the client application.
The User did not authenticate directly with the client application itself.
OAuth provides a level of pseudo-authentication.
It provides a grant or license to access resources rather than provide information about the
authentication itself.
To put it another way, using OAuth for authentication is like an apartment manager giving someone
who wants to know your identity, a temporary key to your apartment.
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 .For example, it can’t provide
the when, where and how the authentication actually occurred.
It doesn’t allow federated single sign on, either.
OpenID Connect can extend OAuth so cloud based applications can get identity information,
retrieve details about the authentication event, and allow federated single sign on.
To understand how OpenID Connect works, we’ll review basic concepts such as Participants,
Identity Tokens, Claims and Scopes, and Endpoints.
Let’s first look at the participants.
The End User is the entity for whom we are requesting identity information.
In OAuth 2.0 this refers to the resource owner and one of the resources they own is their own identity.
The Relying Party is an OAuth 2.0 client that relies on the Identity Provider to authenticate
users and request claims about that user.
The Identity Provider is an OAuth 2.0 authorization server which offers
authentication as a service.
It ensures the End-User is authenticated and provides claims about the End-User and the
authentication event to the Relying Party.
Identity Tokens and Claims 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.
These claims are:
Subject, Issuing Authority, Audience, Issue Date and Expiration Date.
The Subject is a unique identifier assigned to a user by the Identity provider, for example
a username.
The Issuing Authority is the Identity provider that issued the token.
The Audience identifies the Relying Party who can use this token.
The Issue and Expiration Date is the date and time the token was issued and will expire.
There are also a number of optional claims that help the relying party validate the ID token,
such as Authentication time which shows the time the End-User was authenticated and
Nonce values which mitigate replay attacks.
The token may also contain additional requested claims about the subject such as name and
email address.
As with access tokens, the ID token is encoded as a JSON Web Token or JWT.
The claims in the token form part of the payload.
Like an access token, the ID token is also digitally signed using JSON Web Signature
to achieve integrity and non-repudiation.
The Header, Payload and Signature are combined into a JWT and may also be encrypted with
JSON Web Encryption for confidentiality.
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 which 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 request that specific sets of information are made available as claim values.
The 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, and 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.
Alternatively they 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 Authorization Endpoint, the Token Endpoint and the UserInfo endpoint.
The Authorization endpoint is 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.
The token endpoint authenticates the client application.
It also exchanges the authorization code from the Authorization endpoint, for an ID token,
an access token and optional refresh token.
The 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.
We reviewed the basic concepts of Open ID Connect.
This included defining participants, identity tokens, claims and scopes, and endpoints.
In the next video in this series we will examine these flows in detail, and see how ID tokens
and user information are exchanged.
Thank you for watching.