How to start your journey into Microservices Part -3 – Authentication Strategies

In the last blog we learned that we could use DDD to breakup the system into diff. microservices.

In this blog we will understand where and how we can implement authentication in Microservices.

How to implement:

Let’s understand what all mechanisms are there to implement authentication and authorizations:

  • Session Token <A long unidentifiable string> Based
    • HTTP Session – Cookie
      • not meant for microservices enviornment as generally there will be multiple nodes and tying a request to one particular node is not good
    • Redis or Any Other Caching tool
      • store the session token in a cache after the login is done
      • any request which needs to be checked verify the token from the cache
  • JWT Tokens as Session Token<JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.>
    • No external caching required
    • Can be done at Service level only without any external call
    • Challenges on keeping the signing secret constantly changing

In this both the approach has its pros and cons but i generally prefer Session Token and Cache based authentication for user based API and can use JWT for Service to Service communications , now a days JWT tokens are also used extensively.

  • JWT challenges on being used in browser side
    • No easy way to un-autheticate the JWT token as it is self verified <one way is time bound in that case token lives for ~5 min even after user logout> vs you can simply remove the token from
      • You can sort of simulate invalidation of a JWT, for a particular verifying party, by storing the JWT ID (jti claim) or equivalent, into a “revoked” list. For example, in a cache stored in API Gateway. Use a TTL that is longer than the JWT Expiry. (This will not work well if the JWT does not have an expiry!)
    • Other challenge is to manage the private keys very securely and constantly change it.

When to implement:

Let’s understand the categories when we need authentication and authorization

  • External API calls – api calls done from outside the system deployment either from UI or from third party.
  • Internal API calls – api calls done internally from one service to another either in respect of a external API calls or internal timer jobs.
    • Sometimes people do tend to overlook this area and make the internal API calls free from any authentication. Not the right approach
    • To implement this we need ways to transparently paas<Try to do it at the Framework Level rather than every dev take care of this> authentication tokens from one service to another.
    • With this is in place now every service becomes the owner for their data.

Where to Implement:

  • API Gateway Level
    • In this we use a API gateway which does all the authentication either via Session Token or JWT or other mechanisms
    • Any request coming at the gateway <l7 gateway eg: nginx,traefik> will checked for authentication and then only the request goes to the service
    • Do not have to implement form scratch <even though almost every framework provides it out of the box>
    • Service dosen’t seem to worry about authentication. <still when we talk about service to service communication for internal API call Service has to pass through the token>
    • For any communication between services a gateway between services will also be required.
  • Service Level
    • At service level there are various frameworks <Spring Security , Passport JS for Node > which provides authentication and authorization part so that one dosen’t have to code them from scratch .
    • Service <or Framework on which service is written> need to understand the token so that it can pass it through for Internal API calls.

It is very highly depends on the way you are integrating things that at which level you implement.

Horizontal Aspects

  • Auditing
    • very important – must be considered from very starting.
    • Many frameworks provide support for this eg: Spring Boot
  • External IDP – Identity Providers
    • If your are starting from scratch and want integrations with many third party like google , facebook and many others for single sign on external IDP is a very good choice.
    • Auth0 , AWS Cognito , Okta are some of the external IDP
    • Many things like password expiration policies , two factor authentication all available out of the box.

By now you must have got some gist about authentication in microservices world. For any doubts do put that into comments section.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s