OIDC Authorization Code Flow internals in WSO2 Identity Server
After Mr. Innocent got to know about the OIDC Code flow, he prepared a blog to submit for Mrs. Casey’s Assignment.
You can also find out about the OIDC Code Flow by following this link: OIDC authorization code flow for secure access.
Alex Stewart and Rosie Dunne, who are best friends, got a chance to read his blog. They found it interesting and they wanted to know more about that. So they browsed changeTom.com and when they tried to log in to the system. They noticed that the website redirected them to the WSO2 Login portal. ChangeTom.com has a WSO2 Identity Server as the authentication server.
Do you know that now you can change the UIs of the WSO2 login page for your web application? Yeah, From WSO2 Identity Server 5.9.0, you can rebrand your WSO2 IS UIs. To know more about that follow the link here: Re-branding WSO2 Identity Server UIs.
Alex and Rosie downloaded and installed the WSO2 Identity Server and cloned the carbon identity framework in their system to understand the system by debugging. They deployed one of the sample applications and they configured the OIDC for that application in WSO2 IS by following Configuring OAuth2-OpenID Connect guide and they started to understand the process of the flow by debugging the identity framework. To know more about Remote Debugging WSO2 products using Intellij idea IDE.
Considering the OIDC flow, the resource owner needs to grant access permissions to the client. The client gets redirected to the authorization server with requests and parameters such as client ID, redirect URI, response type and scopes. The authorization server then verifies the client and requests the owner to grant access to the access permissions. After granting the authorization, the server is redirected to the client using the redirect URI and is redirected with a temporary authorization code. Hereafter the client deals with the authorization server directly on behalf of the user using the Authorization code, client ID and client secret where the authorization server checks them and if the grant is valid it responds with an access token with details of permission granted and the ID token including user-related information. In the future, the access token is sent to the resource server on behalf of the owner to obtain the required services of the client.
In WSO2 Identity Server, there are two main components that take part in the authentication process for OAuth/OIDC flow.
- OAuth component — responsible for handling the protocol flow
- Framework component — responsible for the user authentication process
At the database level, there are two tables for storing the authentication process information.
- idn_auth_temp_session_store
- idn_auth_session_store
Whenever the control of the process is handed over to the user, the server will store the status of the process as a temporary placement in the idn_auth_temp_session_store. For example, If we have a Multi-Factor Authentication, we have to store the results of the first step before the second step of the authentication then, server store the results of the first step in the idn_auth_temp_session_store and sends back the response to the user. Here we are going to store the data in the form of the object (BLOB). Those tables contain session id, session type, operation, session object, created time, tenant id, and expiry time. The object is stored in the session object that has several session types. Those types are stated below with the reasons for utilizing them.
Initially, when an OAuth2/Authorize requests to enter into the server, the OAuth component which contains the client id and other parameters will validate the request.
Where Request URL contains the following values in the payload
After the validation, the OAuth component stores the data of the request in the database as OAuth Session Data Cache and Authentication context cache.
- OAuth Session Data Cache contains the data that is related to the protocols such as OAuth2 Parameters, redirect URI, client id and a few other similar data.
- Authentication Context Cache contains the fields necessary for the authentication process.
Here both ‘OAuth Session Data Cache’ and ‘Authentication Context Cache’ belong to the temporary session type and they are stored in a temporary store. It contains 302 as a status code which denotes the temporary movement of the resource requested to a URL given by the Location header. As per the status code, there is a location header in response headers.
The URL in the Location header of the request redirects to the Login page of the WSO2 Identity Server.
When user credentials are provided on the Login page and submitted then those credentials will be sent through commonauth. The form values can be checked in the payload of the commonauth.
commonauth has user credentials and sessionDataKey that is used to get the Authentication Context Cache which was stored in the previous step. Here I configured the claim configuration as the application asks for the title of the user where the claim will be a missing claim so the server needs to prompt the title from the user.
As shown in the figure, since the status code of commonauth consists of 302, the location header will have the URL which redirects to the prompt page of the missing claim.
When the claim value is submitted, those values and session data key will be sent through the commonauth.
Again when the server gets the authentication context cache using the session data key, it validates the session and sets the values and stores the authentication context cache over again. In the meantime Framework component stores, the data such as authenticated sequence, authenticated identity providers and a few other data related to the session and they are stored in the name of the AppAuthFrameworkSessionContextCache in the idn_auth_session_store. Furthermore, it contains another entry that contains the information such as authenticated user’s information, authenticated identity providers and data that belongs to the results of the authentication process which are called in the name of the AuthenticationResultCache in the temporary store. Then the OAuth2/Authorize response is sent with the session key.
As shown, as it has a 302 status code, it has a redirect URL in its location header of the response headers where that URL will redirect to the consent page to ask permission to share the claim details with the client application
Once the user allows the consent, the server will add the data which is similar to a session state that contains the data of the authenticated user, session participants and a few similar data that are needed for the OIDC protocol. The data will be stored in idn_auth_session_store where OIDCSessionParticipantCache is a type of session. With that, once the authentication process is completed Authentication Context Cache and Authentication Result Cache will be removed from the temporary session store. Then the Framework component hands over the control to the OAuth Component again, and it will create the Authorization Grant cache object in the idn_auth_session_store. Meanwhile, the server sends the call-back URL with the authorization code to the client. Those data will be added to that object
It has an authorization code which we can check in the payload.
The OAuth component itself retrieves the data stored by it in the initial step and the Authentication Result cache stored at the end of the authentication process by the framework component will be analyzed and it will be redirected to the respective page. If the user provides the correct credentials then it will redirect the user to the home page.
It will redirect to the home page of the client application. And also there will be a response with tokens.
When the server gets the token, it will store them in the authorization grant cache and when the authentication process is finished the authorization grant cache can be deleted. But in idn_auth_session_store, entries are not removed in the same manner. The operation is added as DELETE and the system will remove the entry when there is less traffic on the server. After this, when there is a need for service from the client it sends the access token to the resource server and the resource server validates the grant by sending it to the Authentication server and verifying the details. The access token may expire after a certain period, therefore initially a refresh token is sent with the access token, so that when the access token expires the client sends the refresh token to the Authentication server and receives the new access token without requiring the involvement of the resource owner.
Alex and Rosie came to an understanding of what happens when there is OIDC code flow during the authentication process of the WSO2 IS. Alex logged into changeTom.com to create their avatar photos and Rosie wanted to make a blog about this, to do that she wanted to create some graphical images so she wanted to log into the “whereRainbowsEnd.com”. When she clicked the login button of the whereRainbowsEnd.com, It didn’t redirect to any other login page instead of that it directly allowed her into the site. She noticed that it already had an account in Alex’s profile. But Alex was sure that he didn’t create an account on that page. So They logged out from the page and when they tried to log in to whereRainbowsEnd.com, It redirected them to WSO2 IS login page. They opened the changeTom.com tab, It was also already logged out. They again got confused and when they searched about that they identified the term SSO — Single Sign-On. They wanted to know about that also. So they again started to debug the system.
This is happening because of the Single Sign-On facility of the WSO2 Identity Server. When the user provides his/her user credentials, there will be a commonauth cookie setup.
And when the user tries to sign in to another client application of the WSO2 IS. There is a commonauthID cookie in the cookies of the request. So the server will check that cookie and retrieve the status of the user and it allows him/her into the system without the authentication.
“Hey Alex, look Innocent also used this computer to draft his blog”
“Yeah, I can see his username there”
Alex typed something.
“What are you doing?”
“I entered his password, but it’s not working?”
“What is that “password” password?.. He mentioned password policies in his previous blog also. I am sure he changed the password”
“Ohhh… then try Innocent1998”
“Alex, You are a genius, We logged into his account”
“Rosie, let’s change Mrs. Casey into Mrs. Big nose Casey”
“Poor Innocent, He still doesn’t understand about the password policies”
