Serverless Microservices Auth Problem
Serverless Microservices is a unique architecture paradigm where Microservices leverages Serverless Compute Services which is also known as Function as a Service (FaaS), Serverless Storage Services, Serverless Identity and Access Management (IAM) & etc. to provide solutions.
If you are building a full stack Serverless solution (Or at least majority is Serverless), one of the common questions comes up is;
How are we going to design the authentication and authorization for the fleet of Microservices?
Let’s look at in detail what are the practical approaches to solving this problem.
Authentication
During the past few years, this space is mostly standardized around OAuth protocol (Which was originally designed for authorization). Now you can use OpenIDConnect protocol for authentication (Which uses OAuth2 underneath) directly for authentication which uses JSON Web Tokens (JWT) to transfer the tokens.
So how can we use OpenID Connect with Serverless and Microservices?
You can find Serverless Identity Providers which out of the box support this. For example, if we consider AWS Cognito UserPool, Azure B2C, Auth0, they are quite capable of providing identity as a service which can handle the authentication.
These identity providers will issue self-signed tokens (Refresh, Access, IDToken & etc.) where we could validate it in individual Microservices or at the Gateway (If you decides to use one).
Since this step is more standardized, the approach is straightforward and you might need to do research in finding the right Serverless Identity Provider which facilitates the required features (e.g; Multi-Factor Support, Customizing Domain Name, Customizing Sign In/ Sign Up UI, Cloud Native Support, Single Sign-On Support).
Authorization
This is the quite tricky question to Answer since there are various approaches used by different implementations. Let’s look at a few common approaches used elsewhere.
For simplicity, I will be using IDP Token referring to the tokens issued by the IDP relevant for the use case.
1. Using OAuth Scopes and Claims
When the IDP issues the IDP Token, the IDP could query an external system (Or itself if authorization information is available within) to retrieve the permission granted for the particular user (Note: If you have different scopes, the user might need to grant access at first) and embed those information inside the Signed IDP Token.
Pros
This way when authorizing the tokens and providing access control for any bearer of the IDP token by simply verifying the Token signature. The good side of this is, it doesn’t require to query an external system or a database to retrieve User’s access permission since its self-contained within the IDP Token.
Cons
The downside of this approach is, if the permission of the user is changed, the bearer needs to either get a new token or wait till a new token is issued (After re-login or refresh). Also if the token requires to carry a large number of claims, this might have a limiting factor (At most 8KB in length).
2. Microservice/Gateway Query Permissions
This is another approach, where the IDP Token is used to get the user identity information and query the user permission from a database.
Pros
Suits applications where the permissions changes often. This also allows to restrict/ block the user at authorization level immediately (Even still the IDP Token is valid) restricting access to an authorization level. IDP Token JWT size becomes finite.
Cons
For each request, the permission data needs to be queried (Unless there is a cache which keeps permissions against IDP Token and still needs to query the cache). This is not optimum when doing the authorization since it can also impact performance and have scaling limitations.
Conclusion
In addition to the OpenID Connect for Authentication, new standards like User-Managed Access (UMA), is also there which works with an OAuth-based access management protocol standard.
Therefore, selecting the best Authentication and Authorization solution will be unique depending on the specific solution, depending on the overall governance and compliance objectives.
✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.
