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