We'll cover the scope of this series and show some of the functionalities we'll be building throughout, which include an access token management panel, opaque access token authentication using an organization model, and building an API.

We'll get our web project cloned down. Then, we'll get it configured by first creating our database and running our migrations and seeder. Lastly, we'll get a test SMTP email inbox set up through MailTrap.

In this lesson, we'll quickly walk through the web application we've cloned down to get familiar with the data at play, how it's presented to the user, and the features at hand.

In this lesson, we'll take a high level look at our database's schema so that we have an understanding at the entities and models at play and how they relate to one another within our application.

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.

In this lesson, we'll restrict our routes to their applicable authentication guard. Ensuring our web routes can properly authorize using their role-based authorization and our API can properly authorize using our access token abilities.

In this lesson, we'll finish up our preparation work by creating a data transfer object (DTO) for our access tokens. Then, we'll define what our token abilities will be within our application's API.

In this lesson, we'll add a route to the settings portion of our application allowing the user to create an opaque access token (OAT), with the desired permissions, for the active organization.

In this lesson, we'll rig up the create access token route we created in the last lesson to a form within our Vue application. We'll also stub the overall manage access tokens card for the organization itself.

In this lesson, we'll take a step back to understand the differences between the tokens we're using, which are Opaque Access Tokens (OAT), and JSON Web Tokens (JWT). We'll discuss security, scalability, and what makes up each token.

In this lesson, we'll query all of our organization's access tokens and filter out any tokens that are expired. Then, we'll list the organization's tokens showing it's name, abilities, when it was created, and when it was last used.

In this lesson, we'll add a secondary step to our access token creation flow that will display the newly created access token to the user one time, allow them to copy the token, then drop the token completely from memory.

In this lesson, we'll add the ability for our users to revoke an access token by deleting it out of our database.

In this lesson, we'll briefly give an overview of REST and how we'll be taking a practical approach to it when building our API.

In this lesson, we'll add the first endpoint to our API. With this endpoint we'll return back the Organization's details for the provided Access Token with the request.

In this lesson, we'll take some time to get set up and get comfortable with a REST Client application. This will allow us to store our API endpoints within collections to simplify testing them as we build them out. In this series, I'll be using Hoppscotch

In this lesson, we'll implement a simple versioning mechanism for our API. Versioning allows us to safely make breaking changes without breaking our user's implementations of our API.

In this lesson, we'll begin work on our first CRUD-based API resource by adding the ability to query a list of all our organization's difficulties.

Next, we'll add a POST route and handler so that we can create difficulties from our API

In this lesson, we'll add a GET API route enabling us to get the details of a specific difficulty by providing the difficulties id via route parameter.

In this lesson, we'll add a PUT API route to handle updating our difficulties! This route will also accept in a specific difficulty id via route parameter to specify which difficulty should be updated.

The last CRUD method we need to add is the ability to delete our a difficulty by adding a DELETE API route, we'll take care of that in this lesson.

In this lesson, we'll walk through adding API endpoints for the full CRUD (create, read, update, and delete) flow for our organization's access levels.

In this lesson, we'll duplicate everything we did one more time for our organization's statuses.

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.

Our goal in this step is to add an endpoint that lists our courses. We'll then build upon this endpoint further with the ultimate goal of getting a list of paginated courses.

In this lesson, we'll add endpoints to allow creating, updating, and deleting courses from our API. We'll then use this to stub a number of test courses to give us wiggle room to play with our pagination.

In this lesson, we'll transform our courses list endpoint into a pagination endpoint. We'll check and validate our query string for a page and per page parameter that we'll then use to fetch pages of our courses.

In this lesson, we wrap up the Courses controller by adding a show method that fetches all the key info for a single course. That includes its modules and lessons, all nicely organized and ready to use in your API response.

In this lesson, we'll add a specific endpoint with the ability to patch a course's difficulty, status, or access level with a new value so our users have a way to update these without needing to send the entire course payload.

In this lesson, we'll work on nested resourceful endpoints for our course modules. We'll add endpoints to create, update, patch, and deleting modules from a specific course.