Why do tokens expire?

Speaker 0: Hey, developers. Welcome to authentication avenue. You know how spies in movies have secret codes that expire after a single use? Well, in modern applications, we do something similar with access tokens. Today, we're exploring why these digital passes have expiration dates and the clever system that keeps users logged in securely.

Imagine you're visiting a big amusement park. When you arrive you get 2 things, a ride pass that's good for just one day, that's like your access token, and a special VIP card that's good for the whole year, That's like your refresh token. Now when your day pass expires, you don't need to go back to the ticket counter and buy a new ticket. Instead, you can show your VIP card at the special kiosk, and it will print you a fresh day pass on your next visit. And this is exactly how modern applications handle access.

Your access token is like that day pass. It lets you go on rides or in our case make API requests, but it expires quite quickly. The refresh token is like the VIP card. It's valid for much longer and lets you get new access tokens without logging in again. But why not just make the access token last forever?

Well, imagine if someone stole your day pass, they can use it till the end of the day. But, if they stole a much longer pass, say for the whole year, they could keep using it forever. And that's why we keep access tokens short lived, it's safer that way. In Directus, here is how it works. When you log in, you get a package of data containing an access token, usually valid for 15 minutes, although you can configure that, A refresh token, valid for much longer, and an expiration time stamp.

Now when your access token expires, you call the refresh endpoint with your refresh token, and then get a fresh package of tokens. And if you want to log out, you can destroy these tokens, just like shredding your park passes so nobody else can use them. This is especially important when using shared computers or if you think your tokens might be compromised. So there you have it. Token expiration isn't just an inconvenience, it's a crucial security feature that helps keep your application safe.

Let's see how it works in Directus. I wanna show you how to interact with Directus' authentication endpoints via API, and we're going to start with the login endpoint. So this is a post request to /auth/login. In the body, we provide the email and password, and when we send that, we receive a packet of data back. We what?

Oh, there we go. We have an an access token, which we can use in order to make requests. We have a refresh token and an expiry time. This is 30,000 milliseconds or 30 seconds. I've set it to be quite short in this project to demonstrate my point.

Now we can use this access token here in order to authenticate requests and retrieve data, but as you might remember, we've only set this to 30 seconds before expiry. So if I try and hit send again, we see that the token has expired. This whole token is no longer usable. So what do we do? We won't always be able to send off an email and password because we may no longer have access to them.

You don't necessarily want to store them, so we use the refresh token. Now the refresh token also expires, but a much, much longer time. I believe the default is 7 days, but it is configurable just like the access token is, which I set to 30 seconds here. So we have this refresh token, and we also have a refresh endpoint, post slash auth slash refresh. We provide our refresh token, and what we receive back is the same data packet, an access token, a refresh token, and the amount of time until it expires.

You can now use this new access token in order to authenticate requests. And once again, this refresh token is now spent, it no longer works. You can now use the new refresh token in order to receive a new packet of data. And once you're done and you want to log out, you can hit /auth/logoutpost with your refresh token, that is not the refresh token, with your refresh token, and you will receive a 204, which is a successful request, but with no content returned. And now the tokens, including the refresh token, is, invalidated, and you can no longer access it.

Now when you're working with the SDK by comparison, the SDK handles all of this for you. It will handle the storage of your tokens, it will handle the refreshing of your tokens for you as soon as you log in. However, we do also provide explicit, methods, request, refresh, here it is, and log out, a refresh function and a log out method in order to run those same commands as the API. But in most use cases, you won't need these. You log in, and as you make requests, the SDK will handle the refreshing of tokens on your behalf.

So hopefully, that helps explain the relationship between access tokens, refresh tokens, expiry time, and how you actually work with the API in order to generate and regenerate them. Thank you for joining me on Authentication Avenue, and I'll see you next time.