An old and trusted authentication mechanism that relies on passwords, but in a smarter way
In computer systems, a token is an object or structure used to transfer data between applications. Tokens are primarily used by stateless applications as a vehicle for client-side storage of session data. For example, a shopping app may track things like shopping carts, authentication data, and other session-related data in a token that is stored by the client, instead of maintaining and tracking session state on the app itself, and by doing so, allowing the app to be stateless.
Authentication tokens are a kind of token used to transfer authentication-related data between a client and a server, or between applications. For example, federated identity solutions like SAML and OpenID Connect rely on authentication tokens for exchanging authentication-related information between parties. JSON Web Tokens (JWT) are another kind of token used for exchanging authentication data in more proprietary authentication protocols.
Authentication tokens in general have three parts to them – a header, a payload and a signature. The header typically identifies the user via something like a username. The payload includes all of the authentication claims associated with the user and session. The signature is a digital signature that guarantees the integrity and authenticity of the claims in the payload.
Authentication tokens can be digitally signed to protect their integrity and allow the receiver to verify the identity of their sender. Because data stored by the client is subject to tampering, special care needs to be applied to prevent manipulations to the data. An effective way to achieve this is with the help of digital signatures. Once signed, any changes to the data can be easily detected. Forging a properly implemented signature is considered impossible.
Encrypting authentication tokens guarantees the confidentiality of their data. Without encryption, anyone can read the data, some of which may be sensitive and can provide an attacker with useful information.
Popular authentication token formats include SAML, which relies on XML tagging, and JWT, which is based on a JSON data object.
But what makes authentication tokens especially appealing for developers is that they enable building stateless apps. This means that the server does not have to keep track of authenticated sessions. Instead, this data is tracked by client-side data stored in an authentication token.
Once authenticated, the client receives from the authentication server a signed and often encrypted authentication token that it then appends to every request sent to applications that it wants to interact with. The app verifies the integrity of the authentication token and parses its contents. If everything checks out, the request is processed by the app and a response provided. The next request sent by the client will again include the authentication token and the process of verifying its integrity and parsing its contents will be repeated by the app.
Identity Federation makes extensive use of authentication tokens. Federated identity systems allow relying parties (i.e. applications) to use authentication services from a trusted identity provider (IdP) without the need for tight integration. In such systems, authentication and authorization data is exchanged bypassing authentication tokens.
Without going into specific details, the general setup for federated authentication and authorization (authN/authZ) schemes is as follows:
- A user attempts to access some resource/application for which access is restricted.
- Because the resource/application does not implement its own authN/authZ functionality, it redirects the user to an identity provider (IdP) for authentication.
- The user is authenticated by the IdP, which then creates a digitally signed authentication token attesting to the fact that the user was successfully authenticated and hands this token to the user.
- The user is then redirected back to the resource/application he wants to access and hands over the authentication token he received from the IdP.
- The resource/application reads the authentication token, verifies its signature and checks its claims to make sure the user meets the access criteria.
Common formats for authentication tokens include SAML, OpenID Connect, and JWT. For authorization claims, OAUTH2 is a commonly used standard and format. And while each token has its own specific data structures, claim types and digital signature conventions, they are all tokens with the same fundamental constructs – an identifier, a set of claims, and a digital signature from the entity making the claims.
Common attacks on token-based authentication include stealing authentication tokens using malware and cross-site scripting attacks.
Malware sitting on the client can read a valid authentication token and reuse it so long as it is not expired.
Cross-site scripting (XSS) attacks are probably the most notorious form of attack on authentication tokens. Malicious JavaScript (JS) that reads authentication tokens is injected by an attacker to a trusted site. It is then served by the site to its users, and executed by their browsers where it reads authentication tokens from the user’s machine and sends them to the attacker. Once in possession of a valid token, an attacker can use it to access protected resources. For example, a Web application that enables users to post comments does not properly validate and sanitize the strings posted by users. As a result, a malicious user posts a comment with a <script> tag. The app serves this malicious script to its other users and their browsers execute it.
In summary, authentication tokens have grown in popularity and are a de facto standard for most modern applications. They help application developers build stateless applications that are easier to maintain and scale.
