Skip to main content Accessibility Feedback

Token-based authentication terminology

This is an excerpt from my brand new pocket guide and video course on Token-Based Authentication. It’s part of a new Expert Bundle that also includes courses on State-Based UI and Serverless (coming this week).

There are numerous terms (and in some cases, buzzwords) used with token-based authentication. Let’s demystify them.

Authorization, Authentication, and Identity

Authorization, authentication, and identity are related to each other, so we’ll be looking at them together.

  • Authentication is this process of confirming that you are who you say you are. This typically involves providing credentials like a username and password.
  • Authorization is the process of verifying whether or not you have access to something. The token you get back from the authentication step is typically used for authorization on subsequent API requests.
  • Identity is information about you, such as your username, email address, or first and last name.

The authentication process returns a token that you use for authorization.

Depending on the type of token-based authentication provider you’re using, that token (or a second one) may also include identity information.

JSON Web Tokens

JSON Web Tokens are more commonly referred to as JWTs and pronounced “jot” or “jots” (I have no idea why!).

The tokens returned by the authentication process are often cryptographically-random strings that need to be validated by the third-party that issued them. A JWT is a special kind of token that is self-verifying and contains identity information.

A JWT is compromised of three parts, each separated by a dot (.).

  • Header. The part before the first dot is information about algorithm and token type.
  • Payload. Data such as the user identity and the permissions they have (often called claims).
  • Signature. A bit of data a server can use to verify that the JWT is valid and has not been tampered with.

A JWT typically looks a bit like this.

xxxxx.yyyyy.zzzzz

Because they contain a lot of information, the three parts are typically all Base64-URL encoded, resulting in something that looks like this.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

You can decode the Payload part of a JWT and get back a data object with a small vanilla JS helper function.

/**
 * Decode a JWT payload
 * https://stackoverflow.com/a/38552302
 * @param  {String} token The JWT
 * @return {Object}       The decoded payload
 */
function parseJWT (token) {
	let base64Url = token.split('.')[1];
	let base64 = base64Url.replace(/-/g, '+').replace(/_/g, '/');
	let jsonPayload = decodeURIComponent(atob(base64).split('').map(function(c) {
		return '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2);
	}).join(''));
	return JSON.parse(jsonPayload);
}

OAuth, OpenID, and SAML

OAuth, OpenID, and SAML are all standards (guidelines for providing standardized ways of doing the same task) that define protocols for authenticating and authorizing users.

  • OAuth is one of the most popular standards for authenticating users. It defines the flows that are used in many token-based authentication processes.
  • OpenID is an identity standard built on top of OAuth. In addition to authenticating a user, it returns a JWT that contains identity information.
  • SAML stands for Security Assertion Markup Language. It’s an alternative to OAuth that uses an XML-based standard instead of JWTs to handle authentication and identity.

There are a handful of vendors, like auth0 and Okta, that provide token-based authentication and identity services. Most of them use a mix of OAuth, OpenID, and SAML, depending on the needs of the customer.