Opaque Access Tokens (OAT) vs JSON Web Tokens (JWT)

In This Lesson

We'll take a step back to understand the differences between the tokens we're using, which are Opaque Access Tokens (OAT), and JSON Web Tokens (JWT). We'll discuss security, scalability, and what makes up each token.

Created by: @tomgobich
Published: 7 months ago

Join the Discussion 0 comments

Be the first to comment!

Transcript

>> So far, you've heard me refer to these tokens that we're creating as opaque access tokens a couple of times. Today, let's take a second to stop and compare it to
another popular type of token called a JSON Web Token or JWT. A JWT is a by-value token, meaning that it contains claims or information about our user itself.
In addition to that, it's comprised of three different parts, a header, a payload, which contains that claim information, and a validity signature. So the validity signature is used to
actually determine whether or not the token itself is valid, meaning that it is stateless in terms of our server. It does not need to communicate with our server in
order to determine if the token itself is valid. It can just use that validity signature to do exactly that. In addition to our user information,
the payload also contains when the token is going to expire. Now, because the JWT contains whether or not the token itself is valid or not via that validity signature,
and it contains the expiry information, that means that we cannot invalidate or revoke the signature from our server. We have to wait for the token itself to expire on its own.
Opaque access tokens, on the other hand, are a by-reference token, meaning that they do not contain claims or information at all about our user,
but instead act as more of a pointer to that information elsewhere. This elsewhere in this case is our database. Now, we've taken a look at this in
the previous lesson after we actually created the token, but we can jump into TablePlus here and see these actual API access tokens that we've created directly inside of our database.
This contains their abilities, the hash of the token, as well as when those tokens would expire if that's populated. That means a couple of things for our opaque access tokens,
also abbreviated as OAT. In order for us to discern whether or not the token itself is still valid, we need to send a request out to our server
because that information is housed inside of our database, not the token itself like a JWT has it. Our server is then going to be able to tell us the token's abilities, when that token should expire, if it should at all,
as well as who that token is for. In our specific case, that's for an organization. In standard cases, that's going to be the user's information.
Another advantage of OAT tokens is that we can expire them whenever we need to. Since that value is housed inside of our database and the front-end relies on our server to tell us whether or not that token is still valid,
all we need to do is update that token's database record, either setting the expiry to sometime in the past or deleting that record outright,
to invalidate that token for our user. That can mean that compared to JWTs, OATs can be longer lived than your typical short-lived JWT token.
The token value for OATs compared to JWT, which has those three different parts, is just a cryptography safe random string. In our case, we do have that prefix that we added on,
which is an API underscore. All of our tokens are going to start with that API underscore whenever we create them, but the rest of that token then is just a cryptography safe random string.
JWTs already have baked directly into the token, its abilities, validity, as well as who the token is for. OATs, on the other hand, need to go through the database,
through our server to get that information. There's a small difference there that's going to add additional latency on the OAT side. But again, that's not going to come into play until you reach
a much larger scale than most typically need to worry about. To wrap up, JWTs tend to be less secure because they contain users' information and whether or not the token is valid directly in there,
and they have no way of being revoked. OAT tokens, on the other hand, don't contain our users' information, its expiry, or its abilities.
All of that is pointed to via the token to our database through our server. They can be revoked at any moment's notice. They tend to be more secure because of all of that,
and they follow the never trust, always verify principle. However, they do tend to be less scalable due to the additional round trip
that they need to do with the database, where JWTs do not.

Adding an API to an AdonisJS Web App

43 Lessons

5h 31m

Introduction

API Authentication

Getting Started with APIs

Organization Resources

Courses

Searching

Rate Limiting

Rate Limiting an Organization's HTTP Requests

13m 59s

Stop losing your best ideas!

Use our integrated note feature to capture and organize your key insights. Take a note at any timestamp and jump instantly back to that moment in the video with a single click.