OIDC authorization code flow for secure access
Once upon a time there lived a guy called Mr. Innocent who had his whole pictures in Ji-Drive. At that time, he got to see a trend where everyone upload their cover pictures with their Avatar instead of their original photos. He also wanted to match with the current trend. Mr. Collector who is his friend sent a link “changeMickey.com” which is the web application that is used to edit the faces to an avatar. When he clicked the app excitingly, initially the app asked to upload the picture. The App provided two options when the needed photos are in drive. One is to download the picture from the drive and upload it here or upload the photos directly by connecting the drive with the application. As Mr. Innocent is somewhat lazy he went with the second method. When the app tried to use the drive the Drive refused to connect without the consent of the owner. The App asked Mr. Innocent for the username (Innocent24) and password (P@ssw0rd) so that the app can use the username and password on behalf of Mr. Innocent.
Ouch…Mr. Collector tried hard just to get these username and passwords. Mr. Innocent you really need to know of password policies.
However Mr. Innocent disagreed to give the username and password. This is where OAuth comes into action. OAuth is for the authorization of one service with another service. OAuth is like a valet key of the car with limited access. If there is a need to grant permissions to access data in a secure way OAuth 2.0 protocol is the finest approach. With the help of the access token, the services get access to the required services more securely.
Open ID Connect simply known as OIDC is an authentication standard assembled on top of OAuth 2.0. OIDC provides an Identity token with the access token which is considered as a major modification between OIDC and OAuth2.0. The main key roles involved in the flow in the Open ID Connect Provider are as follows:
Resource owner who is the owner of the account including its data, identity and the actions carried out with the account.
Client Application which is the application which needs access to perform actions. Implements actions on behalf of the resource owner.
Authorization Server which is the application which knows resource owner when there is an account to resource owner. Here We are using our WSO2 Identity Server as an Authorization Server.
Resource Server which is the service or the API the client needs to use on behalf of the resource owner.
Considering the flow of OIDC there are three main types of flows namely Authorization code flow, implicit flow, and hybrid flow. Based on the need and considering security protocols the type of flow implementation is chosen. In view of Authorization code flow, it is the most secure way of accessing data. The initial steps of the OIDC flow are as same as OAuth 2.0 but the change happens when the client sends an authorization token to the authorization server. Here in addition to the access token, an ID token is also given. The ID token is a JWT that can be extracted by the client.
So Initially, the application directs the browser to the sign-in page of the WSO2 Identity Server. When both of the services have OAuth implementation for the authorization of the resource owner the application is directed to a sign in page by the WSO2 IS.
IS redirects the authorization prompt to the resource owner. To ensure the service is asked by resource owner authorization prompt is send including the details of the activity.
Here, Redirect URI or Call back URL which is the URL that is redirected back by the Server the after the resource owner grant the required permission of access, Response Type is the type of information the client wishes to receive and in our case it’s the code. Client ID which is created when the app is registered in the server is used to identify the client by authorization server.
Then the user overview the access permissions and authenticates using the username( Innocent 24) and password (********). After the authentication authorization server sends the authorization code that only works for short period of time which is sent to client from authorization server to get access token to the client. To collect the access token the client sends the authorization code to the server where it identify the grant is valid or not.
The authorization server returns the access token, ID token, and refresh token. It Creates and sends an access token with the details of permissions granted that are secured which expires after a certain time. Therefore in addition to an access token, a refresh token is also given. In ID token the user related information are provided such as who is the user, when and where the user authenticated, how the user authenticated and list of attributes the user can give.
The client calls the resource server with the access token and ID token on behalf of the resource owner.
Hereafter whenever the client needs details from the resource server, the client sends the access token. Resource validates the token and responds to the request. Access token will be verified by the resource server some times with the help of authorization server and the required data will be transferred.
Now Mr. Innocent got to know of this ideology and then he searched for a new client application to make the avatar and successfully found “changeTom.com” . Now his friends are starting to get irritated on Mr. Innocent for his new avatar photos which are being uploaded in every social media.
