Skip to main content

Propagate Security Context via Tokens

Context​

Microservices are used or are being adopted. A token-based authentication and authorization mechanism was introduced.

Problem​

  • The security context is not present in the microservices.
    • The individual microservices cannot differentiate different access privileges for authorization.

Solution​

Encode the security context into the issued token to automatically propagate the security context with every request containing the token.

Tokens are usually an encrypted object containing information about the user. E.g. JWT (Java web token) is widely adopted and allows to specify next to very generic user information like the user id. These claims can be complemented with additional standards or custom fields. For example, the micro profile standard adds information like the user name and the authorization groups the user belongs to. Additional proprietary claims can complement the security context with additional information like the user's address.

Example Token T (usually base64 encoded and signed by private key):

{
  "sub": "12345", // userId
  "name": "John Doe",
  "email": "john@doe.com",
  "roles": ["healthcare-professional"]
}

Additional custom information added to the security context might not be supported by external components, like open source infrastructure components.

Microservices might still need additional information for authorization. We suggest to store this required information within the microservice itself so that no further calls to other microservices are required to authorize the user. This can be implemented by design or data replication mechanisms.

Maturity​

More data required (only 2 sources).

Sources of Evidence​

LN44:

  • Context: Reverse Security Token Service
  • Trend in industry: use JWT for principal propagation
    • no formal description in scientific literature
    • user-to-service authentication via token => every service understands token
      • => allows transporitng user identity and session state through system in decentralyed and secure manner
    • after authentication: token for internal use within microservice network (service resp. for token generation = Reverse STS)
    • limited token lifetime: expiration time in body
      • shorter liftime = higher security
    • info about user and intended audience can be included
    • token passed to microservices involved in processing the request
    • each microservice validates token using the public key
    • => each microservice makes decision based on locally available information (second design principle of distributed systems)
      • loose coupling, highly scalable, no overhead of a centralized solution
    • OAuth 2.0 = standard for delegated authorization; OpenID connect builds on it => can be tailored for inter-service security
    • Caveats:
      • Assumption: clock synchroniyation problem does not exist (e.g. by using NTP)
      • tokens must be sent over secure challens, e.g., TLS - otherwise can be intercepted and reused; short validity time as part of the solution
      • private key of issuing service must remain private - if compromised any user can be impersonated by attacker
  • Context: Experiment on performance of different security mechanisms
    • Benchmark system using REST as communication between microservices
    • 4 setups:
      • baseline without security features,
      • STS and JWT token validation
      • MTLS with CA service
      • Tokens + MTLS
    • results: baseline fastest
      • tokens decrease performance by 7%
      • MTLS decrease performance by 4%
      • MTLS + tokens decrease performace by 11%
      • => acceptable since microservices are slower than monolith anyway

Interview B:

  • Alternative to propagating security context via token:
  • put information into request headers => have context in headers
    • dependent on if reuse is planned or not