Microservices Architecture(MSA) : Security, Authentication & Authorization

Problem : How to handle security with authentication & authorization in MSA?

MSA requires uniform security to ensure microservices can communicate and collaborate with-in and outside the system. Each microservice needs info about who triggered the call for system usage. Authentication & Authorization are two core components of the security apparatus both are independent of each other.

Authentication : Identity of the user

Authorization : Decision on user is allowed to access & execute actions

  • Individual microservices should not perform authentication(central server approach can be adopted)
  • Authorization enables the interplay between microservices hence it would require the user groups, roles etc to created & administered collectively
  • OAuth2 is a widely supported protocol( Google, Microsoft, Twitter, XING, Yahoo etc)

OAuth2 solves the authentication & authorization primarily for human users for enabling it for microservices based system would need additional steps like:

  • Microservice to microservice communication protected by SSL/TLS against wiretapping (by encription) – REST supports such protocols
  • Certificates can be used to authenticate clients(non-humans)
    • Certificate Authority (CA) creates certificates & can be leveraged to verify digital signatures (SSL & TLS support certificates)
  • API keys (similar to certificates, keys are shared with external clients to allow them access to the system) – OAuth2 supports this through Client Credential
  • Firewalls : Use for controlling the microservice to microservice communication, helps in intrusion scenarios to enforce restrictions
  • Intrusion detection mechanisms (part of the monitoring system setup)
  • Datensparsamkeit : Concept enforces the restriction on data collection fields (collect the data which is absolutely required rest all are not store in the system)
  • Hashicorp Vault : Tool
    • Secret password
    • API keys
    • Keys for encryptions or certificates
    • Integrates with Hardware Security Modules (HSM’s),SQL databases, AWS IAM, can generate keys for AWS cloud by itself

Additional security scenarios for consideration:

Each micoservice has to ensure the below things in its design & implementation:

  • Integrity : Data integrity is the responsibility of every microservice it can be achieved by signing the data
  • Confidentiality : Ensures data modifications are not denied (again by using the user keys)
  • Data Security :
    • No data loss
    • Backup & disaster recovery solutions
    • Highly available storage solutions
  • Availability : Resilience approach should address the failure scenarios to ensure high availability

Most of the times above scenarios are ignored or missed out while designing security approach for the systems.

Questions to probe further during design discussions:

  • Session management implementation
  • What is the microservices communication & service discovery model?
  • User experience can change or should remain same?
  • Are you breaking the monolith to SPA(Single Page Applications)?
  • Do you have mobile clients?
  • How is identity and permission info conveyed to a service?
  • How is info decoded and interpreted?
  • What data would be required to make access decisions(ACL’s, roles, user accounts etc)
  • How is data managed?
  • Who is responsible for storing and retrieving it?
  • How to verify the tampering case?
  • Who all will interact with the services?
    • Users, Devices, Services, Applications, External Services,

Approaches available:

Evaluate all the approaches to see the proper fitment, multiple factors are at play, traditionally authentication in monnolith(heavyweight architecture) world has been always sateful service but MSA is lightweight distributed architecture but works mostly on stateless services, below are the approaches to work with stateful microservices:

  • Old world options available are….
    • Basic HTTP authentication (has drawbacks )
      • $ curl “https: //$username:$password@host/resource
    • Certificate based security : Supported in Sprint Security (X.509) – (has drawbacks )
    • Network security – (has drawbacks )
    • Custom Authentication Token
  • In MSA’s mostly deal with stateless stuff, we need to focus on what is stateful and stateless & how do we achieve statelessness?
    • Authorization servers are often stateful (they store issued access token in db for future checks)
    • By issuing JWT tokens as access tokens will help us to get statelessness to the interactions
      • JSON (JWT) is a secure way to encapsulate arbitrary data that can be sent over unsecure URL’s
  • Leverage JWT (JSON Web Tokens)
    • URL-safe
    • Exchanged between two parties
    • Claims are encoded as JSON object which is digitally signed by using secret between two parties
  • Use some Redis/Memcached db for user sessions in all the frontend microservices(this will ensure user authenticated once will have continuity for the following sessions)
  • Tokens (Expiry & Non-Expiry) : For expiry always pair with refresh tokens
  • API firewalls/reverse proxies are used for token translations
  • OAuth 2.0 is an open source delegation protocol allow secure authorization in simple & standard from desktop, web, mobile applications
    • In MSA context:
      • Authentication can be a microservice itself
      • Authorization is a common functionality across MS’s
    • Implicit grant (Frontend application)
      • For web applications running on the browsers with AngularJS or mobile apps
      • Gets access tokens directly
      • Similar to code grant but client gets access token directly
    • Client credentials grant :
      • Service-to-Service
      • Application authenticates itself using clientid and client secret
    • Password credentials grant:
      • Client collects username & password to get an access token directly
      • Only viable for trusted clients
    • Authorization code grant:
      • Server based application
      • Redirect flow for web server apps( to authorization server for code)
  • Frontend applications
    • Use implicit grant
    • Use HTML 5 localstorage for access and refresh tokens


