A basic understanding on OpenID connect 1.0 (OIDC)
In my first week at WSO2 Identity and Access Management team, OpenID Connect is a new word I heard. When I was exploring what is OpenID Connect, there were some interesting stuffs I got to know.
Earlier I had confusion with OAuth and OpenID connect. In my last post , I had a quick glace at OAuth. In OAuth, client doesn’t know any authentication information of end-users. OAuth provides only and should only authorization using access token. So how can a third part app know about end-user? It also needs some sort of information about end-user. Right?
OpenID Connect solves this issue. OpenID connect is built on top of OAuth 2.0 in order to provide user authentication information.
“OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an inter-operable and REST-like manner (see OpenID connect 1.0 Specification).”
Simply we can think,
OpenID Connect= OAuth 2.0 + User Information
How does OIDC 1.0 work?
All the steps up to step 4 are related with OAuth2.0 . Step 4 and 5 determine the flow of OpenID Connect. After getting Authorization response (authorization code) from OpenID Provider(OP- In OAuth flow, we call it as Authorization server) Relying party (RP- in OAuth work flow, we call it as client/service provider) will request for user information. OpenID Provider will send the details (eg: subject, email,.. which are allowed by the end-user to share) to the Relying Party as an ID token which is embedded with the access token.
OpenID Connect was introduced in 2014 and it plays an important role in WSO2 identity server.
Next We will see in details what is an ID token?
“The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims .”(claim-Piece of information asserted about an Entity)
In simple words, ID token is similar to our Identity Card . But not like our identity card, the ID Token is represented as a JSON Web Token (JWT).
Since the ID token consists user information, ID token should be sent to the Relying party in a highly secured manner. In order to ensure authenticity and integrity, ID tokens should be signed using JSON web signatures (JWS) and after that it can be encrypted using JSON Web Encryption (JWE) to ensure confidentiality[ signing of ID token is mandatory but encrypting the signed ID token is optional] .
When Relying party requests for user information, both ID token and access token are summed up and sent to the relying party by the OpenID provider.
Response of the OpenID provider will look as follows,
In the above picture, id_token is a JSON web token. It consists user information as illustrated below.
In the ID token,
- iss — issuer(issuer identifier)
- sub- subject(a locally unique identifier within the issuer for the end-user)
- aud- audience(client_id of the relying party/parties)
- exp- expiration time(Expiration time on or after which the ID Token must not be accepted for processing)
- iat- issued at(time at which JWT was issued. 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.)
- also email, auth_time are optional.
Learn, code !
