Configuring Access Token Auth on top of Session Auth
In this lesson, we'll get opaque access tokens configured within our AdonisJS application on top of the already configured session/web authentication. This will include configuring the guard and setting up the db access token provider.
- Author
- Tom Gobich
- Published
- Apr 21
- Duration
- 10m 50s
Developer, dog lover, and burrito eater. Currently teaching AdonisJS, a fully featured NodeJS framework, and running Adocasts where I post new lessons weekly. Professionally, I work with JavaScript, .Net C#, and SQL Server.
Adocasts
Burlington, KY
Get the Code
Download or explore the source code for this lesson on GitHub
Transcript
Configuring Access Token Auth on top of Session Auth
-
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.
-
Introduction
-
API Authentication
-
2.0Configuring Access Token Auth on top of Session AuthLesson 2.010m 50s
-
2.1Separation of API & Web Auth Guard ConcernsLesson 2.19m 17s
-
2.2Defining Access Token Abilities & DTOLesson 2.29m 54s
-
2.3Creating Access Tokens Part 1: AdonisJSLesson 2.310m 19s
-
2.4Creating Access Tokens Part 2: Inertia/VueLesson 2.412m 44s
-
2.5Opaque Access Tokens (OAT) vs JSON Web Tokens (JWT)Lesson 2.53m 57s
-
Listing an Organization's Access TokensLesson 2.68m 3s
-
Join The Discussion! (0 Comments)
Please sign in or sign up for free to join in on the dicussion.
Be the first to Comment!