Token-based authentication is a protocol which allows users to verify their identity, and in return receive a unique access token. During the life of the token, users then access the website or app that the token has been issued for, rather than having to re-enter credentials each time they go back to the same webpage, app, or any resource protected with that same token.
Auth tokens work like a stamped ticket. The user retains access as long as the token remains valid. Once the user logs out or quits an app, the token is invalidated.
Token-based authentication is different from traditional password-based or server-based authentication techniques. Tokens offer a second layer of security, and administrators have detailed control over each action and transaction.
But using tokens requires a bit of coding know-how. Most developers pick up the techniques quickly, but there is a learning curve.
Let's dig in, so you can determine if tokens are right for you and your organization.
A History of Authentication Tokens
Authentication and authorization are different but related concepts. Before we had authentication tokens, we had passwords and servers. We used traditional methods to ensure that the right people had access to the right things at the right time. It wasn't always effective.
Consider passwords. Typically, they involve:
- User generation. Someone comes up with a combination of letters, numbers, and symbols.
- Memory. The person must keep that unique combination in their mind.
- Repetition. Whenever the user needs to access something, the password has to be entered.
Password theft is common. In fact, one of the first documented cases of password theft happened all the way back in 1962. People can't remember all of their passwords, so they resort to tricks, such as:
- Writing them all down. Loose pieces of paper filled with passwords are security nightmares.
- Repeating them. People tend to use the same password in multiple places. If one password is discovered, many accounts may be vulnerable.
- Slightly changing them. People change one letter or number when prompted to update a password.
Passwords also require server authentication. Each time the person logs on, the computer creates a record of the transaction. Memory load increases accordingly.
Token authentication is different.
With token authentication, a secondary service verifies a server request. When verification is complete, the server issues a token and responds to the request.
The user may still have one password to remember, but the token offers another form of access that's much harder to steal or overcome. And the session's record takes up no space on the server.
3 Authentication Token Types
All authentication tokens allow access, but each type works a little differently.
These are three common types of authentication tokens:
- Connected: Keys, discs, drives, and other physical items plug into the system for access. If you've ever used a USB device or smartcard to log into a system, you've used a connected token.
- Contactless: A device is close enough to a server to communicate with it, but it doesn't plug in. Microsoft's so-called "magic ring" would be an example of this type of token.
- Disconnected: A device can communicate with the server across long distances, even if it never touches another device at all. If you've ever used your phone for a two-factor authentication process, you've used this type of token.
In all three of these scenarios, a user must do something to start the process. They may need to enter a password or answer a question. But even when they complete those preliminary steps perfectly, they can't gain access without the help of an access token.
Token Authentication in 4 Easy Steps
Use a token-based authentication system, and visitors will verify credentials just once. In return, they'll get a token that allows access for a time period you define.
The process works like this:
- Request: The person asks for access to a server or protected resource. That could involve a login with a password, or it could involve some other process you specify.
- Verification: The server determines that the person should have access. That could involve checking the password against the username, or it could involve another process you specify.
- Tokens: The server communicates with the authentication device, like a ring, key, phone, or similar device. After verification, the server issues a token and passes it to the user.
- Storage: The token sits within the user's browser while work continues.
If the user attempts to visit a different part of the server, the token communicates with the server again. Access is granted or denied based on the token.
Administrators set limits on tokens. You could allow a one-use token that is immediately destroyed when the person logs out. Or you could set the token to self-destruct at the end of a specified time period.