CODEWITHSUNDEEP
phpnode.jsrestauthenticationmicroservices
AndrewMcLagan
AndrewMcLagan

Reputation: 13987

JWT Authentication within a Micro Service architecture

Question

Question how is it possible to create an authentication service within a micro-service application and have other services check against that token (JWT) and retrieve a user?

Possible Solution

My current thinking is based around the auth service inserting { token, user } into Redis once a user is authenticated. All other service can check against the user's Authorization: Bearer kdI8$dj$nD&... header token within Redis.

enter image description here

  1. User sends { username, password } to auth service
  2. Auth service authenticates credentials and retrieves { token, user }
  3. Auth service inserts { token, user } into Redis
  4. User makes request to Service-1 with { token }
  5. Service-1 loooks for { token } in Redis and retrieves { token, user }
  6. Service-1 does its thing and sends back { data }

Are there any possible security, logic or architectural problems with this approach?

Upvotes: 2

Views: 2017

Answers (2)

David Karlsson
David Karlsson

Reputation: 9716

Using this approach you will have to validate the token in all your services, if you are okay with this then you are probably fine.

The access token may have an expire time that will make it necessary to use a refresh token to get a new access token from the auth service:

  • When the access token expires you would return a 401 to the client, from the Service X that you are trying to talk to.
  • The client would have to call the Auth service providing a refresh token, getting a new access token
    • Finaly the client would be hitting the Service X again with this new access token, have it validated and get the expected response from Service X.

In my recent assignment I wrote a micro-service that proxied all the requests validating their tokens, the proxy handled everything from login/auth to roles and sending 401's for expired tokens and revoking refresh tokens etc. I think this gave me a greater separation of concerns than having to deal with tokens in all services. However it ofcourse makes the proxy a possible bottle neck into the system, autoscaling of the auth service is meant to deal with this in my case.

Also I did not user redis but stored a hashed key (consisting of hashed accesstoken properties + salt) in the accesstoken that I could validate by rehashing the other properties of the accesstoken+salt.

Important Note: In the refresh token scenario above my proxy only would experience load for an invalid/expired accesstoken, whilst in your scenario any service could be reached with invalid tokens, I don't know if this is of any concern in your particular case but it is probably worth mentioning...

Another approach would be to let Service-A and Service-B call the auth service to validate the tokens, but this would infer a lot of more traffic between the services since each HTTP request with a token has to be validated. In this scenario as well a invalid token request would reach your Service X and hence infer some load on it...

Upvotes: 1

MvdD
MvdD

Reputation: 23494

It's not really clear why you would want to store tokens in Redis. The security token typically contains information about the user (claims data) already. If you need information about the user that is not stored in the token, you should be able to look that up by a simple database query on the user id claim.

Each service can validate the incoming token by checking its digital signature (only needs the public key of the signing certificate for this), lifetime (when does the token expire), audience (who is the token for) etc. If the caller presents a valid token, the user is authenticated.

Upvotes: 4

Related Questions