Solution Frameworks:

  • Netflix Zuul
  • OAuth : It is not for authentication & authorization but for scalable delegation protocol where actors involved are (map the numbers beside approach to the figure shown above ):
    • Resource Owner(RO)
    • Authorization Server(AS) – (2) (5)
    • Resource Server(RS) – (4)
    • Client – (1)(3)(6)
    • Access tokens are JWT (JSON tokens help in achieving the statelessness)
      • By Value(Inside the network)
      • By Reference(Outside the network)
  • OpenID Connect
    • Resource Owner(RO)
    • Authoriztaion Server(AS) – (2)
    • Resource Server(RS) –  (5)
    • Client – (1)(3)
    • MyMail.com – (4)(6)
    • Sessions – (5)
  • JSON Web Tokens
  • Sprint Security REST plugin
    • Spring Security core support – has inbuilt support for Oauth2 standard  that can be extended or customized for our implementation needs
    • Login & Logout REST endpoints
    • Token validation filter
    • Memcahed token storage
    • Partial implicit grant support for 3rd party providers
    • Oauth 2 support
  • SAML assertions (similar features to OAuth2)
    • XML focused
    • Standard based like OAuth
    • Supported by Spring Security
    • Standardized request signing
    • Enterprise usage
    • Drawbacks
      • Cumbersome setup for servers & clients
      • Headers will have large amount of XML data
      • Complexity for developers
  • Datensparsamkeit : Approach
  • Hashicorp Vault : Tool

(Image Source : OAuth.net )


Solution Design:

There is no one size fit all the solution for this scenario, we have to adjust our solution according to the context & need of technical setup on the ground

  • Core problems in MSA :
    • Identifying user
    • Creating sessions
  • Leave authentication to Oauth or OpenID server
  • Make all MS’s accept JWT’s (with translate using reverse proxy for by reference to by value translations)
  • Ensure that….
    • Everything is self-contained
    • Standards based
    • Non-reputable(don’t trust anything)
    • Scalable
  • JSON (JWT) can be used for…
    • Single Sign-On
    • Secure payload transportation (obscure url parameters or POST body elements)
  • JWT for achieving statelessness
    • Instead of storing access token in a stateful way, do it with JWT
    • On the client browser securely store the JWT-encoded access tokens ( this is helps us to achieve one of the basic rule of REST i.e. state transfer
    • JWT claims can be signed
    • JWT can leverage JWE (JSON Web Encryption)


Lightweight distributed architecture based services demand lightweight infrastructure, security is very important but should be unobtrusive, spring security makes it easier for the developers to understand the low level needs of security communication & implementation. Oauth 2.0 being a standard helps to have common streamlined approach to solution implementation.

  • Spring Security Oauth
  • Spring Security SAML Assertions
  • Sprint Session
  • Oauth2 seems to be evolving as the alternative it is
    • Extremely simple for client (lightweight)
    • Access token have information other than identity only
    • Resources are free to interpret token content
    • Standards based hence changes be decoupled for uniform implementation
    • Supports bearer tokens
      • Centralizes account mgmt. & permissions
    • Supports Authorization Server, Resource Server & Client Application
      • Examples
        • Facebook – Graph API
        • Google – Google API
        • Cloud Foundry – Cloud Controller



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 )

Google+ photo

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

Twitter picture

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

Facebook photo

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


Connecting to %s