What Is Token-Based Authentication?

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.

JSON Web Token (JWT): A Special Form of Auth Token

Because so many users are accessing systems via mobile phones (apps) and web apps nowadays, developers need a secure way to authenticate that’s appropriate for those platforms.

To solve that challenge, many developers turn to JSON Web Tokens (JWTs) when working on tokens for their applications.

A JSON web token (JWT) is an open standard. The finished product allows for safe, secure communication between two parties. Data is verified with a digital signature, and if it's sent via HTTP, encryption keeps the data secure.

JWTs have three important components.

Header: Define token type and the signing algorithm involved in this space.
Payload: Define the token issuer, the expiration of the token, and more in this section.
Signature: Verify that the message hasn't changed in transit with a secure signature.

Coding ties these pieces together. The finished product looks something like this.

Don't be intimidated by JSON code. This type of notation is common when entities want to pass data back and forth, and tutorials abound. If you're interested in using JSON tokens but you've never tried the language before, a resource like this could be helpful.

Pros & Cons of JWTs

There are many benefits of JWTs.

Size: Tokens in this code language are tiny, and they can be passed between two entities quite quickly.
Ease: Tokens can be generated from almost anywhere, and they don't need to be verified on your server.
Control: You can specify what someone can access, how long that permission lasts, and what the person can do while logged on.

There are also potential disadvantages.

Single key: JWTs rely on a single key. If that key is compromised, the entire system is at risk.
Complexity: These tokens aren’t simple to understand. If a developer doesn’t have a strong knowledge of cryptographic signature algorithms, they could inadvertently put the system at risk.
Limitations: You can’t push messages to all clients, and you can’t manage clients from the server side.

Why Should You Try Authorization Tokens?

You've assessed your current strategy, and you think things are working just fine. Why should authorization tokens become part of your systems? Very real benefits come to developers who take the plunge.

Authorization tokens are good for administrators of systems that:

Often grant temporary access. Your user base fluctuates based on the date, the time, or a special event. Granting and rescinding access repeatedly is too draining. Tokens could be helpful.
Administrators of university library sites, for example, might appreciate a token approach.
Require granular access. Your server grants access based on specific document properties, not user properties. Passwords don't allow that time of fine-tuned detail.
For example, you run an online journal. You want everyone to read and comment on only one document, not on any others. Tokens could allow this.
Are prime hacking targets. Your server contains sensitive documents that could do your company intense damage on release. A simple password doesn't offer enough protection. A piece of hardware helps quite a bit.

Many more authentication token use cases exist. But this quick list could get your creative juices flowing, and the more you think about the benefits, the more likely you might be to get on board.

Follow Authentication Token Best Practices

Authentication tokens are meant to enhance your security protocols and keep your server safe. But they won't work effectively if you don't build your processes with safety in mind.

Your authentication tokens should be:

Private. Users can't share token authentication devices or pass them around between departments. Just as they wouldn't share passwords, they shouldn't share any other part of your security system.
Secure. Communication between the token and your server must be secure via HHTPS connections. Encryption is a critical part of keeping tokens safe.
Tested. Run periodic token tests to ensure that your system is secure and functioning properly. If you spot a problem, fix it quickly.
Appropriate. Pick the right token type for your individual use case. For example, JWTs aren't ideal for session tokens. They can be costly, and security risks involved with interception are impossible to eliminate. Ensure you're always picking the right tool for the job.

Don't take your authentication token decision lightly. Do your homework, ask your peers, and ensure that you're doing the best job you can for your company.

Let Us Help

As we continue to evaluate how we secure access to our homes and offices, it’s just as important to implement mechanisms like token-based authentication to ensure that only the right people have access to our digital resources.

Discover how Okta can better secure your world.