Session Authentication vs Token Authentication

1. In Session-based Authentication the Server does all the heavy lifting server-side. Broadly speaking a client authenticates with its credentials and receives a session_id (which can be stored in a cookie) and attaches this to every subsequent outgoing request. So this could be considered a "token" as it is the equivalent of a set of credentials. There is however nothing fancy about this session_id string. It is just an identifier and the server does everything else. It is stateful. It associates the identifier with a user account (e.g. in memory or in a database). It can restrict or limit this session to certain operations or a certain time period and can invalidate it if there are security concerns. More importantly it can do and change all of this on the fly. Furthermore it can log the user's every move on the website(s). Possible disadvantages are bad scale-ability (especially over more than one server farm) and extensive memory usage.

2. In Token-based Authentication no session is persisted server-side (stateless). The initial steps are the same. Credentials are exchanged against a token which is then attached to every subsequent request (it can also be stored in a cookie). However for the purpose of decreasing memory usage, easy scale-ability and total flexibility (tokens can be exchanged with another client) a string with all the necessary information is issued (the token) which is checked after each request made by the client to the server. There are a number of ways to use/create tokens:

   1. Using a hash mechanism e.g. HMAC-SHA1

      token = user_id|expiry_date|HMAC(user_id|expiry_date, k)
      

      where user_id and expiry_date are sent in plaintext with the resulting hash attached (k is only know to the server).

   2. Encrypting the token symmetrically e.g. with AES

      token = AES(user_id|expiry_date, x)
      

      where x represents the en-/decryption key.

   3. Encrypting it asymmetrically e.g. with RSA

      token = RSA(user_id|expiry_date, private key)
      

Production systems are usually more complex than those two archetypes. Amazon for example uses both mechanisms on its website. Also hybrids can be used to issue tokens as described in 2 and also associate a user session with it for user tracking or possible revocation and still retain the client flexibility of classic tokens. Also OAuth 2.0 uses short-lived and specific bearer-tokens and longer-lived refresh tokens e.g. to get bearer-tokens.

Sources:

• https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
• https://stackoverflow.com/questions/1283594/securing-cookie-based-authentication
• https://web.archive.org/web/20170913233103/https://auth0.com/blog/angularjs-authentication-with-cookies-vs-token/
• Demystifying Web Authentication (Stateless Session Cookies)
• https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication

HTTP is stateless, and in order to have an authenticated state, you need some kind of token used to reference information about the user. This session id is usually in the form of a random token sent as a cookie value. An OAuth Access Token is used to identify a user, and the scope of resources that user has access to. In applications that use OAuth single-sign on, an OAuth Access token typically is exchanged for a session id which can keep track of a wider variety of user state.

From an attacker's perspective, hijacking a session id, or OAuth Access Token, is as a good as a username and password, and sometimes it is even better. Session IDs must have security properties which protect user accounts from compromise.

From the developer's perspective, never reinvent the wheel. Use the session manager provided by your platform, and ensure it is configured to conform to the the OWASP Session Management guidelines.