Microservice Authentication strategy

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: https://stackoverflow.com/questions/25595492/single-sign-on-in-micro-service-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.

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/

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

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/

you can use idenitty server 4 for authentication and authorisation purpose

you must use Firewall Architecture hence you have more control over secutiry , robustness ,scalability and ease of use