In the past, authentication in most applications and web services required users to memorize and enter their passwords every time they logged in. Besides the inconvenience that was caused, this created security risks because users often picked weak passwords and reused them across multiple services. Token-based authentication addresses these issues. Let’s learn how this is achieved.
Tokens can be either software components (e.g., with the JSON Web Tokens standard), or hardware devices. They allow users to log in easily and stay so without compromising security. Tokens can also improve security by promoting the use of strong passwords, and acting together with passwords to enable Multi-Factor Authentication (MFA).
What Is Token-Based Authentication?
Token-based authentication simplifies the authentication process for known users. To begin with, the user sends a request to the server, using a username and password. The server then validates them based on values registered in its credentials database. If the credentials are confirmed, the server responds with an authentication token (which is also kept in the database).
When the same user sends requests to access secured resources in the future, the requests can be authorized with the authentication token, rather than the username and password. The server validates the token against the registered token in the database and grants access. Authentication can be carried out using various types of tokens like OAuth and JSON Web Tokens (JWT).
JWT uses a secure method, based on signed tokens, which makes it easy to identify modifications. Hardware tokens can contain a credential or generate a one-time password based on a challenge.
How Does Token-Based Authentication Work?
There are many ways to grant users authentication tokens—hardware-based tokens, one-time passwords (usually granted via mobile phones) and software-based tokens that are typically based on the JWT standard.
All tokens store user credentials and data in a secure manner. The token is also able to verify that the data is correct and was not tampered with, a crucial security requirement with so many data privacy laws out there today. They also dramatically enhance user experience, because they allow users to sign in without having to memorize passwords.
Token-based authentication typically follows a 4-step process:
- Initial request—a user requests access to a protected resource. The user must initially identify themselves in a way that does not require a token, for example using a username or password.
- Verification—the authentication determines that the user’s credentials are correct and checks which permissions they have on the requested system.
- Tokens—the system issues a token and grants it to the user. In the case of a hardware token, this involves physically provisioning tokens to the user. In the case of software tokens, this happens in the background as the user’s background communicates with the server.
- Persistency—the token is held by the users, either physically, in their browser or on their mobile phone. It allows them to authenticate without their credentials in the future.
Main Types of Authentication Tokens
Here are a few common types of tokens that are being used by developers to authenticate users or service accounts today.
Hardware Tokens (USB Tokens)
Hardware tokens are physical devices that enable the authorization of users to access protected networks. They are also sometimes called authentication or security tokens. The purpose of a hardware token is to add a layer of security via two-factor or multi-factor authentication (2FA or MFA). The token owner links the token to the system or service they want to access.
Hardware tokens are designed for user experience and customizability, so they can come in multiple forms. The most common types of tokens are key fobs and USB or wireless tokens. Hardware tokens can be divided into three categories.
- Contactless—a contactless token doesn’t require you to enter an access code or connect to a device. This type of token uses a wireless connection to access the system, which may grant or deny access based on the credentials associated with the connection.
- Disconnected—a disconnected token doesn’t need to be physically inserted into the system being accessed. It works by setting up the device to generate one-time access codes, which serve as part of 2FA or MFA. Typically, a disconnected token will be a mobile device like a smartphone.
- Connected—a connected token must be physically connected to a system in order to enable access. The token is scanned by a reader, which receives any relevant authentication credentials. This could be a USB token or a key fob (e.g. Yubikey).
JSON Web Tokens (JWT)
Because of their small size, JWTs can be sent as URLs, POST parameters, or HTTP headers, and can be transmitted quickly. The JWT contains all the necessary information about the entity, to avoid multiple queries to the database. The JWT receiver doesn’t need to call the server to validate the token.
A JWT is composed of three parts:
- A header, which includes the type of token and the encryption algorithm it uses.
- A payload, which provides authentication credentials and other information about the user or account.
- A signature, which includes a cryptographic key that can be used to validate the authenticity of the information in the payload.
One-Time Password (OTP) Tokens
One-time password (OTP) tokens are secure hardware devices or software programs that can generate one-time passwords. Most commonly, these are personal identification numbers (PIN), numeric codes between 4-12 digits.
Smartphones are commonly used to generate or receive one-time passwords. Once a user proves ownership of their phone, they can use an authenticator app that generates OTP passwords—in this case the phone serves as a code generator. Alternatively, OTPs can be sent to the device by SMS.
Related: What is Passwordless Authentication?
One-time password tokens enhance existing identity and password systems by adding dynamically generated credentials. Depending on the provider, OTP tokens generate PINs either synchronously or asynchronously:
- Synchronous tokens use your private key and the current time to create a one-time password.
- Asynchronous tokens use Challenge Response Authentication Mechanism (CRAM), a group of protocols in which the server presents a challenge, and the token must generate the correct answer.
In a nutshell, API Tokens are used as unique identifiers of an application requesting access to your service. Your service then generates an API token for the application to use when requesting your service. The API Token can then be matched with the one you have stored to authenticate and provide access. You can implement a Session ID in some use cases, but that is basically a very specific deviation.
API tokens have gained popularity as they replace the unsafe practice of sending username and password combinations over HTTP. OAuth2 (access tokens) is one of the most common ways of implementing API security today.
Related: API Token Generation
Is Token-Based Authentication Secure?
Cybercrime is becoming more sophisticated, which means that managed service providers (MSPs) must continuously update their security techniques and policies. There has been an increase in attacks that target credentials via methods like phishing, brute force and dictionary attacks. This means that authentication can no longer rely on passwords alone.
When combined with additional authentication techniques, token-based authentication can create a more complex barrier to prevent sophisticated hackers from exploiting stolen passwords. Tokens are only retrievable from the unique device that created them (i.e. a smartphone or key fob), making them a highly effective authorization methodology today.
While there are many advantages to authentication token platforms, some risk always remains. Tokens housed in mobile devices are convenient to use but may be exposed through device vulnerabilities. If the tokens are sent via text, they can be easily intercepted in transit. If a device is lost or stolen, a malicious actor can gain access to the tokens stored in it.
But always keep in mind that you should never rely on a single authentication measure. Token authentication should be considered as one component in a two-factor or multi-factor authentication strategy.
Pros and Cons of Software-Based Tokens
Like any other methodology or technique, there are pros and cons you must take into account before opting for this methodology.
Pros of Using Tokens
- Efficiency – Software-based tokens are efficient and scalable. The server can easily create and verify as many tokens as needed, making it easier to scale the number of users accessing your website or web application. Importantly, they do not require organizations to provision physical tokens to their users.
- Flexibility – Software-based tokens can be used on multiple servers, and can provide authentication for multiple websites and applications simultaneously. They are commonly used to implement single sign on (SSO), which is convenient for users and improves security.
- Security – Tokens using accepted standards like JWT are stateless, and can only be verified when the private key is received by the server-side application used to generate them. Therefore they are considered a robust, secure method of authentication.
Cons of Using Tokens
- Compromised Secret Key – A major drawback of the JWT standard is that it relies on one key. If the key is not managed properly by developers or website administrators and is compromised by attackers, this can put sensitive information at risk. It can enable attackers to impersonate users and hijack user sessions, malicious actions that can become hard to detect/contain.
- Data Overhead – The size of the JWT is much larger than a normal session token, and it grows with the amount of data stored about the client. Adding more data to a token can have an impact on the time required to establish a user session, and ultimately, increases page load times.
- Unsuitable for Long-Term Authentication – Systems that allow users to remain logged in for prolonged periods are less ideal. These tokens require frequent revalidation and can annoy users. Using refresh tokens and storing them correctly is a good workaround. Refresh tokens allow users to remain authenticated for longer periods without re-authorization.
Make sure you are planning properly and breaking down your use-cases. You can make the right decision only after doing so. Self-service is another key feature you should look to integrate into your ecosystem from the get go.