Lesson Description

The "Protected Routes" Lesson is part of the full, API Design in Node.js, v5 course featured in this preview video. Here's what you'd learn in this lesson:

Scott discusses securing routes like user and habit routes with middleware that authenticates tokens and ensures only authorized users can access them. He also discusses organizing protected routes under separate routers.

Preview
Close

Transcript from the "Protected Routes" Lesson

[00:00:00]
>> Speaker 1: Let's protect some routes What are some routes that we can protect If we look, should we protect the auth routes What do you all think No So we should let anybody sign up Imagine if you couldn't sign up unless you were already signed up

[00:00:00]
That wouldn't make any sense So yeah, we don't want to protect the auth routes I mean, there might be certain situations where you would want to protect the auth routes For instance, this is an admin dashboard that we deployed only for internal company people

[00:00:00]
There are many other ways to get past that, but you probably don't want to protect public routes or public pages with authentication requirements This introduces another challenge, because we can't do it globally

[00:00:00]
If we did it globally, it would protect everything So we need to handle this on a more local level If I were to add a middleware at the top of server.ts that locks down the entire server, then no one could ever sign up

[00:00:00]
You can't do it globally because there's at least one route that should not be blocked Let's look at other routes We have an auth route and a user route These routes do nothing right now, but they will eventually

[00:00:00]
I would say we don't want anybody doing anything with a habit or a user unless they're signed in Would you all agree You really can't do anything without authentication because habits belong to users If we can't identify you, how do we know what habits to associate with you without giving access to every single habit in the database

[00:00:00]
At that point, anybody could use our database with plain text passwords like "admin123" The easiest way to handle this is to put middleware on each route, or we can add authentication at the router level

[00:00:00]
When I create the router, I can say `router.use` and add an authenticate token middleware This means everything below this route must run through this middleware first Let's test it in Postman I'll try to get all habits

[00:00:00]
If I send the request without authentication, I get a 401 unauthorized status code If I remove the authentication, I get all the habits If I add it back, I get the 401 again Now let's test finding the user

[00:00:00]
I'll grab a JWT token, go to Authorization in Postman, select "Bearer Token", and paste the token When I send the request, it passes To verify, I'll log the user associated with the token You might notice two extra headers: "iat" (initialized at) and "exp" (expires)

[00:00:00]
These are the values we added when signing the token You could use these to check token expiration or invalidate tokens from a specific time during a security breach Regarding creating a protected routes router, that comes down to route design

[00:00:00]
In a real-world example, I probably wouldn't mount auth routes under "/api" I would mount them under "/auth" and create a separate API router with user and habit routes This way, you only need to add authentication to the API router once, rather than to each individual router.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now