We live in an age of clouds and microservices. Clouds and microservices provide many benefits but also come with some challenges. One big challenge with clouds and microservices is securely authenticating users to the system. In this post, I’ll highlight challenges and solution for authentication in clouds and microservices.
Traditional enterprise authentication
This includes a data store like LDAP and secure authentication mechanism like Kerberos/LDAP Authentication. This works well for internal enterprise applications. Since the user data does not leave the premise, this is pretty secure. Some of the advantages include
- Company has full control over the user data and credentials.
- User management is easy and more controlled.
Authentication challenges with cloud-based applications
With the cloud-based model, applications are hosted in different vendor clouds rather than on-premise. This poses a few authentication challenges.
- If user data is stored in the cloud, its accessible to the cloud vendor and may cause privacy issues.
- It’s difficult to manage user data remotely. We won’t know what the vendor is doing.
- When a company uses multiple cloud services, this will have multiple authentication mechanisms and multiple copies of user data.
- Difficult to synchronize login and authentication data between external clouds and internal systems without exposing internal security data.
Authentication challenges with microservices
Microservices are cool. They help in better and quicker development, deployment and maintenance of services. But they too come up with authentication challenges.
- Authentication logic replicated to each service.
- Single responsibility principle violation.
- Data/Credentials access to each service which increases the attack surface.
Requirements of an Authentication system
Before discussing the solution, I would like to highlight the requirements of an authentication system for clouds and microservices. Some key requirements include
- Fault-tolerant system
- Centrally managed
- Should scale independent of the cloud apps and microservices.
- Support strong authentication
- Follow standards for easy integrations
Solution: Token Based Authentication
A token-based architecture has 3 components
- A centralized Authentication Server which validates user login and generates tokens.
- A database that stores user credentials/login information. The authentication server validates user login against this database.
- The end applications(cloud-based application/microservices) validates the token to get the user information.
A token is a unique value generated by Authentication Service in exchange of credentials. It can be unstructured like random string or structured like SAML/JWT.
Advantages of token-based authentication
- Credentials are not transferred over the network
- Resource provider does not deal with credentials
- Tokens have limited time validity making it secure
Now that we saw a token based architecture can solve the authentication problem, let’s see what a good token would look like. Some key features of a good token are
- should be stateless
- easy to validate locally
- lightweight for better performance
- timebound/short-lived for better security
JSON Web Token
Looking at the above characteristics, JWT (JSON Web Token) qualifies to be a good token. I’ll talk about details of JWT in a separate post but would like to throw some light here. A JWT token is a compact and self-contained way for securely transmitting information between parties as a JSON object. This can be signed using a secret (with HMAC algorithm) or a public/private key pair using RSA. A JWT token is a simple string in below format
Each of these three parts as base64 encoded JSON data.
data = base64urlEncode( header ) + “.” + base64urlEncode( payload )
hashedData = hash( data, secret )
signature = base64urlEncode( hashedData )
What I described above is a generic architecture or blueprint for an Authentication system. You can implement this on your own or use some open standards. One such open standard based on the above architecture is OpenID Connect. OpenID Connect is based on OAuth 2.0 family of specifications and uses simple JSON Web Tokens. I’ll discuss more on OpenId Connect in a separate post. The advantage of using a standard is that you can easily integrate with different vendors/services which support the standards. One key point to note is that the above architecture does not specify any particular authentication mechanism at the Authentication server. You are free to choose any authentication mechanism. As a security best practice, one should use multi-factor authentication.