Reading Time: 5 minutes
Modern applications are designed and deployed as a collection of loosely coupled domain/business driven services based on Microservices architecture. These services and web applications should be stateless and decoupled so that can be deployed, scaled in the cloud easily. Token based security is heart of Microservices Security and it used to secure Microservices services instead of traditional cookie (form) based security.
What is Cookie based security?
It is stateful, server keep track of sessions and client (browser) holds session identifier in the cookie. Server verifies the credentials and creates a session on the server and then set a cookie with the session identifier in the browser. It is implicit, browser send it automatically with every request to the domain (and due to this CSRF attack is possible). There is a major problem with Cookies, they doesn’t work from domains they’re not valid for so client system can’t access cross domain resources/APIs.
What is Token based security (using JWT)?
It is stateless, server does not keep track of logged-in user’s sessions. Authorization server (STS) issue a token to the client system and client send token in the request header explicitly, server uses it to verify the authenticity and access of the request (and due to this CSRF attack is not possible). Client system can send token to any domain to access the cross domain APIs (if CORS is enabled for the APIs).
Why token based security?
It is stateless, scalable and decoupled, JWT token contains all the information to check its validity and user’s identity and access details. Client system can access cross domain APIs using token, it is not possible with cookie without SSO. Cookie is not supported by every client system like native mobile apps but token based security can be easily implemented for Native mobile apps and Internet of Things.
What is JWT (JSON Web Tokens)?
JWT tokens are JSON encoded data structures contains information about issuer, subject (claims), expiration time, access token, refresh token, id token etc. It is signed for tamper proof and authenticity and it can be encrypted to protect the token information using symmetric or asymmetric approach. JWT is simpler than SAML 1.1/2.0 and supported by all devices and it is more powerful than SWT(Simple Web Token).
What is OAuth2?
OAuth2 is an authorization protocol, it solves a problem that user wants to access the data using client software like browse based web apps, native mobile apps or desktop apps. OAuth2 is just for authorization not for authentication, client software can be authorized to access the resources on-behalf of end user using access token. Below are the OAuth2 players-
OAuth2 actors- There are four main OAuth2 actors-
- Resource Owner (User) – End user who own the resource at the Resource server and uses client system to access it.
- Authorization server – Issue a token to the client system using OAuth2 flows (details are below in the next OAuth2 flow section).
- Client – This system access the resource server’s APIs on behalf of resource owner. There are trusted/untrusted and confidential/public clients.
- Resource server – Expose the resource (APIs) and these are consumed by the client on behalf of user.
OAuth2 flows –
There are four types of OAuth2 flows to get the token from Authorization server by Client system and Resource Owner together.
- Authorization code flow – Used by server rendered classical web application (confidential client like J2EE/ASP .Net web app) to get the token.
- Resource Owner Password Credentials flow – Used by trusted client app to get the token. Client app get the user’s credentials directly instead of Authorization server and send it to Authorization server for authentication.
- Client Credentials flow – This is for client to server communication. Resource Owner does not involve and client app uses client app credentials to get the token.
OpenID Connect –
OpenID Connect builds on top of OAuth2 and add authentication. OpenID Connect add some constraint to OAuth2 like UserInfo Endpoint, ID Token, discovery and dynamic registration of OpenID Connect providers and session management. JWT is the mandatory format for the token.
OpenID Connect flows –
It support Authorization code flow for server based application and Implicit flow for client based application.
- Start with standard OAuth2 message to access the user profile and it must start with openid scope to access the user profile details.
- Redirect to IDP, if user is not authenticated.
- Authorization code is returned by authorization end point after IDP round-trip.
- Client system uses the authorization code to get the token from token end point. This token has access token, refresh token (standard OAuth2 tokens) and ID token. ID token is added by OpenID Connect protocol and client system uses it to validate the token issuer, Subject, Audience and Expiration.
- Client system can get user profile data using access token from UserInfo Endpoint.
API Gateway: Microservices Security–
API Gateway acts as a single entry point for all types of clients apps like public java script client app, traditional web app, native mobile app and third party client apps in the Microservice architecture. The API Gateway authenticates the user using cookie or token and passes the JWT token to the MicroServices. MicroServices uses this JWT token to identifies the user and validate the access (request authorization using access token). A MicroServices can also include this JWT token in requests header it makes to other services.
This is just high level overview of token based security concept and I have tried to cover the all points. There are many framework like Spring.Security.OAuth2 for Java and Microsoft.Owin.Security.OpenIdConnect for .Net available for OpenID Connect implementation.
If you are going to implement it using JAVA language, click here to get the sample application from GitHub. I created this application using Spring boot, Spring Cloud Oauth2 and Spring Security.