So as made evident by the fact that we were able to successfully register a brand new user inside of our application a couple of lessons ago, we already have web authentication set up

and ready to go inside of this application. So what we need to do is add API, opaque access token authentication on top of it.

That's what we'll use to authenticate against our organization inside of our API that we'll be building throughout this series. So similarly to how we

reconfigured our database inside of this application, we're going to be redoing that with our authentication.

Really all that we want is a new AuthConfig generated out, so that we also have the API guard defined inside of our AuthConfiguration.

Now, we don't want to get rid of the web guard here, so we want to merge what we currently have with the new configuration that we'll get set up here in a moment.

But the configuration step won't give us a new Auth file if it already exists inside of our file tree. So in order to get a new Auth file,

let's right-click our Auth and just rename it here, adding the suffix -web or something, and then we'll be able to merge this into the new one, and then we'll be able to delete this file. So now that we have that set,

let's jump back into our terminal here and reconfigure Auth. So node ace configure@adonisjs/auth, give that a run, and it's going to ask us

which guard we want to use. Now, session is the web guard that we already have set up, so that's not the one that we want. What we want is the opaque access tokens, which is what we'll use to authenticate

against our organization with our API. So give that a select, and you should see that this generated out a couple of files. First and foremost, we have a new Auth configuration.

It also updated our adonisrc.ts file, gave us a migration that we'll be deleting here because we already have a user migration. Our API is also going to be going against our organization

and not our user. So we definitely don't need that migration, but the second one we do want to keep. This is the table that our access tokens are actually going to store inside of.

So we definitely want that one there. And then it skipped over giving us a new user model since that already exists, as well as an auth middleware

since that exists as well, and it updated our kernel.ts. So with all those in place, let's go ahead and jump back into our text editor here, and let's start by joining our web guard

together with our new Auth configuration for our API guard. So if we just drag the new Auth configuration over here onto the left-hand side,

keep the old one that we had for our web on the right, you can see that really the only difference here is the guards object itself. Our old configuration has the guard for web

and our new configuration has the guard for our API. So all we need to do here is copy the web guard

from our auth web file over into our new Auth configuration. We can go ahead and move our cursor to one of the red squigglies, hit command dot to get the quick fix options.

And just select add all missing imports. Then let's go ahead and switch our default guard back to web

so that if we omit specifying a guard with the authenticator, it will default to using the web guard. Since the web portion of this application predates,

the API portion we'll be adding throughout the series. That's just going to make sure that everything works properly for what's already there. With that set, we're now done with our auth web configuration file.

So we can close that out, right-click it, delete and move it to the trash. Now, as I've said a few times, our API is going to authenticate against our organization, not our user.

So we don't want this model to point towards our user here, but rather we want it to point towards our organization model.

We do however, still want to maintain our web guard pointing towards our user there. So the main difference here is whenever we log in

with the web guard, the authenticated user that we're going to get back is an actual user record of type user model. Whenever we authenticate now with our API,

it will instead be an organization record of type organization model. So there is a difference there, and it's going to vary depending on what auth guard

it is that we're actually using. And whenever we fall back to that default guard, it's actually not going to be able to differentiate between those two different types on which one it should use.

So it's going to give us a union of those two types. Before we dive into that a little bit further, let's fix the red squiggly here for our organization itself.

This is red squiggly because it doesn't implement the access token provider that actually enables us to create, delete, and manage our access tokens for our organization.

So we need to go do that next. And that's going to be within our app, models, organization model. Now the user model that it skipped over generating for us

would have had this already, but what we now need to do is implement it for our organization since we don't want it on our user and it skipped over creating our user.

So at the top of our organization model here, let's add in a static access tokens property

equal to DB access tokens provider. Off of this class, we want to call for model and pass in our organization model.

If you want a basic implementation, that's all that you need, but let's go ahead and configure this a little bit further. If we actually dig into for model, we can take a look at those types.

So I just command clicked on that type. And if we scroll on over here, we should see our options. Now this is omitting tokenable model. So keep that in mind. But if we take a look at the types here,

we have tokenable model, which is being omitted, table expires in token secret length type and prefix. Prefix allows us to specify any string that we want

