In a microservices architecture, once the user logs in, the identity of the user needs to be communicated to all the services that handles the requests to the application and each service needs to know that this is an authenticated user and need to check whether the user have privileges for requested operation.
The entry point to a microservice based application is an API gateway which hide the complexity due to multiple services from the end user. The gateway will contact an Authentication and Authorization server which authenticates and logs in the user and returns a JWT access token. This access token is further used in each request to verify the identity of the user from Authorization server.
JWT is a Base64 encoded string which can be decoded into a the following (all separated by "."):
1. a header with an algorithm used for signing the token,
2. a payload which consists of basic user info like userId and iat (issued at time) and some basic info but not credentials
3. a footer consisting of a signature generated out of header and payload using the algorithm mentioned in the header and a secret key which is held only by the authorization server.
The JWT token is issued to the user based on the login using the credentials and is typically send in the further requests as a bearer token (by placing Bearer <token> in the Authorization header). The JWT token is normally saved in the cookies for the browser to send it in the further requests.
The authorization server generates a signature by extracting header and payload from the bearer token provided to it and compare with the signature in the bearer token for validating the authenticity on subsequent requests.
OAuth 2.0
Important Terminologies:
Resource owner - The user who owns a resource (e.g. files on a google drive).
Resource server - The server which maintains the resource (e.g. google drive server)
Authorization server - The server which validates authorization to access resource server
Client application - Any client application that wants to access user resource on behalf of the user.
Grant type client credentials
In a microservice architecture, if a microservice needs to access data from another microservice:
1. The Authorization server grants a client credentials access token to the microservice
2. The authorization server validates the requests from the source microservice based on the client credential access token.
3. permission needs to be managed for the client credential access token for restricting the access of the service to APIs in the destination microservice as required.
Grant type authorization code
If a client application wants to access certain details from a resource server on behalf of an end user:
1. The client application sends a request to authorization server requesting the access for the resource.
2. The authorization server redirects to the end user asking him to allow the client application to access the resource on his behalf, the user has to login if he has not already logged in to the authorization server.
3. Once the user gives consent for the client application to access the resource, the authorization server will send an authorization code/token to the client application.
4. The client application may store the same and calls the authorization server with the authorization code to get an access token.
5. The client application uses this access token for communicating with the resource server.
Grant type device code
OAuth 2.0 extension that enables devices with no browser or limited input capability to obtain an access token.
Grant type refresh token
This is used for getting a new access token when the original access token is expired. The original access token will have an expiry time when refresh token is required.
Handling SSO using OAuth 2.0
Although OAuth was meant for authorization, this model is extended to implement Single Sign On using grant type authorization code flow:
1. The client application sends a request to authorization server requesting the profile information of the user.
2. The authorization server redirects to the end user asking him to allow the client application to access his profile information, the user has to login if he has not already logged in to the authorization server.
3. Once the user gives consent for the client application to access his profile info, the authorization server will send an authorization code/token to the client application.
4. The client application may store the same and calls the authorization server with the authorization code to get an access token.
5. The client application uses this access token for communicating with the resource server and gets the profile info.
6. The client application trusts the authorization server and since authorization server validated the user, the user is considered valid by the client application
6. The user profile info is then set in the security context of the client app and will proceed.
No comments:
Post a Comment