The wide story of OpenID Connect
“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 interoperable and REST-like manner.”
Why we need OpenId Connect and what is the major difference from OAuth2.0?
As mention in the definition, OpenId Connect (OIDC) is the identity layer on top of the OAuth 2.0 protocol. The basic access token flow in the OAuth 2.0 protocol is the Resouce owner (user) request for service from the client (third-party application). The Client (third-party application) sends the access request with its own identity to the authorization server ( facebook). The authorization server (Facebook) gets the authentication request and verifies the identification of the third party application. After verification, authorization server requests to the resource owner(user) to authenticate them self and get consent to allow the client (third-party application) to access their resources mention in the concent interface. After getting positive consent from the resource owner, the authorization server sends the Access token to the client application for access the resource server. (follow OAuth2.0 to know more about OAuth and Access delegation)
In this flow, the Client request for access the Authorization server then the server returns the access token to the client for access the resource. The client application doesn't know anything about user-related information. To overcome this issue, we apply the OpenID Connect (OIDC) as an identity layer on top of the OAuth 2.0 protocol to know about user information from the client side.
We can obtain client information with the help of three common widely used OpenID flows.
1. OpenID with Authorization code flow
Authorization code flow was used by OAuth2 and provides a way to retrieve token on a back-channel.
Step1: The Resouce owner (user) request for service from the client (third party application)
Step2: Client sent the authorization request to the Authorization Server with the response_type as code and scope as openid
https://server.example.com/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkjStep3: Authorization server gets the authentication request and verifies the identification of the third party application. After verification, authorization server requests to the resource owner(user) to authenticate them self and get consent to allow the client (third-party application) to access their resources mention in the concent interface.
Step 4: After getting positive consent from the resource owner, If the end-user grants the access request then the Authorization Server sends the success message with a code.
Step5: The client sends the access token request to the Authorization Server token endpoint with the code.
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Step6: The client verifies the code and sends back the Access Token along with the ID-Token. The ID token contains the user information.
Further more details visit: https://openid.net/specs/openid-connect-basic-1_0.html
2. OpenID with Implicit flow
The Implicit flow depends on the front-channel (browser-based calls) to retrieve tokens. We can not generate a refresh token using Implicit flow. Therefore it’s not recommended for sort validity period access token generation.
Step 1: The Resouce owner (user) request for service from the client (third party application)
Step 2: The Client (third-party application) sends the access request with its own identification. In addition, Client sents the openid as scope and response type as id token.
https://server.example.com/authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2MjStep 3: Authorization server gets the authentication request and verifies the identification of the third party application. After verification, authorization server requests to the resource owner(user) to authenticate them self and get consent to allow the client (third-party application) to access their resources mention in the concent interface.
Step 4: After getting positive consent from the resource owner, the authorization server sends the Access Token and ID token to the client application. The ID token contains the user information.
HTTP/1.1 302 Found
Location: https://client.example.org/cb#
access_token=SlAV32hkKG
&token_type=bearer
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&expires_in=3600
&state=af0ifjsldkjFurther more details visit: https://openid.net/specs/openid-connect-implicit-1_0.html
3. OpenID with Hybrid flow
It is the combination of Implicit and authorization code flow. It allows requesting a combination of ID-Token, Access Token and Code via front-channel.
There are three major Hybrid flows,
3.1 Code Token
Step1: The Resouce owner (user) request for service from the client (third-party application).
Step2: Client sent the authorization request to the Authorization Server.
https://localhost:9443/oauth2/authorize?response_type=code token&client_id=<Client ID>&nonce=asd&redirect_uri=http://localhost:8080/playground2/oauth2client&scope=openid
Step3: Authorization server gets the authentication request and verifies the identification of the third party application. After verification, authorization server requests to the resource owner(user) to authenticate them self and get consent to allow the client (third-party application) to access their resources mention in the concent interface.
Step 4: After getting positive consent from the resource owner, If the end-user grants the access request then the Authorization Server sends the success message with a code and Access token.
Step5: The client sends the token request to the Authorization Server token endpoint with the code, Client-ID, and Client-Secret.
curl -k -v — user <Client ID>:<Client secret> -d “grant_type=authorization_code&code=99b34587–5483–374d-8b25–50485498e761&redirect_uri=http://localhost:8080/playground2/oauth2client" https://localhost:9443/oauth2/token
Step6: The client verifies the code and sends back the Access Token along with the ID-Token.
3.2 Code ID-Token
Step1: The Resouce owner (user) request for service from the client (third-party application).
Step2: Client sent the authorization request to the Authorization Server.
https://localhost:9443/oauth2/authorize?response_type=code id_token&client_id=<Client ID>&nonce=asd&redirect_uri=http://localhost:8080/playground2/oauth2client&scope=openid
Step3: Authorization server gets the authentication request and verifies the identification of the third party application. After verification, authorization server requests to the resource owner(user) to authenticate them self and get consent to allow the client (third-party application) to access their resources mention in the concent interface.
Step 4: After getting positive consent from the resource owner, If the end-user grants the access request then the Authorization Server sends the success message with a code and ID-Token.
Step5: The client sends the token request to the Authorization Server token endpoint with the code, Client-ID, and Client-Secret.
Step6: The client verifies the code and sends back the Access Token along with the ID-Token.
3.3 Code ID-Token Token
Step1: The Resouce owner (user) request for service from the client (third-party application).
Step2: Client sent the authorization request to the Authorization Server.
https://localhost:9443/oauth2/authorize?response_type=code id_token token&client_id=<Client ID>&nonce=asd&redirect_uri=http://localhost:8080/playground2/oauth2client&scope=openid
Step3: Authorization server gets the authentication request and verifies the identification of the third party application. After verification, authorization server requests to the resource owner(user) to authenticate them self and get consent to allow the client (third-party application) to access their resources mention in the concent interface.
Step 4: After getting positive consent from the resource owner, If the end-user grants the access request then the Authorization Server sends the success message with a code, Access token, and ID-Token.
Step5: The client sends the token request to the Authorization Server token endpoint with the code, Client-ID, and Client-Secret.
Step6: The client verifies the code and sends back the Access Token along with the ID-Token.
Further more details visit: https://docs.wso2.com/display/IS570/OpenID+Connect+Hybrid+Flow
ID Token
ID Token is a simple JSON Web Token(JWT) that contain the user information sent by the Authorization server. Using ID Token, we can find who is the user got authenticated, when he got authenticated, how he got authenticated, what are the attributes that the user can share and why the user shares that attribute.
In general, ID-Token sign by the JSON web signature and encrypted by the JSON web encryption to increase the authenticity and security. We can decode ID-Token and can see the user information using jwt.io.
sample ID token,
eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiSnJaWTlNdFlWRUlJSlV4LUREQm13dyIsInN1YiI6ImFkbWluIiwiYXVkIjpbIm5jemJnNW01eHh0NnRQNFVNWndCNlB0UW9Rb2EiXSwiYXpwIjoibmN6Ymc1bTV4eHQ2dFA0VU1ad0I2UHRRb1FvYSIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTUxMDgzMTAxMCwibm9uY2UiOiJhc2QiLCJpYXQiOjE1MTA4MzEwMDd9.XKV0ioEvflR4MHGthO3cwXwC88msNgqR4l1O83mfhxOMtO1PG3ABWB5E4aFXFpR9t-8zJs09slhLsDTDhmC33KE8Die61UK9_Vb5aNA4XCkawyJt8dCX6clc6UUbTEO5N1ubXA18QFgwAEWpvoTz1hKx8XLnvOSehbdEKsoPunoHDmXpYJe_9hBg5V3kN-VHxdKdGOtl9u-Aml42s5p45cZY0mlFVcKjatBAf7hqWNPlUebyujDWG1Iyk_-AXNQ2wYi0F77uG7_HstP_tp0sOctu0TYCK8bwBTXEJYMPt1CqOqcae05m8N8hb0zs6Yxvyx_udCJPG-8n2zRB-T-kcg
The ID-Token contains three main parts separated by a full stop.
1.HEADER: It contains the metadata of the token (ALGORITHM & TOKEN TYPE).
2. PAYLOAD: It contains the user’s information.
- sub: Identity of the user
- aud: Audiences that this ID Token is intended for (client)
- iss: Issuer Authority
- exp: Expiration time
- iat: The time that JWT was issued
3. VERIFY SIGNATURE: It contains validated and trust the token from the application site.
WSO2 Identity server supports the OpenID connect for get the user information. Please visit https://wso2.com/identity-and-access-management/ for further information.
try openID connect tutorials with WSO2 Identity server, https://docs.wso2.com/display/IS570/OpenID+Connect
*************************** END *************************