to actually be prefixed onto the token itself. So if we wanted all of our generated tokens to start with API, we could add that as a prefix. And then all of our generated tokens

will then start with API as we've defined. Type is a way for us to differentiate between the access tokens if our application needed multiple access tokens. In our case, it doesn't,

but if we were to add access tokens for anything else down the road, in addition to our organization, that would give us a way to have our organization access tokens

in addition to whatever the other purpose is for them. Token secret length is the actual secret length of the token. Expires in is the duration

that the token itself will be valid for. So you might have it expire in 24 hours, 48 hours, two hours, you could set that there.

And then table is the table that the access token itself should target. So those are all of the options that we have there. Although we don't need them, we're gonna go ahead and fill a couple of them out.

So for our organization, I'm gonna give these tokens a unique type called API token. And then I'm also going to go ahead and prefix all of my tokens with API underscore.

So this will specify that all of the tokens created for our organization with this access tokens here is specifically for purpose with our API. And then we're just prefixing

the actual token itself with API to give us a visual representation of what that token's for. And then the expiry, if we don't specify an expiry within here,

we can specify it on a per token basis whenever we create the token itself. But if it's omitted in both places, then the token will just never expire,

which is what we actually want for this application since the user has a dashboard where they can manage their tokens themselves. So we're good to go there. Let's go take a look at those migrations next.

So we'll dig into our database migrations. These two green files are the ones that were created for us. As stated earlier, we actually wanna get rid of our user one because we already have a user migration up here

that adds everything in for our user itself. So we'll just right click on that one, delete it and move that to the trash. The second one that was generated for us

is our auth access tokens table. And this has everything almost exactly as we need it. First and foremost,

we need to change the foreign key for the tokenable ID. Tokenable ID is the actual ID for the record the token was created for. So in this case,

it's going to be our organization ID that the token is actually for. So we don't want it to reference our users table, but rather the ID inside of our organizations table.

In addition to that, since this is bound to our organization, let's rename the table itself to match with the other namings that we have on our organization's API access tokens

by renaming this from auth access token to instead API access tokens. Since we've now switched this default name, we also want to reference that

inside of our organization access tokens configuration as well by adding table API access tokens to make sure that both of those match.

With that set, we can go ahead and run this migration. So let's jump back into our terminal and do node ace migration run. And there we go. Okay, we can clear our terminal out there.

Then briefly before we run this lesson out, let's quickly discuss the actual authenticator types that I touched upon a moment ago.

So let's do a quick search within our application here for auth.user. All right, looks like we have this within our organization controller right here.

Whenever we reference auth.user, that's going to use the default guard from our auth configuration, which I have right here. So I'm just going to drag this over to the right hand side so that we have those side by side.

So our default guard is web, and that's the one that this will use. But remember, I mentioned that it's going to be a union type since whenever we use the default guard,

TypeScript's not going to be able to discern which model we're actually using between these two guards. So if we take a look at the type of our auth.user,

you'll see that it's user or organization, and then our access token bound on top of it, which is added on by the tokens guard directly from our API auth configuration.

Since it cannot discern between those types and instead gives us a union, the instances where we're just doing auth.user aren't going to work where we need it

to literally be type of user, which we have right here, hence the red squiggly. So to fix that, all we need to do is specify which guard it is that we actually want to use

in this instance, and then that will give us the correct type for our user. So if we do .use, that's how we can specify which guard it is that we want to use.

In here, you'll see that we have as options, API, or web. Here, we want to use the web guard. And now those red squigglies go away because our user is actually a type of user

as we see right here. So we're now properly getting back just a type of user, and we've dropped the type of organization by specifying that we want to use the web guard specifically. So let's give that a save.

We can close out our auth configuration now, and let's bring back up that search panel because we had one more occurrence of that. We want to do the exact same thing here.

So .use and specify that that's using the web guard. Everywhere else should be a-okay. We can do a search real quick for auth.use, and you can see in all of these other instances,

we're already using the web guard specifically. So those are all going to be a-okay. All right, jump back into our file explorer there. So now that we have those instances fixed

and with that said, we're now good to move onward.