Ultimate Guide to Token-based Authentication

Identity management topics can be a bit abstract or in the clouds, literally. You may already be familiar with authentication, which I described in a prior blog. At its core, authentication is a method for verifying that a user is who they claim to be, and used to keep bad actors out of your network. Unlike passwords, which can be easily compromised and used by hackers for data breaches, tokens are more secure.

Read on to learn:

• What a token is
• Why tokens should be used
• What token-based authentication is and how it works
• The benefits of token-based authentication
• Types of authentication protocols, including uses and limitations

To make token-based authentication easier to understand, let’s start with some examples of “tokens,” which are basically versions of secret passwords, knocks or phrases used to verify identities.

A cartoon character knocks on a door and a sliding panel opens with a face appearing, waiting for the secret phrase (“Joe sent me”) before opening the door to keep out undesirables. It could also be a special sequence of knocks (two knocks, pause, three knocks) instead of a secret phrase. 

Or maybe you prefer spy movies, where two people need an inconspicuous way of verifying their identities when meeting for the first time in a public place. The secret code is an agreed-upon message. The spy looking for his contact in a bar makes a seemingly random comment, to which his contact responds with the correct answer to verify her identity. Only then will the conversation or hand-off of confidential information occur.

Cartoons and movies notwithstanding, auth tokens are incredibly useful tools when we execute transactions online to prove one’s identity during logins, updates, purchases and other processes. The great thing about auth tokens is that they might be seamless, as in the case of a login experience, or not so much, applying “friction” (additional or manual input) as I have discussed in previous blogs to ensure that you are who you say you are and that you do indeed want to execute the particular action.

Because tokens don’t have to contain a user’s personal data and are algorithm/software generated, they keep this data safer from hackers. This is a huge improvement over enterprises using a person’s social security number or other personal/private information as their account number, making it easier for bad actors to steal identities. Or users who include personal data in their passwords, like the names of their pets, that can be easily discovered by bad actors with a quick search of the user’s social media accounts.

Token-based authentication can be thought of as starting a conversation with someone online. Instead of two people communicating, pieces of code are communicating with each other in the background, sharing the same secret passcode or agreed-upon symbols to generate a token that completes the authentication process. Verifying the user’s identity with a token prevents unauthorized users from accessing your resources.

Tokens can be used at different stages of the authentication process, including multi-factor authentication (MFA) and through protocols working on the backend between applications, APIs and/or websites.

Step back from the technology itself to look at the problem you are trying to solve. In order to keep bad actors out of your network (where they can steal data, install ransomware, etc.), you are asking legitimate users to prove their identities. When we use a token that comes from an application such as PingID, a key fob, or a dongle that we plug into our computer, we keep outside actors from interfering because the token is based on the private key of the device. If you make it too difficult, they will choose a competitor’s service over your own. Selecting a token-based authentication solution that verifies users without causing friction or frustration is the “why.” A process that runs smoothly keeps users happy and data secure. 

Of course, technology isn’t foolproof. Poor planning and implementation can make matters worse, as we’ve seen with companies that use technology to automate and streamline operations to improve the user experience, while simultaneously reducing staff. Customer expectations are set, so when authentication or other automated systems fail, people get frustrated and angry. Imagine an airline with a system failure that prevents customers from accessing their accounts online to buy tickets, check-in or rebook. Customers are forced to wait on hold for hours or stand in a long line at the airport after their flight has been cancelled. Will they fly that airline again?

That reminds me of a story. My mother was flying cross-country for a visit. I won’t name and shame the airline, as tempting as it is. While my mother claims she’s not a techie, she really is. She spent 30 minutes trying to confirm her reservation online, but couldn’t get into the system. She finally had to call, and a nice employee helped her out. When the employee asked if there was anything else she could do, my mother asked if the $25 surcharge for phone assistance would be removed. The employee said no, until my mother reminded her the airline’s website prevented her online confirmation. The employee finally agreed to remove the fee. Companies that don’t scale technology correctly or understand the user experience are destined to disappoint and lose customers.

Watch this short video about customer identity to understand why the user experience is so important.

