Stateless and Stateful Authorization Cheat Sheet

DO NOT mix statefulness with state transfer mechanisms.


  • Stateful = save authorization info on server side, this is the traditional way
  • Stateless = save authorization info on client side, along with a signature to ensure integrity


  • Cookie = a special header with special treatment (access, storage, expiration, security, auto-transfer) by browsers
  • Custom Headers = e.g. Authorization, are just headers without any special treatment, client has to manage all aspects of the transfer
  • Other. Other transfer mechanisms may be utilized, e.g. query string was a choice to transfer auth ID for a while but was abandoned for its insecurity


  • “Stateful authorization” means the server stores and maintains user authorization info on server, making authorizations part of the application state
    • This means client only need to keep an “auth ID” and the server can read auth detail from its database
    • This implies that server keeps a pool of active auths (users that are logged in) and will query this info for every request
  • “Stateless authorization” means the server does not store and maintain user auth info, it simply does not know which users are signed in, and rely on the client to produce auth info
    • Client will store complete auth info like who you are (user ID), and possibly permissions, expiration time, etc., this is more than just auth ID, so it is given a new name token
    • Obviously client cannot be trusted, so auth data is stored along with a signature generated from hash(data + secret key), where secret key is only known to server, so the integrity of token data can be verified
    • Note that token mechanism merely ensures integrity, but not confidentiality, client has to implement that
    • This also means for every request client has to submit a complete token, which incurs extra bandwidth


  • “Cookie” is just a header, but with some preloaded operations on browsers
    • Cookie can be set by server and auto-saved by client, and will auto-send for same domain
    • Cookie can be marked as httpOnly thus prevent client JavaScript access
    • Preloaded operations may not be available on platforms other than browsers (e.g. mobile), which may lead to extra efforts
  • “Custom headers” are just custom headers without preloaded operations
    • Client is responsible to receive, store, secure, submit and update the custom header section for each requests, this may help prevent some simple malicious URL embedding


  • There is no magic, auth state has to be stored somewhere, either at server or client
  • You may implement stateful/stateless with either cookie or other custom headers
  • When people talk about those things their default mindset is mostly: stateless = token + custom header, stateful = auth ID + cookie; these are NOT the only possible options
  • They have pros and cons, but even with encrypted tokens you should not store sensitive info

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your 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