Microservice Authentication strategy

Question

I'm having a hard time choosing a decent/secure authentication strategy for a microservice architecture. The only SO post I found on the topic is this one: Single Sign-On in Microservice Architecture

My idea here is to have in each service (eg. authentication, messaging, notification, profile etc.) a unique reference to each user (quite logically then his user_id) and the possibility to get the current user's id if logged in.

From my researches, I see there are two possible strategies:

1. Shared architecture

In this strategy, the authentication app is one service among other. But each service must be able to make the conversion session_id => user_id so it must be dead simple. That's why I thought of Redis, that would store the key:value session_id:user_id.

2. Firewall architecture

In this strategy, session storage doesn't really matter, as it is only handled by the authenticating app. Then the user_id can be forwarded to other services. I thought of Rails + Devise (+ Redis or mem-cached, or cookie storage, etc.) but there are tons of possibilities. The only thing that matter is that Service X will never need to authenticate the user.

---

How do those two solutions compare in terms of:

• security
• robustness
• scalability
• ease of use

Or maybe you would suggest another solution I haven't mentioned in here?

I like the solution #1 better but haven't found much default implementation that would secure me in the fact that I'm going in the right direction.

Solution 1

Based on what I understand, a good way to resolve it is by using the OAuth 2 protocol (you can find a little more information about it on http://oauth.net/2/)

When your user logs into your application they will get a token and with this token they will be able to send to other services to identify them in the request.

Example of Chained Microservice Design

Resources:

• http://presos.dsyer.com/decks/microservice-security.html
• https://github.com/intridea/oauth2
• https://spring.io/guides/tutorials/spring-security-and-angular-js/

Solution 2

Short answer : Use Oauth2.0 kind token based authentication, which can be used in any type of applications like a webapp or mobile app. The sequence of steps involved for a web application would be then to

1. authenticate against ID provider
2. keep the access token in cookie
3. access the pages in webapp
4. call the services

Diagram below depicts the components which would be needed. Such an architecture separating the web and data apis will give a good scalability, resilience and stability

Solution 3

You can avoid storing session info in the backend by using JWT tokens.

Here's how it could look like using OAuth 2.0 & OpenID Connect. I'm also adding username & password login to the answer as I assume most people add it as a login option too.

Here are the suggested components of the solution:

1. Account-service: a microservice responsible for user creation & authentication. can have endpoints for Google, Facebook and/or regular username & password authentication endpoints - login, register. On register - meaning via register endpoint or first google/fb login, we can store info about the user in the DB. After the user successfully logs in using either of the options, on the server side we create a JWT token with relevant user data, like userID. To avoid tampering, we sign it using a token secret we define(that's a string). This token should be returned as httpOnly cookie alongside the login response. It is recommended that it's https only too for security. This token would be the ID token, with regards to the OpenID connect specification.

2. Client side web application: receives the signed JWT as httpOnly cookie, which means this data is not accessible to javascript code, and is recommended from a security standpoint. When sending subsequent requests to the server or to other microservices, we attach the cookie to the request(in axios it would mean to use withCredentials: true).

3. Microservices that need to authenticate the user by the token: These services verify the signature of the JWT token, and read it using the same secret provided to sign the token. then they can access the data stored on the token, like the userID, and fetch the DB for additional info about the user, or do whichever other logic. Note - this is not intended for use as authorization, but for authentication. for that, we have refresh token & access token, which are out of scope of the question.

I have recently created a detailed guide specifically about this subject, in case it helps someone: https://www.aspecto.io/blog/microservices-authentication-strategies-theory-to-practice/

Comments

[Plamen Petrov]

Would you please priovide more details on what you are trying to achieve? In the first case does authentication happen against Redis, or in the services themselves? Redis is missing in the second diagram, is this intentional?

[Augustin Riedinger]

I have added some information. Please let me know it is still unclear. Thanks!

[Tiarê Balbi]

Have you thinking about the idea to create a microservice which use the OAuth Protocol and your other's service use Token created?

[Augustin Riedinger]

I'm curious about this solution, but I still don't understand how it will work in practice. Do you know where I could find some standard implementations of it?

[Manchanda. P]

@AugustinRiedinger, thanks for putting this up. I am also breaking my monolithic web application into micro services by taking baby steps. In your case, are the Services 1-n stateless or state-full. In case they are state-full, have you thought about managing sessions in each of these services. Thanks

[Augustin Riedinger]

Well if you use a different session storage for each service, either the user has to login in every services, or you need to setup a process that for 1 signup, signs the user up on every other service, which in its most basic form, is to share the session ID, which corresponds to strategy #1. Or did I miss something?

[Little Roys]

This is great, I met the same problem!

[Augustin Riedinger]

Thanks it is pretty clear. I found this very good article decomposing pretty much the same solution: dejanglozic.com/2014/10/07/…

[mfrachet]

Your answer is great, but how does the token generated from the API Gateway (from inside of it, or in a AuthMicroService) can be handle by a random microservice, whose the aim is not to authenticate, and dont probably have oauth management inside of his business code ?

[Tiarê Balbi]

For example you can use Netflix Zuul to send the token received in the gateway to all services and they will know the user information. docs.spring.io/spring-boot/docs/current/reference/htmlsingle‌​/…

[cmp]

Another nice thing about using OAuth2 between services is you can have endpoints which distinguish between service authenticated and user authenticated actions.

[Declan Whelan]

Check out this article for using microservices with oauth.nordicapis.com/…

[João dos Reis]

OAuth is more about granting a system access to a user's data held in another system. This to me looks like a good case for SAML.

[user2679859]

Better than SAML: Use OpenID Connect.

[Taku]

Doesn't AWS Lambda become "cold" and takes time to start up? That would make the login slow, wouldn't it?

[Sandeep Nair]

@tsuz, AWS has now introduced concurrency feature in lambda where you can reserve the concurrency. With this you could fix the cold start problem. docs.aws.amazon.com/lambda/latest/dg/…

[brayancastrop]

I would have loved to have seen this answer years before, it makes incredibly simply to understand how microservices architecture with authentication and authorization independent microservices can be orchestated to give access to other services

[Anil Kumar]

@Sandeep, I think you're referring to Provisioned concurrency and not reserved.