Let's take a look at the database so that we can look at the token that we created in the previous episode. So we used the User with an email of jcoss@example.com. It has an ID of 1. And if we look at the personal access tokens, we can see that there is one record. The tokenable ID has a value of 1. This is the relationship between our tokens table and the users table. So this means that this is a token for the User with an ID of 1. We have the name, the token, abilities, last used at, and then we have the expires column. Now notice that it is null.

We have the name, the token, abilities, last used at, and then we have the expires column. Now notice that it is null. And by default, any token that we create with Sanctum never expires. And we can go back and forth as to whether or not that's a good idea. But there are some times when you want a token to never expire. There are other times when you want tokens to expire. We're not going to hash that out because it's really done on a case-by-case basis. What we do want to do, however, is revoke a token that is essentially going to sign the user out and, well, we'll just implement that functionality. So let's go to our AuthController, and we are going to add a method called logout.

the User out and, well, we'll just implement that functionality. So let's go to our AuthController, and we are going to add a method called logout. We need the request, and there are three different ways that we can revoke a token. The first is to use a method called tokens. This is a gateway to, well, all of the tokens for the given User. And we can call simply delete, and that is going to delete all of the tokens for that User. For signing out, we don't want to take this approach because what if the User has a token that doesn't expire? It might be for a service or some kind of agent application.

that doesn't expire? It might be for a service or some kind of agent application. If we delete that token, we've essentially broken their stuff, and they're not going to be happy with us. So this is not a good option for this case. Now, we could provide the ability for a User to revoke all of their tokens if they wanted to do that. There are some very good reasons why we would want to do that. But for our purpose in this case, no, we don't want this. Now, similarly, there's the ability to delete a token based upon its ID.

But for our purpose in this case, no, we don't want this. Now, similarly, there's the ability to delete a token based upon its ID. So we would use the tokens method, call where, and then if we had the ID of a token, we could use that and then simply delete it. And that's okay, except for our case, we don't necessarily have that ID. We do, however, have the ability to get the current access token that was used to authenticate this request. And in that case, yes, we definitely want to delete that token. So this is how we are going to sign the user out. We will call currentAccessToken, we will delete that, and then that revokes that token.

So this is how we are going to sign the User out. We will call currentAccessToken, we will delete that, and then that revokes that token. But we do need to return something here. So let's just say okay. And I don't necessarily think we need a message. But if we ever decide that we do, then we can add one, although, oh, we added the ability to pass in data, didn't we? And we need to do something. But in this case, we don't need that. So let's go to our ApiResponsesTrait, and let's just have a default value for data.

But in this case, we don't need that. So let's go to our APIResponsesTrait, and let's just have a default value for data. We'll just set that to an array. We might want to do something different, like use null, but for this, it should be okay. If we ever need to change it, we can. Okay, so that should log the user out. We need to set up a route for this. So let's go to our api.php file, and we want to use the auth:sanctum middleware. Because if the user isn't authenticated, there really is no reason for them to be hitting this endpoint.

Because if the user isn't authenticated, there really is no reason for them to be hitting this endpoint. So we want to be sure that the user is authenticated with our auth sanctum middleware. Then let's make this a POST request for the logout endpoint. We need to call the logout method on our AuthController. And that should be that. So now we just need to make that request. Let's go to Postman. Under authentication, let's create a new request. Let's rename it to logout request, and we need to change this to a POST request.

Under authentication, let's create a new Request. Let's rename it to LogoutRequest, and we need to change this to a POST request. The URL is for the logout endpoint. We do need to set the authorization header for our bearer token. And hey, it automatically imported that value, so that's great. And this gives us the option to set as a variable. So let's do that. That way we don't have to go to all of our other requests to change the token. So let's just call this bearer, for the lack of a better word. And let's use the global scope that's going to set that variable.

So let's just call this bearer, for the lack of a better word. And let's use the global scope that's going to set that variable. So we now have this bearer variable that we could use every place else. And let's set the accept header to application/json. So that should be everything, I think we're ready to go. So let's save it, let's send it, we should get a response. And great, there's no message, but we get that status of 200. So that's perfect, let's take a look at the database. And let's refresh this, and sure enough, that token is now gone. So if we try to make a request for our tickets,

And let's refresh this, and sure enough, that token is now gone. So if we try to make a request for our tickets, let's change our token here to use our bearer variable. If we send this, it should say unauthenticated. So that's perfect, everything is great. Now let's talk about expiration, because I think it would be a good idea for our tokens to expire after a certain time. So whenever we create our token and we give it a name, we can also give it the abilities that that token will have. And then we can also set the expiration point.

we can also give it the abilities that that token will have. And then we can also set the expiration point. So let's do this, we will set the abilities to be all for the time being. We will eventually have our own abilities here. But then we will set an expiration of, let's say, a month. That's probably a little bit too long for this case. But the idea here is that clients are going to be hitting this login endpoint. So for a client, we would want some kind of expiration. I would probably prefer a day. If that, maybe 30 minutes, depending upon what kind of application this was.

I would probably prefer a day. If that, maybe 30 minutes, depending upon what kind of application this was. But for our purposes, we don't want to have to keep signing in and everything. So we'll just stick it to a month, so that we can go back to Postman. We can log in, so let's send that request. That's going to give us a new token, but we need to update our bearer variable. So let's go to Environments, Globals, and then we have Bearer there. We can set the initial value and the current value to our new value. Let's save that, go back to Collections. Let's get our tickets to make sure that that works.

Let's save that, go back to Collections. Let's get our tickets to make sure that that works. Sure enough, it does. Let's take a look at the database. Whenever we refresh, we now see that we have this expires_at column with a value. So that's perfect. And if we wanted to set a default, we could go to our Sanctum configuration file. That is sanctum.php. And down kind of halfway in the file, there's this expiration. Now, it's important to read here because it says that this will override any values.

And down kind of halfway in the file, there's this expiration. Now, it's important to read here because it says that this will override any values set in the tokens expires at attribute. But whatever value we set, it of course needs to be numeric. It is the number of minutes for the expiration. So if we wanted to set it to 30 minutes, then we would just use 30. If we wanted an hour, that would of course be 60. If we wanted a day, we could multiply that by 24, and then by 30 for 30 days. But once again, this will override any values. And so now that we have the ability to both sign in and sign out,

But once again, this will override any values. And so now that we have the ability to both sign in and sign out, let's start focusing on working with our data.