API Authorization Checks

In This Lesson

We'll implement our API Authorization checks across all the API controller methods we've implemented thus far. We'll then create a specific access token for each operation (read, create, update, and delete) to ensure everything is working.

Created by: @tomgobich
Published: 1 year ago

Join the Discussion 2 comments

@aaron-ford
10 months ago

Can we clean up the error responses and not have it return the frames array? Just message, name, status?

1
1. Responding to aaron-ford
  @tomgobich
  10 months ago
  
  Ah - it didn't occur to me, but I should've noted this in the lesson. Similar to the HTML Youch page, the frames here is only included in when debugging. It should be omitted when your application is running on production. I believe only message is included in production.
  If you do wish to customize the exception, though, you can do that within the exception's handle method. This can be done globally within the handle.ts method or any individual custom exceptions. You can also narrow in on a specific exception within handle.ts as well:
  /** * The method is used for handling errors and returning * response to the client */ async handle(error: unknown, ctx: HttpContext) { if (error instanceof errors.E_HTTP_EXCEPTION) { return ctx.response.status(error.status).send({ message: 'Oh no!' }) } return super.handle(error, ctx) }
  
  Copied!
  
  0

Transcript

Now, currently the token that we have been working with thus far actually has unfettered access to all of our API operations.
If we were to dig back into our organization access tokens panel, this right here is the one that we're working with, which has permissions to read, create, update, and delete.
However, as we can see below, we have the ability to create just tokens that can read, just tokens that can create, so on and so forth.
And one thing we've yet to account for inside of our API is ensuring that the token that is making the request actually has the permission to perform the operation,
AKA authorizing the actual request. Now, in our setup stage, we actually created an ability to authorize our token.
And within here, we have read, create, update, and delete, which checks to see whether or not the current access token for the request allows that particular action.
If it doesn't, then we throw a forbidden exception, preventing the operation from taking place. So what we need to do is implement this inside of our API controllers.
And we actually have something similar implemented inside of some of our web-based controllers as well. So if we dig into the organizations controller, directly nested within our controllers directory,
so the main organizations controller, and scroll on down, we should see that we have an update method within here that gets the user's role within the organization,
and then checks to see whether or not that role can perform an edit operation, and then forbids the operation if it cannot, prior to the operation actually taking place.
So that's the same premise that we need to take with our API, the only difference is, we'll use the API token to determine whether or not the operation is authorized rather than the role of the user.
Since we're working at the organization level within our API rather than the user level. So let's go ahead and dig into our organizations controller first, because what this does is reads.
So we need to authorize reading from this endpoint. So let's go ahead and give ourselves a couple of new lines. And since our authorized token action
directly throws a forbidden exception within here, we don't wanna do an if check, we just merely want to call the appropriate action to determine whether or not it's authorized.
And if it's not, then we'll throw an exception, which will be caught by our exception handler, and will prevent further operations within our controller from actually executing.
So all's we need to do is authorize token and import that action, call the read method, since we're trying to read within this controller, and pass our organization in.
That will ensure that the organization token that we're working with has the ability to read from our API. And if it does, it will continue onward and populate our difficulty statuses
and access levels onto our organization, then kick back the organization itself. And if it doesn't, as we saw, we'll get that forbidden exception. Now, we don't wanna perform this authorization check inside of our middleware
that's actually querying the organization, because that organization is also needed, as we saw, for our update, create, and delete operations as well.
So we do need it if the token is able to do any one of those, so we're not gonna prevent that with our read here. We'll specifically prevent it just within the controller handlers.
So we can give that a save, and let's continue on through before we test any of these, and populate all of the others. So we also have our difficulties controller, which has various operations.
So we'll just walk through it and do the exact same thing. So we'll authorize token, and this one is reading, and pass it in the organization. Then we have our store.
So we'll authorize token dot create, and pass the organization in there as well. Let's give ourselves a line break for that one. Then we have show, which again is going to read.
So authorize token, read organization, and update. So authorize token, and we should have an update one. There we go.
Organization, and give ourselves a line break. And then finally we have delete. So authorize token dot delete, and pass the organization in there as well. Cool.
I'm going to go ahead and just drill through the access levels and status controllers for this as well. So authorization token read, organization,
give that a copy, paste it in the show, door, authorization token create, organization, key. Have our updates just like so,
and delete, authorization token delete, organization, and good. Then finally our statuses. So let's scroll on up to the top again. And I believe I still have the read copied.
So we'll get that. Command dot to import that, paste that into show as well. And then we have authorization token create again,
the organization, and update. There we go. And finally delete.
So authorization token delete, organization, and good. Perfect. So now that we have all of the authorization checks added into all of our API controllers,
let's go ahead and dig back into our browser and let's create a new development read, development create, development update, development delete token.
So we'll add an access token, development read. I'm just going to go ahead and give development there a copy, let's create that one. Oh, right, nevermind. We need to copy our token as well.
Jump back into Hopscotch and let's go into our environments, our development environments, and over to our secrets. And let's add a new one for token read
and then paste that secret value in. Let's see, I think we also appended bearer onto that as well. So let's make sure that we have bearer appended onto that too. Okay, before we go ahead and save that,
let's run through all of the others as well. So let's dig back into our browser. We have our read one, do update or do create next,
untick read and create gets a tick there. Let's create that one, copy the token, back over to Hopscotch, add another token,
underscore create bearer and paste in the token. Let me go ahead and show it so that I can confirm that I got that right. All right, then we need updates.
So untick create, tick update, create that, copy it, back over to Hopscotch, token, underscore updates, bearer, space, paste. Let's show it to make sure I got that right again.
Okay, close that. And finally, we need one for deleting. So development, delete, and tick delete there, copy our token.
And one more time, token, underscore, delete, bearer, space, and paste the token in. Okay, perfect. Let's give all of those a save and let's test them out.
So let's jump back over into our collections. Now, remember, we set up the accept and authorization headers within our API collection and it cascades through to all of these sub collections within there.
However, a nice thing that we can do is override that by adding the header directly into the header list for the specific request.
So for example, if we were to add an authorization into this one, the authorization header goes ahead and disappears from this particular request
from our API collection. Meaning that we can now dig into the value and reach for say our token and let's do read, which certainly does not have the ability to delete.
Test this out, send that off. And sure enough, we get a forbidden exception. The provided token does not have the permission to delete in this organization.
So that's working perfectly fine. And then if we were to go ahead and switch that back to the one that does have specific abilities to delete, which is our token delete variable, send that off.
We're gonna get a row not found, which is a different error, but it means that our request was indeed authorized. Of course, we're getting the 404 there because we've already deleted the ID of 11.
So awesome, everything's working good for our delete. We can go ahead and remove that authorization token and the one from our API collection comes back. Let's dig back into our status collections.
We've tested our destroy. Let's walk through the full CRUD flow here just to make sure everything with these is working okay. So we'll add an authorization header in here.
Let's reach for our token. This is update that we're on. So let's do maybe create, there we go. Should again get a forbidden exception, which we do.
And then let's jump back over to here and do updates. We've already got our body payload in there. So that should send off a okay, and it does, perfect. Let's get rid of that header.
Jump now to our get a specific status. So this one is the read. So let's add in our authorization header and then token underscore,
maybe let's try delete for this one. If we send that off, we get a forbidden exception as expected. If we switch that to read now, send that off,
we get back our record and a 200 response. Awesome, remove that token yet again and jump now over to our create, which is our store.
And again, add in the authorization header, token, let's try update for this one. This one only has the ability to update. So it should not be able to create,
send that off and there's our forbidden exception again, switch that back to create, send that off and we get back a brand new record with an ID of 13.
Awesome, lastly, we have our getting a list. So this one is again, a get. This one we did not, looks like we still already have a specific token within here.
So let's just go ahead and add create onto that token, send it off, there's our forbidden exception
and let's now go ahead and test just the one that can read, send that off and perfect, we get back our list of statuses. We can go ahead and remove the token from that one
and the one from the collection will pop up there. Cool, so now we have authorization out of the way and we're done with our organization's resources, which is our difficulty statuses and access levels,
which gives us play to now move on to more interesting things like our courses, modules and lessons.

Adding an API to an AdonisJS Web App

43 Lessons

5h 31m

Introduction

API Authentication

Getting Started with APIs

Organization Resources

Courses

Searching

Rate Limiting

Rate Limiting an Organization's HTTP Requests

13m 59s

Stop losing your best ideas!

Use our integrated note feature to capture and organize your key insights. Take a note at any timestamp and jump instantly back to that moment in the video with a single click.