What is token-based authentication?

Put simply, a token is a piece of data that carries just enough information to authorize a user’s access to a specific service or system. There are many different types of tokens, but the three main types involved in token-based authentication are security tokens, access tokens, and refresh tokens.

Security tokens

The security token does most of the heavy lifting in token-based authentication solutions. A security token is a dedicated physical device or software used to authenticate the user together with (or in place of) their credentials.

When you try to log in to a protected system, the server asks you to verify your identity with a security token in your possession — for example, completing one-time authentication on your phone’s authenticator app or flashing a smart card across the scanner. This way, security tokens prevent others from easily breaking into your account with stolen credentials.

Access tokens

An access token is a unique, self-contained piece of data that lets you access an app, service, or website without having to repeatedly prove your identity. Access tokens are issued by authentication servers directly to your device after identity verification. As long as you have a valid token, you can access the service without having to go through authentication again.

Think of access tokens like old-school train tickets. To stamp a ticket, the conductor needs to be sure everything is in order, such as the passenger’s identity and seat number. But once that’s done, you don’t need to go through the song and dance routine at every station — the stamp is proof enough that you have the right to be there.

Refresh tokens

A refresh token has one simple function — to obtain additional access tokens for the user once they expire, essentially refreshing their duration. When an authentication server confirms the user’s identity and issues a valid access token, it will also issue a refresh token to the user’s device.

Why are refresh tokens necessary? To prevent hackers from abusing intercepted tokens, most access tokens have a very limited lifetime (typically between 900 to 3,600 seconds). But this also means that legitimate users have to periodically re-identify themselves to continue using the system. Secure refresh tokens allow system administrators to use short-term access tokens without compromising user experience.

Cybersecurity experts have noted that over time, passwords tend to follow a negative feedback loop. Strong passwords are hard to remember, so users write them down; written passwords are easy to steal, so users make them easy to remember; and in the end, the resulting simple passwords do not offer much security at all.

Token-based authentication was originally developed to address this problem. Security tokens can combine with passwords to form two-factor authentication (2FA) or even multi-factor authentication (MFA) solutions, letting users enjoy relative safety even with weak login credentials.

Better yet, token-based authentication can complement other authentication methods (like biometrics or push notifications) to do away with passwords entirely.

The first development in token-based authentication was the release of the Security Assertion Markup Language (SAML) by the Organization for the Advancement of Structured Information Standards (OASIS) in 2002. SAML was an open standard for exchanging authentication and authorization information, forming the foundation for subsequent authentication protocols.

Following SAML, the next major token-based authentication development was the release of OAuth in 2007. OAuth was originally a token authentication method for Twitter, but it has since been adopted by other major tech companies like Google, Facebook, Microsoft, and Amazon. OAuth can be used to grant one service access to the user’s information on another service without revealing the user’s password.

2010 saw the release of the JSON Web Token (also known as JWT). JWTs were extremely compact, making it easy to transmit them between parties. JWT rose in popularity with the proliferation of smartphones and the development of high-speed internet infrastructure, becoming the authentication token of choice for mobile and web applications.

Among the latest token-based authentication developments was the OpenID Connect (OIDC) protocol, built on the back of the OAuth 2.0 framework in 2014. Like OAuth, OIDC allows people to use login credentials registered with an OpenID provider for multiple sites, supplying the latter with the necessary information and context.

Broadly speaking, token-based authentication methods fall into one of three categories.

Connected

The oldest type of authentication token, connected tokens require a physical connection to the system to function. Connected tokens were widely used before the proliferation of wireless technology and cloud computing services. These tokens are usually housed in dedicated physical devices like key fobs, USB sticks, or external hard drives.

Contactless

Unlike connected tokens, which need physical contact with the system to function, contactless tokens can give users access as long as they are in physical proximity. These tokens use radio frequency identification (RFID) or near field communication (NFC) technology for authentication. Contactless tokens like wireless keyrings or NFC authenticators are a popular way for organizations to manage access to company premises.

Disconnected