Whether we are talking about an airline, bank or other service, understanding the applications your customers and employees need to access during a session is part of the process for mapping out the tokens that will be required. Where are the applications located (cloud or on-premises) and who owns them (your company or a partner)? Users checking their bank balances online don’t want to have to create and use separate logins to pay their bills and order checks. The easier it is to adopt strong authentication, the more widely it can be used.

Token-based authentication is inherently more secure than other forms of authentication, especially passwords. That’s what it all boils down to.

Benefits include:

• Stateless (self-contained)
• Provides fine-grained access control
• Flexible - expiration time (session or longer), exchangeable and refreshable
• Generated from anywhere
• Streamlines the authentication process

Applications don’t necessarily live on our computers anymore, they are in the cloud. Your laptop can be talking to your company’s cloud applications, partner cloud applications or possibly unsecured sites. There is a growing trend to communicate with cloud applications via application programming interfaces (APIs), including RESTful APIs. These connections need to be secure so that our personal information is protected.

There are a lot of tools we can use for token-based authentication. Let’s start by defining several authentication protocols.

Open Authorization (OAuth) emerged from the social web to allow users to specify authorization permissions without divulging social media credentials. OAuth is the standard which describes how a client-side application obtains an access token in the first place. OAuth defines many grant types to accommodate various flows and user experiences.

Security Assertion Markup Language (SAML) is the grandparent of authentication protocols and still the backbone of web-based single sign-on (SSO). By making a range of resources accessible with just one set of login credentials, you can provide seamless access to resources and eliminate insecure password proliferation. SAML doesn’t actually specify a method of authentication on the identity provider side.

OpenID Connect (OIDC), currently at version 2.0, is ideal for connections between modern applications found on the web and various types of applications that use RESTful APIs. As Single Page Applications (SPAs) become more popular, OIDC is becoming more important.

Client Initiated Backchannel Authentication (CIBA) is an extension to the OpenID Connect flow. CIBA decouples the client application and authentication server without redirects through the user’s browser.

JSON Web Token (JWT) is an open standard that contains encoded JSON objects, including a set of claims that cannot be altered after a token is issued. JWT is often used for web APIs, including RESTful APIs, to authenticate a user wanting access to the API. 

You need to look at your needs, use cases and identity framework to select the best protocol for your enterprise. For example, let’s compare SAML to OIDC.

• Any time you are working with a Single Page Application (SPA), SAML really doesn’t support it.
• New applications tend to favor OIDC with CIBA.
• Probably the most important, SAML is web application only, OIDC can be used with applications (mostly mobile apps).

The choice of the best authentication token is situational. Making the decision on whether to use OAuth, SAML, JWT or another auth token should be based on your applications, needs and use cases. 

My colleague, Lee Brewer, has provided a quick overview of token usage below. While not all-inclusive, it provides a good starting point for discussions and decisions about auth token selection.

Token-based authentication for web APIs is the process of authenticating users or processes for applications in the cloud. The user’s application sends a request to the authentication service, which confirms the user’s identity and issues a token. The user is then able to access the application.

Token-based authentication for RESTful APIs is easier to use than lower level web APIs. Often an open-standard JWT token, the format looks like a web address with a long string of characters with a verb (e.g., GET, PUT, or POST) and an endpoint. If you want to learn a bit more about how RESTful APIs work, you might want to consider reviewing this link.

Hard and soft tokens fall under the “something you have” authentication factor in multi-factors authentication, typically used after the “something you know” username-password combination to verify a user’s identity.

Hard tokens, also referred to as connected tokens, include keys, dongles, and other devices you plug into your computer. A one-time password or passcode (OTP) is generated to authenticate the user with the authentication server. If we want to make this even more secure, we can consider adding a PIN code as well. This might introduce more friction, but it engages multi-factor authentication by including “something you know” along with the “something you have” dongle.

Soft tokens, also referred to as disconnected tokens, are software generated through devices in the user’s possession, such as mobile devices. OTPs can be used to authenticate the user’s identity, as can biometrics such as touch ID.

I hope that in this blog, I’ve been able to get you more acquainted with why an organization might want to include tokens as a part of your overall authentication goals. Including auth tokens provides stronger security to this part of your IAM planning. For some additional reading on this, please consult Ping Identity’s Buyer’s Guide to Multi-factor Authentication to learn more about how tokens can be a part of your authentication strategy.