Skip to main content

Token-based Authentication

Context​

Microservices are used or are being adopted. The decision was made to use a centralized SSO component. The authentication mechanism attaches the login credentials to every request to authenticate against the system.

Problem​

  • The authentication system is vulnerable against replay attacks since the login credentials are not invalidatable.

Solution​

Use token-based authentication and authorization. Token-based authentication reaches from simple JWT token generation to established protocols like OAuth2 and OpenID Connect.

The central SSO component has a cryptographic key-pair with a public and a private part. It issues a token once to the authenticating user after signing in with the private key. The client application includes this token into requests to microservices. Each microservice can validate the authenticity of the user token by public key of the token issuer. The token is viable for a configured time span. The smaller the token lifetime, the more secure against replay attacks is the mechanism. In order to continue using the APIs, the user either has to sign-in again or use a token refresh mechanism.

There are various ways on how the public key to validate the authenticity of a token finds its way to the other microservices. You could offer an API that provides the public key, use a configuration service, secrets of the underlying platform, environment variables, ecetera.

Since every microservice can authenticate a user via this token there is no need to locate the authentication logic in the API facade. However, the facade can take over validating the token once and

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L5:

  • security as major challenge with microservices
  • for some systems: vital to identify user in all the chains of a service communication happening between microservices
  • OAuth and OAuth2 well-known solutions

L34:

  • Example for microservices vs SOA vs SCS
    • original user management component partially dissolves into the SSO module for authentication
  • literature considers security protocols in respect to service interactions and trust, authentication or global identity management
    • keywords:
    • authentication, authorization, access control
    • OAuth(2)
    • encryption
    • OpenID
  • Open challenges: security across services must correlate when one service allows half of the process and the second denies it

L44:

  • Context: structure of a IoT Microservice
  • user auth: token-based authentication
    • users or services provide credentials to obtain token
    • token grants access for specific resource for specified time period

L55:

  • Context: microservice-based middleware for digital factory
  • User Account and Authentication (UAA) service
    • authentication and authorization
    • check user credentials (human operator, CPSs or microservices) => verify identity
    • issues time-limited Oauth2 token
    • token authorizes subset of possible actions depending on their role

LN44:

  • after authentication by gateway => microservices should know about user auth state
    • e.g., if authenticated, which role in authorization context
  • need to identify user in every service down the operation chains
  • Seucirty tokens: token-based auth = common security mechanism
    • relies on cryptographic objects called security tokens containing authentication and authorization information
    • created on successful validation of client credentials on server specified
    • given to client for subsequent use
    • substitute client's credentials within limited time framework
    • example: token-based auth via HTTP cookies
  • Advancement of token-based auth: OpenID Connect = security standard for SSO
    • same functionlality by Security Token Service (STS)
      • part of WS-Trust standard
      • methods for issuing, renewing, and validating security tokens
    • JSON security standards
      • JSON Web Signature (JWS), Encryption (JWE), and Token (JTW)
  • Token-based authorization
    • Role-based Access Control (RBAC)
      • user-centric; not accounting for relationship between requesting entity and the resource
    • Attribut-based Access Control (ABAC)
      • better for fine-grained authorization on resources, e.g., to access specific API called
    • tokens can include authorization information
      • e.g., RBAC roles can be additional attribute in JWT tokens
  • 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
  • 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

LM47:

  • Context: SLR with tactics to achieve quality attributes
  • Federated identity extends host-authenticated TLS
    • in-band authentication options
    • allows to use identity management system to store identity of users for auth
    • usually adopt trusted third party
      • issues tokens, eg JWT
      • implemented as separate service or SSO framework
      • examples: OpenID Connect, SAML, OAuth2, Shibboleth

Interview B:

  • BEST PRACTICE: use tokens
    • secure every service by itself, but with tokens
    • issued by an authentication provider => JWT token
    • token includes information
      • am I allowed to get in? yes or no
      • who am I? => user information: claims
    • claims can be used to propagate information about user
      • instead of specifying in API every time which user, email, address,....
      • is a BEST PRACTICE to use claims!
    • token has shorter life time than session
      • refresh token to generate token in background
      • transparent for user
      • security starts at UI => handling of refresh token
  • Two problems:
    • securing the API
    • getting security context
    • Monolith: sign-in => session contains information
      • every code can access this information
    • Distributed world
      • either sign-in everywhere
      • or each service needs to ask at auth provider about user
        • overhead!
      • solution: information into token
        • encrypted or not
        • certified => use public key to see if token was manipulated

Interview C:

  • need to think first where to do security
    • facade?
    • particular services?
    • central token service issuing tokens valid for a time span?
      • used to access backend services

Interview E:

  • Most often sees OAuth2 and Open ID Connect for implementation => defacto standard for token-based auth in the web
  • In frontend shell: get security token, distribute over classical communication channels to micro frontends
    • e.g., over message bus, session storage, or local storage