Token-based authentication is one way to confirm a user's or device's identity. It relies on checking to see if the entity in question possesses a previously issued token.
After reading this article you will be able to:
Copy article link
Token-based authentication is the process of verifying identity by checking a token. In access management, servers use token authentication to check the identity of a user, an API, a computer, or another server.
A token is a symbolic item issued by a trusted source — think of how law enforcement agents carry a badge issued by their agency that legitimizes their authority. Tokens can be either physical (like a USB hard key) or digital (a computer-generated message or digital signature).
Token-based authentication can refer to a couple of different processes:
Authenticating via physical token usually takes place during the user login process. The user has to prove that they possess an item no one else has. They can prove this by entering a code displayed by the item, connecting the item to a device via USB, connecting the item via Bluetooth, or several other methods. Similar to the way entering a password proves that the user possesses a piece of knowledge that no one else has, using a token proves that a user possesses an item only that user has.
There are two kinds of tokens used for this type of authentication: soft tokens and hard tokens.
A web token is digital, not a physical item. It is a message sent from a server to a client and stored temporarily by the client. The client includes a copy of the token in subsequent requests sent to the server to confirm the client's authentication status.
While physical token authentication verifies identity during the login process, web tokens are issued as the result of a successful login. They keep the logged-in session active.
However, using web tokens for user sessions is not always ideal. Many developers are proponents of using cookies instead. Web tokens may be better used for API endpoint authentication or to validate a connection between servers, instead of between server and client.
JWTs include three components:
JWTs are sometimes used to keep users authenticated once they log in to a web application. However, cookies can be used for this purpose too.
A cookie is a small data file that a server sends to a client. When a user signs in to a web application, the server generates a cookie and sends it to the client device (typically a user's computer or smartphone). The client device stores the cookie in the browser's cache and includes a copy of the cookie in future requests to the server, similar to how JWTs can be used. Once the user signs out, the browser deletes the cookie.
Cookies have a much smaller file size compared to JWTs, because JWTs include headers and digital signatures in addition to the payload. By contrast, the cookie only contains the payload. This makes them far more efficient in terms of web performance and bandwidth.
JWTs are not optimized for performance because they include digital signatures, which ensure their contents have not been tampered with. But if a web application is using HTTPS (as it should), a cookie should be tamper-proof anyway. HTTPS will encrypt and sign the cookie along with all the other HTTP data being exchanged between client and server, and attackers should not be able to forge it or intercept it in transit, unless they are carrying out an on-path attack.
JWTs are better suited for APIs and server-to-server connections. Such uses do not need to scale up quite as much: a web application may get a million users, but it is not going to have a million API connections. This reduces the potential impact on performance and bandwidth. However, other authentication methods, like mutual TLS, are sometimes more efficient for APIs — learn more about mutual TLS.