Page tree
Skip to end of metadata
Go to start of metadata

Discussion around what a stateless architecture is and what problems it solves and challenges it brings

  • Description of stateful architecture
    • traditional cookie/session management technique - authentication results in server side object
    • client receives an opaque reference/pointer to the server side object
    • client presents reference during subsequent service access requests
    • service needs to verify cookie by integrating with AM server side via agents/REST
    • AM looks up cookie from CTS (Core Token Service)
    • CTS is replicated directory - available to all AM instances in cluster

  • Description of stateless architecture
    • post authentication results in session that is presented to the client side
    • this session object is actual value not a pointer/reference
    • JWT (JSON Web Token) is approach used
    • JWT is base64 encoded . (dot) delimited string - which is signed by token issuer to prevent tampering


  • Benefits of stateless
    • reduces reliance on server side storage and replication of server side token material - can therefore increase scale of authentications/sessions
    • resources being protected, can verify/introspect stateless tokens locally
      • they can receive the public key of the token issuer, by calling a public endpoint (JWK_URI) that contains the public key
      • resources can use this public key to verify the JWT has not been tampered
      • resources should check fields such as exp (expiration time), nbf (not before time), scopes, iss (issuer) and aud (audience) fields


  • Challenges of stateless
    • stateless uses JWT's - JWT's have fundamental issue, of how they can be revoked before their natural expiration
    • revocation may be needed due to logout
    • AM provides mechanism to track logged out tokens - it uses a server side blacklist
    • the blacklist is stored in the CTS and is replicated and made available to all AM instances in the clustered
    • whilst this is server side state, the blacklist is much smaller than an equivalent white list seen in stateful architectures
    • checking for a blacklist entry is really a combination of several requirements
      • network hops involved - do you want to check every token on every request?
      • how long lived are the tokens - making the life span small, reduces potential threat window
      • one concept is to not check every token every request against the blacklist, but a % based on algorithm
      • checking algorithm could be something like 0.5 x time to  exp. Eg token has exp of 2 hours.  At 1 hour before exp, make call to AM to verify token against blacklist.

  • Some useful links that were discussed


 

  • No labels