Identity Providers: What is Token Based Authentication?

Token-based authentication starts with a user logging into a system, device or application, typically using a password or a security question. An authorization server validates that initial authentication and then issues an access token, which is a small piece of data that lets a client application make a secure call or signal to an API server.

Token-based authentication works by giving the server a second, high-assurance way to verify the identity of the user and authenticity of the request.

Once this initial token-based authentication protocol is completed, the token works like a stamped ticket: The user can continue to seamlessly access the relevant resources, without re-authenticating, for the duration of the token lifecycle. That lifecycle ends when the user logs out or quits an app — and can also be triggered by a set time-out protocol.

Token-based auth provides many benefits across multiple stakeholders:

• Seamless user experiences: Instead of having to re-enter credentials and re-authenticate each time they return to a system, app or webpage, the user retains seamless access as long as the token remains valid (generally until the session is ended by logging out or quitting).
• Added digital security: Token-based authentication adds an additional layer of security on top of traditional password-based or server-based authentication. Tokens are generally much harder to steal, hack or otherwise compromise than a password.
• Admin control: Token-based auth gives administrators much more granular control and visibility over each user action and transaction.
• Lighter tech burden: Because token generation can be fully decoupled from token verification, the verification can be handled by a secondary service like that provided by the Entrust Identity and Access Management solution. This significantly reduces the load places on internal servers and devices.

Access or authentication tokens grant users access to a device, application or other digital resource. There are many different types of tokens available today:

Hardware tokens

Hardware tokens are small physical devices that users present to gain access to a resource. Hardware tokens can be connected (i.e., USB, smart card, one-time password key fobs) or contactless (i.e., Bluetooth tokens). These tokens are carried with the user. In the early days of token-based authentication (read: pre-smartphone), hardware tokens were the only option. However, hardware tokens are comparatively expensive, are subject to loss and theft, and often require more significant IT support as a result.

Software tokens

Software tokens, also called disconnected tokens, are truly contactless and can authenticate identity from anywhere. The most common examples of software tokens are now mobile applications that use smartphones to facilitate two-factor authentication (2FA), multi-factor authentication (MFA) or JSON web tokens. Software tokens are increasingly the dominant choice for token-based authentication, offering an advantage in reduced cost, reduced user friction, reduced likelihood of loss or theft, and less risk for man-in-the-middle attacks.

The most common type of disconnected or software tokens is the open-source token — more specifically, the JSON Web Token (JWT). JSON is an open-source standard (RFC 7519) that offers a simple, self-contained protocol for encoding information as a JSON object, which enables that information to be efficiently and securely transmitted between. JWT have risen in popularity because they are extremely compact object which can be transmitted in a variety of efficient means, including through query strings, header attributes and within the body of a POST request.

A JSON web token comprises three distinct parts:

• Header: The type of token and encryption algorithm
• Payload: The authentication credentials for the given resource
• Signature: A cryptographic key to verify the authenticity of the payload

There are five key steps to implementing a token-based authentication protocol:

1. Request: A user inputs their login credentials
2. Verification: The server verifies the user’s credentials
3. Token submission: The server generates a token that will be valid for a set time period
4. Storage: The token is stored by the user’s web browser for future use
5. Expiration: The token remains active for a given time period

While token-based authentication is undoubtedly a major step above traditional password-based authentication, the token is still considered a “bearer token” — that is, access is granted to whomever holds the token. This means that even software tokens like mobile applications are still subject to theft or compromise: If a malicious individual comes into possession of a token, they could then use that token to gain unauthorized access to protected resources and information. To protect against this remaining risk of compromise and breach, it’s important to build your token-based authentication program around the following best practices:

• Keep the token confidential: Users should treat the token — whether hardware or software — like any secure credential. This means it should be stored safely and securely, never shared and only revealed to verified services, so as to prevent loss or theft.
• Simplify the token payload: Tokens are designed to use the bare-minimum amount of information to authenticate a user. While they’re encoded, they’re also easily decoded by malicious actors. For this reason, never place sensitive or protected information within the token payload — and aim to minimize the claims to the payload. This will also help boost speed/performance.
• Define token expiration and enable token revocation: A token is typically set to expire automatically when a user logs out or does a hard quit. But technically, absent this session-ending trigger, a signed token has no built-in expiration. To protect against compromise, you should set a default expiration on all tokens and have a protocol in place for revoking tokens when necessary.
• Always use HTTPS connections: Unsecured connections make it incredibly easy to intercept and steal tokens in-transit. Always utilize HTTPS connections when transmitting tokens to and from the token verification server.
• Consider additional layer(s) or security: Depending on your security requirements, it may be necessary to add additional security and authentication protocols on top of basic token-based authentication. For example, some use cases add a second token verification system that specifically ensures all tokens are generated from the correct server.