Token-based authentication is an authentication strategy designed to enhance network security. Users enter their credentials, these credentials are verified, and a unique encrypted token is generated that allows them to access online resources without providing their username and password to authenticate every request.
Inherently more secure than passwords, tokens are encrypted machine-generated codes that are used to confirm that users are who they claim to be and which resources they can access. Tokens are self-contained entities that have all of the information needed to authenticate a user’s identity and the validity of the request. Because the server side doesn’t need to maintain the state of a user, token-based authentication is often referred to as stateless authentication.
Each token is unique to a user’s session and is protected by an algorithm, which ensures servers can identify tokens that have been tampered with. Tokens can also provide administrators with fine-grained access control to resources and the roles and permissions users have within each application. Tokens can even be revoked, which disables application access.
But perhaps most importantly, token-based authentication improves the user experience. Users enter their credentials to start a session. Authentication and authorization processes are performed behind the scenes, and users aren’t even aware that it’s happening. When the token expires or users sign off, the session ends, and the tokens are eliminated.
The types of tokens often used during authentication and authorization processes include:
Hardware tokens
One-time passcode (OTP) tokens
JSON Web Tokens (JWTs)
API tokens
Users authenticate by proving they have tangible devices, such as smart cards, key fobs, or USB devices, in their possession. These tokens add a layer of security to the authentication process and can be:
Contactless: This type of token doesn’t require you to enter an access code or connect to a device. It uses a wireless connection to access the system, which grants or denies access based on the credentials associated with the connection.
Disconnected: This type of 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 a multi-factor authentication (MFA) process. Typically, a disconnected token is a mobile device like a smartphone.
Connected: This type of token must be physically connected to a system to enable access, such as a USB token or a key fob. The token is scanned by a reader, which receives any relevant authentication credentials.
Users authenticate by providing one-time passcodes (OTPs) that they receive through email or text message. These codes are typically valid for 30-60 seconds. During the session, the token is temporarily stored until the session expires.
OTP tokens can be:
Synchronous, where the token contains a private key to create an OTP when the session begins.
Users authenticate by providing their username and password. This information is verified and a JSON web token (JWT) is generated, which contains information about the token, the encryption algorithm it uses, user credential information, and the authenticity of the messages transmitted.
JWTs contain:
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.
These tokens are used as unique identifiers for applications requesting access to a service. The service generates an API token for the application to use, which can be matched to the one stored to authenticate and gain access.
Token-based authentication processes vary, but they generally work like this.
A user requests access to a protected server, site, application, or resource and is prompted to authenticate.
The server verifies the user’s credentials to determine if they are who they say they are.
After verification, the server issues the user a security token that grants them access to their authorized resources.
The token is stored in the user’s browser for the duration of the session and is referenced every time the user tries to access a different part of the server. The user’s access to these resources is specified in the token.
The token expires when the session times out, the user signs off, or the connection to the server is severed.
The most well-known authentication and authorization frameworks and standards, OAuth, OpenID Connect (OIDC), and SAML use token-based authentication methodologies.
The primary difference between these standards is that OAuth, now known as OAuth 2.0, is an authorization framework used to protect specific resources, such as applications or sets of files, while SAML and OIDC are authentication standards used to create secure sign-on experiences.
SAML is an open federation standard that enables single sign-on (SSO). SAML tokens are XML representations of claims made by one entity about another entity. The SAML token is signed with a certificate associated with the security token service and contains a proof key encrypted for the target service. The token is presented and users ultimately gain access to the application. See SAML for details.
Widely used in enterprise organizations, SAML was created to support SSO for browser-based applications and services. It does not support SSO for mobile applications or applications that access resources through the API.
OAuth is an open standard framework for API authorization and not an authentication protocol. It doesn’t define a specific token format or a common set of scopes for the access token, nor does it address how a protected resource validates an access token.
Instead, OAuth defines how an API client can obtain security tokens that contain a set of permissions against the resources available through that API. See OAuth for details.
OIDC uses JWTs and access tokens to complete authentication and authorization processes. JWTs contain information about the user, such as their usernames, when they attempted to sign on to the application or service, and the length of time they are allowed to access the online resources.
Access tokens are used to access protected resources, which are intended to be read and validated by the API. These tokens can be JWTs, but might be in a different format. Their purpose is to inform the API that the bearer of this token has been authorized to access the API and perform specific actions, as specified by the scope that has been granted. See OIDC for details.
For additional information regarding these standards, see Authentication and Authorization Standards.
Start Today
Contact Sales
See how Ping can help you deliver secure employee and customer experiences in a rapidly evolving digital world.
Request a FREE Demo