Just like their name implies, disconnected tokens require no physical link to whatever you’re trying to access — it doesn’t matter if you’re in the same room as the server or on the other side of the world. Disconnected tokens also don’t require a dedicated physical device to work, often making use of free authentication tools on mobile phones or laptops. As a result, disconnected tokens are the most popular form of token-based authentication today.

Based on the above token-based authentication methods, we can classify all security tokens into two main types:

• Hardware tokens are special devices that act as dedicated authenticators. These devices act as connected tokens, such as special USB sticks and access cards, or contactless tokens like wireless keyrings. Before the smartphone revolution, hardware tokens were the only realistic option for token-based authentication due to software limitations of mobile devices. Today, hardware tokens offer certain advantages over software tokens (such as being harder to hack or duplicate), but they also introduce significant risks (for example, they can be stolen or destroyed).
• Software tokens are not tied to a dedicated authenticator — instead, they take the form of specialized software that can be installed on nearly any smartphone or laptop. Nearly all software tokens are disconnected, although some apps act as contactless tokens instead, working through your phone’s Bluetooth or NFC. The most well-known examples of software tokens are the authenticator apps used in two-factor and multi-factor authentication.

We have already mentioned JSON Web Tokens when discussing the history of token-based authentication. JWTs are the most common type of disconnected software tokens in use today. Their inner workings are based on the RFC 7519 open standard, which specifies using JavaScript Object Notation (JSON) objects to safely send tokens between parties.

JWTs are composed of three parts. The header specifies what encryption algorithm the token uses. The payload includes all the credentials necessary for the token-based authentication process, as well as additional information about the user or the account. Finally, the signature carries the cryptographic key that lets the server verify the authenticity of the signed token.

The wide adoption of JWTs can be attributed to their small size, which allows them to be sent as URLs, POST parameters, or HTTP headers. In addition, the fact that JSON Web Tokens are tied to a thorough authentication process makes them ideal for single sign-on (SSO) systems used in corporate offices.

The operation of token-based authentication systems can be broken down into four broad stages.

1. Request. The user wants to make use of some specific resource (for example, a cloud storage account, a social media profile, or an email service) and asks the server for access. If the resource is protected (non-public), the server asks the user to verify their identity by logging in.
2. Verification. The server determines if the user should gain access to the protected resource by checking their submitted credentials. This may be as simple as checking if the username and password match the records in the server’s database, but more steps may be added to the process by either the server administrator or the users themselves. For example, in MFA setups the server may need confirmation from a hardware or software token in the user’s possession.
3. Token submission. After the server verifies the user’s identity, it creates an access token associated with the user, the credential information supplied at the request stage, and the user’s device.
4. Storage. The server sends the generated access token to the user’s device for storage. Access tokens are only valid for a certain length of time — once the token expires, a new access token or refresh token will need to be obtained from the server.

The main benefit of token-based authentication is enhanced security. Authentication tokens such as physical USB keys or authenticator apps on your phone can supplement traditional authentication methods, which are highly vulnerable on their own. But organizations may also want to implement token-based authentication for other reasons, such as:

• Granularity: Token-based authentication and authorization solutions are highly flexible — for example, access tokens can be set to only allow the user to read certain portions of a protected document, whereas passwords usually are an “all or nothing” affair. In addition, token-based authentication solutions can be easily deployed across multiple apps, websites, and servers with complete control over their settings (such as token expiration).
• Efficiency: Access tokens greatly improve the user experience by eliminating the need to verify the user’s identity every time they want to access some resource. Until the access token expires, the user is able to freely work, browse, or play on the server without having to log in again.
• Statelessness: Tokens are stateless — they don’t carry user credentials or any sensitive information. Once the client’s identity has been verified and an access token has been issued, the server is able to use that token to generate other tokens as needed without further input from the client’s end.
• Automatic expiration: An access token remains valid for a limited amount of time — it will be automatically destroyed once its expiration date passes or when the user logs out. Automatic expiration reduces the risk of a cyberattack: hackers can’t just root through your cache to dig out old tokens, and any tokens they intercept have strict time limits.