Sessions versus tokens

A how-to guide to implementing user state

A photo of today's speaker

Robert Kawecki

Sessions vs tokens

2022-06-08

twitter.com/rkaw92

Quick background

  1. Node.js user of 9+ years

P.S. We're hiring!

Problem introduction

  1. You've created some basic routes...

Need to keep the user logged in.

But also to turn features on/off for given types of users.

Authentication vs authorization

In the context of users:

Authentication
Proving who you are
Authorization
Controlling access to resources
Basic flow of authentication and authorization
Flow of authentication and authorization in a typical app

Secret, option A: Sessions

Session ID - an opaque reference to server-side state

            
                1c0dd6ca-039e-402b-8b17-5c95f2205ad3

Needs resolving to a set of user capabilities.

Secret, option B: JSON Web Tokens

Example composition of a JSON Web Token
Bearer token with claims about the user's capabilities

JWT already contains user info

            
                {
                    "sub": "alex@ads.example.com",
                    "role": "advertiser",
                    "iat": 1654627044,
                    "exp": 1654628844
                  }
Authorization differences between sessions and JWT
Authorization differences between sessions and JWT

The DB request: both sides of the coin

  1. Run-time cost
  2. Opportunity to discover invalidation

Sessions: pros and cons

+ -
Instant invalidation Latency
Listability Coupling to central DB
Auxiliary data Race conditions

"Fixing" sessions

  1. Limit scope of middleware

    2. Most Web frameworks let you apply middlewares:
    per route (Express)
    or per module (Fastify).

  2. Use a fast, sharded DB
  3. Stop storing app state in sessions (store references)

JSON Web Token: pros and cons

+ -
No infrastructure Cannot force expiration
Obvious to scale Hard to keep transient data
One issuer, multiple audience Transparent payload

"Fixing" JWT

  1. Use access + refresh token pairs
    Refresh token
    A token that allows generating a new access token
  2. Discuss expiry times with incident response team
  3. Use local storage for cart references etc.
  4. Is this better than sessions?

A hybrid?

  1. Access + refresh tokens
  2. 1 refresh token = 1 session
  3. Access checking at edge, refresh via central DB

Abstracting for flexibility

  1. In-memory model of capabilities
  2. Business logic independence from session/token mechanism
            
                interface CurrentUser {
                    isAdmin(): boolean;
                    isAdvertiser(): boolean;
                }

To sum up...

Rules of thumb

  1. Sessions are fine for most user-facing apps

Third-party solutions

  1. Keycloak (OSS)
  2. auth0 (commercial)
  3. Supertokens (OSS/commercial)

Closing remarks

  1. You're responsible for authorization even if you don't manage authentication
  2. Pick the right tool for the job
  3. Talk to security / incident response people

Links

  1. Evert Pot - JWT is a bad default
  2. express-session - basic session middleware
  3. jwt.io - token debugger
  4. Keycloak - open-source federated login
  5. auth0
  6. Supertokens

Questions

See you next month at WarsawJS