Hello everyone, In this blog we will try to understand Federated Authentication and Authorization concept and will try to see how Sitecore uses this concepts to perform Authentication and Authorization.
Let's begin. We will see basic terminology like OAuth 2.0, OpenID Connect etc. which is mostly used in implementing the Federated login mechanism.
OAuth 2.0 : OAuth 2.0, which stands for “Open Authorization”, is a standard designed to allow a website or application to access resources hosted by other web apps on behalf of a user.
OpenID: OpenID is a unified user identification method released as an open standard that essentially acts as a single user identification system that can be used across multiple websites. It is a wrapper made on top of OAuth 2.0 which provide the functionality of Authentication.
Resource Owner : User who is trying to login on an application
Client : An Application which provide the interface where user can click on Sign In button.
Authorization Server : It is the Third party application hosted on a different server basically known as Identification server which try to Authenticate and Authorize the user
Resource Server : This server provide the authorized resources or data for the logged in user. Sometime Resource Server and Identity Server are same only.
Redirect URI : The URI which is also called as Callback URL which receives the Authorization code from Authorization Server which is again pass to Authroization server to get the access token which the client can use for getting Authorize resources. In this parameter, internally the Return URL is passed a query string parameter on which User is redirected on successful login.
Access Token: Token which is basically a JWT token which contains information regarding the access level of User. Basically this token helps Identity Server to only serve Authorize resource from Resource Server
ID token : Contains logged in User Information.
Scope : What level of access is defined for this User on Identity Server. This is determine by sending scope parameter in request during the call.
Client Id : Application registering themselves with Identity Server to get a unique Client Id
State : Normal text message which is passed TO and FRO between Servers in the request.
Client Secret : This is secret key which the Identity Server provides the application who are registering. This is very sensitive data and it is unique for each application. This secret key is passed to Authorization Server or Identity Server by client application during Token exchange process. The exchange process happens at backend system only. We should never expose the Client Secret on browser network tab.
Authorization Grant Type : An authorization grant is a credential representing the resource owner's authorization (to access it's protected resources) to the client and used by the client to obtain an access token.
There are 5 type of Authorization Grant available which is used
Authorization Code Grant Type : Most used grant type. Used to authorize the Client to access protected data from a Resource Server.
Implicit Grant Type : Implicit Grant Type is intended to be used by user-agent based clients (Example: SPA), which can’t keep a client secret because all of the application code and storage is easily accessible.
Resource Owner Credentials Grant Type : The Resource Owner Credentials Grant Type uses the username and the password credentials of a Resource Owner (user) to authorize and access protected data from a Resource Server
Client Credentials Grant Type : The Client Credentials Grant Type uses the Client Id and the Client Secret credentials of a Client to authorize and access protected data from a Resource Server.
Refresh Token Grant : The Refresh Token Grant Flow is specially used to gain new access token from the Authorization Server by providing the refresh token call to the Token Endpoint
Now let's try to see all this concept by using a Simple Flow Diagram.
In the above flow diagram, Lets consider Client Application is ABC.com. This application is allowing user to Sign In using Gmail. So for User the Authorization Server is Google. When user click on Sign in button, he will be redirected to Google verfication page. User will pass the above shown parameter in request as query string parameter. This will include Client ID, Scope, Grant Type,State,Redirect URI. This Redirect URL internally have the return url parameter to which the ABC.com redirect after successful login. The Resoruce Server can be any Google Interal Application. For example: Google Conatct API
When user validates on google verification page, the Authroization server sends Auth Code to the Client Application on successful validation. Then Again the Client Application request the Authorization Server to get the Access Token and ID token in exchange of Auth Code.The Client Application sends few extra parameters along with Auth Code and that are Client ID,Client Secret,Grant Type. The Authorization Server will validate the Auth Code and if it is validated successfully then it returns the client with Access Token and ID Token. The Client Application can use the Access token to get resources from Resource Server based on access defined in that Access token.
Now as we have understood, the OAuth 2.0 and OpenID concepts, we will see how it is related to Sitecore.
From Sitecore 9 onwards, Sitecore is using Identity Server (Authorization Server) for authenticating the user.Once the User is Authenticated it also provide the required Authroization resources to the logged in User.
I have attached the same flow explained above in the blog for Sitecore. You can relate Sitecore Login Mechanism with the above example explained. Please refer the network tab request.You will see the request starting when user invokes the Sitecore CMS url. Example: https://{instance name}/Sitecore
If you see the above network tab request, It is behaving like the example which we have seen. Passing the Auth Code and Client Secret step happens at backend for getting the access token to ensure security.Once all Step are completed, we will get the Sitecore LaunchPad Page.
This blog explains the basic understanding of Federated Login. In the next blog we will see how we can implement third party identity provider which will help us to get achieve both Authentication and Authorization using the Sitecore inbuilt mechanism.
Hope you liked this blog.The blog is little lengthy but I have tried to explain whatever I have learned recently.Thanks for reading and happy learning.
Comments
Post a Comment