Token-Based Authentication: What Is It and How It Works

keyboard lit by screen

In a previous post, Zix | AppRiver discussed how those responsible for the SolarWinds attack had abused tokens and certificates as part of their infection chain. The malicious actors went on to abuse those same types of assets in additional campaigns targeting other entities. This resulted in a confirmed certificate security incident at an email security provider.

Acknowledging these malicious activities, Zix | AppRiver felt it necessary to provide its customers with a series of articles that discuss the affected types of authentication methods and how they work. We’ll begin with token-based authentication.

Token-Based Authentication: An Overview

Token-based authentication addresses some of the limitations of session-based authentication. In the latter, a server creates a session for a user when they log in. It stores the session ID in a cookie, which accompanies all subsequent requests if the user stays logged in. The server then verifies a user’s identity by comparing the cookie to the session data stored in memory.

An illustration of session-based authentication. (Source: Sherry Hsu)
An illustration of session-based authentication. (Source: Sherry Hsu)

The problem here is that session-based authentication suffers from certain drawbacks. First, it requires that the server stores sessions in its memory. There’s also the issue of cookies working across multiple devices of different mediums (such as web and mobile).

That’s where token-based authentication comes in. This form of authentication involves an application providing a signed token to the client upon validating a set of user credentials. The client stores that token and sends it with each request, at which point the server verifies the token and sends along information.

An illustration of token-based authentication using a JSON Web Token (JWT). (Source: Sherry Hsu)
An illustration of token-based authentication using a JSON Web Token (JWT). (Source: Sherry Hsu)

In this sense, token-based authentication differs from session-based authentication in that it’s stateless. It doesn’t involve storing information about a user on a server or in a session. It stores that data in the token on the client side.

Benefits and Challenges of Token-Based Authentication

Token-based authentication comes with many benefits. Chop-Chop notes that tokens work on different websites and mediums, as well, which creates an opportunity for a greater diversity of users—especially those using mobile devices. On top of all that, tokens stand in for a user’s credentials in the process of granting access to data; someone who compromised a token would not automatically gain access to the affected user’s account credentials.

That being said, token-based authentication isn’t without its challenges. Devbridge Group notes that some session tokens are not generated in a secure manner, for example. This makes it possible for an attacker with a large enough sample of session IDs to figure out a pattern and guess the tokens for a larger pool of users. There’s also the issue of attackers leveraging insecure token storages, multiple logins and/or long token validation times to steal authentication secrets.

How to Securely Use Token-Based Authentication

Acknowledging the risks discussed above, here are a few best practices for securely using token-based authentication:

  1. Generate strong tokens. In particular, Devbridge recommends that the tokens feature a large set of possible values, incorporate a degree of pseudorandomness and consist of at least 16 bytes in length.
  2. Give tokens an expiration. It’s important to set conditions for how long a token remains valid, notes Auth0. Obviously, if a user is still active, the token can automatically renew. But there’s also wisdom in allowing a token to expire when the user logs out and terminating the token no matter what after a certain period of time has elapsed.
  3. Disallow multiple logins. As noted by Devbridge, it’s possible to use key attributes to prevent parallel authentications where more than one person is interacting with the same user account simultaneously.
  4. Securely store tokens. Local storage is not the way to go here. DEV Community recommends the use of a cookie policy called SameSite for specifying the conditions under which a cookie can be passed in a cross-domain request. A Strict SameSite policy along with the requirement that people must a browser version that supports this functionality will help to keep session tokens secure.  

Up Next in the Blog Series….

We covered the basics of token-based authentication in this post. Next time, we’ll do the same for a form of certificate-based authentication. Stay tuned.