Your First Node API

Async

A Complete Server: Getting Started

A Complete Server: Persistence

A Complete Server: Authentication

A Complete Server: Deployment

Command Line Interfaces

Testing Node.js Applications

Bonus: Persistence with PostgreSQL

Changelog

Enter your name and email address below, then click the **"Send my free chapter"** button to get started

The Complete Guide to Building Production Apps with Node.js

Fullstack Node.js

Without authentication we can't know who is using our service, and without authorization, we can't control their actions. Our API currently has neither, and this is a problem; we don't want any random user to be able to create and delete our products.

When our API is running on our laptop, we don't need to worry about authentication. We're the only people who can make requests to the API. However, once our API is hosted on a server and is publicly accessible on the internet, we'll want to know who is making the requests. In other words, we'll want our requests to be authenticated. This is important, because without authentication, we won't be able to selectively limit access.

Once we can identify who a request is coming from, we can then make decisions on whether or not we allow access. For example, if we are making the request, we should have full access (it's our API, after all). Conversely, if it's a stranger, they should able to view products, but they should not be authorized to delete anything.

In this chapter we're going to incrementally build up our API's security model. We're going to start with a solid foundation where we can authenticate an admin user, and set up authorization for a set of private endpoints. By the end of the chapter we'll have a full database-backed user model where authenticated users will be authorized to create and view their own orders.

Currently our API has no restrictions on what a user can do. If our API were to be deployed in production, it could be a disaster. Anybody could create an delete products at any time. This is a problem, and so the first thing we need to do is to start restricting access to private endpoints.

The first step towards locking things down is to identify requests coming from an admin user. There are many ways to do this, but we'll start with a very straightforward and common approach: password and cookie.

To start, we come up with a secret password that only the admin user will know. Then we create an endpoint where the admin can log in. The admin user proves their identity by sending their secret password to the log in endpoint. If the password is correct, the API responds with a cookie. When the server receives any subsequent requests with a valid cookie, it knows the user is the admin and can allow access to private endpoints.

Here's a diagram of the admin logging in, getting the cookie, and using it to create a product:

Using this approach, we can limit access to all of our private endpoints (everything except the ones to view products). Modifying products and orders (create, edit, delete) should only be done by admins. Orders are also private for now; later in this chapter we'll allow customers to create accounts, and we can allow an authenticated customer to create and view their own orders.

To add authentication to our app we'll use the popular module 

. Passport is authentication middleware for Node.js. It's flexible, modular, and works well with 

. One of the best things about it is that 

 supports many different authentication strategies including username and password, Facebook, Twitter, and more.

 module provides the overall framework for authentication, and by using additional strategy modules, we can change how it behaves. We're going to start with username and password authentication, so we'll want to also install the 

Once we get everything hooked up, our app will have an endpoint 

 combination is correct (we'll get to how we determine this in a second), our app uses the 

 module to create a session for the user. To create a session, our app generates a unique session ID (random bytes like 

), and it uses that ID as a key to store a value that represents what we know about the user (e.g. 

). This session ID is then sent to the client as a cookie signed with a secret (if a client alters a cookie the signature won't match and it will be rejected). When the client makes subsequent requests, that cookie is sent back to the server, the server reads the session ID from the cookie (we'll install 

 for this), and the server is able to retrieve the user's session object (

). This session object allows our routes to know if each request is authenticated, and if so, who the user is.

 we can start to protect our routes. The first thing we need to do is to require these modules:

const passport = require('passport')
const Strategy = require('passport-local').Strategy
const cookieParser = require('cookie-parser')
const expressSession = require('express-session')

We then choose which secret we'll use to sign our session cookies and what our admin password will be:

const sessionSecret = process.env.SESSION_SECRET || 'mark it zero'
const adminPassword = process.env.ADMIN_PASSWORD || 'iamthewalrus'

Simple secrets and passwords are fine for development, but be sure to use more secure ones in production. It's worth reading up on the 

the dangers of a simplistic session secret

passport.use(
  new Strategy(function (username, password, cb) {
    const isAdmin = (username === 'admin') && (password === adminPassword)
    if (isAdmin) cb(null, { username: 'admin' })

    cb(null, false)
  })
)

. Similar to how we can use many different middleware functions to operate on our request and response objects as they come into 

 strategies to modify how we authenticate users. Depending on the strategy, configuration will be a little different. Ultimately, the purpose of a strategy is to take some input (e.g. a username and password) and if valid, return a user object.

, we need to provide a function that accepts 

, and a callback. That function checks the provided 

, and if valid, calls the callback with a user object. If the 

 don't match, the function calls the callback with 

 is able to make sure that the user object is stored in the session and accessible to our middleware functions and route handlers. To do this, we need to provide 

 methods for serializing the user object to and deserializing the user object from session storage. Since we're keeping things simple, we'll store the user object in our session as is, and therefore our serialize/deserialize methods will both be identity functions (they just return their arguments/inputs):

passport.serializeUser((user, cb) => cb(null, user))
passport.deserializeUser((user, cb) => cb(null, user))

We can think of session storage as a simple object with keys and values. The keys are session IDs and the values can be whatever we want. In this case, we want it to be the user object itself. If we kept a lot of user details in the database, we may just want to store the username string when we serialize, and do a database lookup to get the latest, full data when deserializing.

 to use to store user info in the session, but we need to configure 

 as middleware before it will work properly. Out of the box, 

 won't automatically parse cookies, nor will it maintain a session store for us.

app.use(cookieParser())
app.use(
  expressSession({
    secret: sessionSecret,
    resave: false,
    saveUninitialized: false
  })
)

 so we can sign the cookies. We also set 

app.use(passport.initialize())
app.use(passport.session())

 all hooked up, and our app can take advantage of it. The two things we need to do are to handle logins and to protect routes. Here's how we have 

app.post('/login', passport.authenticate('local'), (req, res) =>
  res.json({ success: true })
)

---
code: https://gitlab.com/fullstackio/books/newline-course-apps/david-guttman-fullstack-node.js-book-app/-/tree/main/code/src/05-authentication?ref_type=heads
---

# A Complete Server: Authentication

Without authentication we can't know who is using our service, and without authorization, we can't control their actions. Our API currently has neither, and this is a problem; we don't want any random user to be able to create and delete our products.

When our API is running on our laptop, we don't need to worry about authentication. We're the only people who can make requests to the API. However, once our API is hosted on a server and is publicly accessible on the internet, we'll want to know who is making the requests. In other words, we'll want our requests to be authenticated. This is important, because without authentication, we won't be able to selectively limit access.

Once we can identify who a request is coming from, we can then make decisions on whether or not we allow access. For example, if we are making the request, we should have full access (it's our API, after all). Conversely, if it's a stranger, they should able to view products, but they should not be authorized to delete anything.

In this chapter we're going to incrementally build up our API's security model. We're going to start with a solid foundation where we can authenticate an admin user, and set up authorization for a set of private endpoints. By the end of the chapter we'll have a full database-backed user model where authenticated users will be authorized to create and view their own orders.

## Private Endpoints

Currently our API has no restrictions on what a user can do. If our API were to be deployed in production, it could be a disaster. Anybody could create an delete products at any time. This is a problem, and so the first thing we need to do is to start restricting access to private endpoints.

The first step towards locking things down is to identify requests coming from an admin user. There are many ways to do this, but we'll start with a very straightforward and common approach: password and cookie.

To start, we come up with a secret password that only the admin user will know. Then we create an endpoint where the admin can log in. The admin user proves their identity by sending their secret password to the log in endpoint. If the password is correct, the API responds with a cookie. When the server receives any subsequent requests with a valid cookie, it knows the user is the admin and can allow access to private endpoints.

Here's a diagram of the admin logging in, getting the cookie, and using it to create a product:

![Our admin user authenticating with our API](https://d2uusema5elisf.cloudfront.net/books/fullstack-nodejs/images/05-authentication/01-passport-local-diagram.png)

Using this approach, we can limit access to all of our private endpoints (everything except the ones to view products). Modifying products and orders (create, edit, delete) should only be done by admins. Orders are also private for now; later in this chapter we'll allow customers to create accounts, and we can allow an authenticated customer to create and view their own orders.

## Authentication With `passport`

To add authentication to our app we'll use the popular module `passport`. Passport is authentication middleware for Node.js. It's flexible, modular, and works well with `express`. One of the best things about it is that `passport` supports many different authentication strategies including username and password, Facebook, Twitter, and more.

The `passport` module provides the overall framework for authentication, and by using additional strategy modules, we can change how it behaves. We're going to start with username and password authentication, so we'll want to also install the `passport-local` strategy module.

Once we get everything hooked up, our app will have an endpoint `/login` that accepts a POST body object with `username` and `password` properties. If the `username` and `password` combination is correct (we'll get to how we determine this in a second), our app uses the `express-session` module to create a session for the user. To create a session, our app generates a unique session ID (random bytes like `7H29Jz06P7Uh7lDyuTEMa5TNdZCyDcwM`), and it uses that ID as a key to store a value that represents what we know about the user (e.g. `{username: 'admin'}`). This session ID is then sent to the client as a cookie signed with a secret (if a client alters a cookie the signature won't match and it will be rejected). When the client makes subsequent requests, that cookie is sent back to the server, the server reads the session ID from the cookie (we'll install `cookie-parser` for this), and the server is able to retrieve the user's session object (`{username: 'admin'}`). This session object allows our routes to know if each request is authenticated, and if so, who the user is.

By making a few changes to `server.js` to use `passport` and `passport-local` we can start to protect our routes. The first thing we need to do is to require these modules:

```js
const passport = require('passport')
const Strategy = require('passport-local').Strategy
const cookieParser = require('cookie-parser')
const expressSession = require('express-session')
```

We then choose which secret we'll use to sign our session cookies and what our admin password will be:

```javascript { actualFilename=code/src/05-authentication/01/server.js endLine=13 startLine=12 statedFilename=05-authentication/01/server.js url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-nodejs-book/fullstack-nodejs/code/src/05-authentication/01/server.js#L12 }
const sessionSecret = process.env.SESSION_SECRET || 'mark it zero'
const adminPassword = process.env.ADMIN_PASSWORD || 'iamthewalrus'
```

I> Simple secrets and passwords are fine for development, but be sure to use more secure ones in production. It's worth reading up on the [the dangers of a simplistic session secret](https://martinfowler.com/articles/session-secret.html) and related prevention techniques.

Next, we configure `passport` to use our `passport-local` strategy:

```javascript { actualFilename=code/src/05-authentication/01/server.js endLine=22 startLine=15 statedFilename=05-authentication/01/server.js url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-nodejs-book/fullstack-nodejs/code/src/05-authentication/01/server.js#L15 }
passport.use(
  new Strategy(function (username, password, cb) {
    const isAdmin = (username === 'admin') && (password === adminPassword)
    if (isAdmin) cb(null, { username: 'admin' })

    cb(null, false)
  })
)
```

We can think of a `passport` strategy like `passport-local` as middleware for `passport`. Similar to how we can use many different middleware functions to operate on our request and response objects as they come into `express`, we can use many different `passport` strategies to modify how we authenticate users. Depending on the strategy, configuration will be a little different. Ultimately, the purpose of a strategy is to take some input (e.g. a username and password) and if valid, return a user object.

![How \`passport\` uses strategies](https://d2uusema5elisf.cloudfront.net/books/fullstack-nodejs/images/05-authentication/01-passport-strategies.png)

In the case of `passport-local`, we need to provide a function that accepts `username`, `passport`, and a callback. That function checks the provided `username` and `password`, and if valid, calls the callback with a user object. If the `username` and `password` don't match, the function calls the callback with `false` instead of the user object.

After `passport-local` does its thing, `passport` can handle the rest. `passport` is able to make sure that the user object is stored in the session and accessible to our middleware functions and route handlers. To do this, we need to provide `passport` methods for serializing the user object to and deserializing the user object from session storage. Since we're keeping things simple, we'll store the user object in our session as is, and therefore our serialize/deserialize methods will both be identity functions (they just return their arguments/inputs):

```javascript { actualFilename=code/src/05-authentication/01/server.js endLine=25 startLine=24 statedFilename=05-authentication/01/server.js url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-nodejs-book/fullstack-nodejs/code/src/05-authentication/01/server.js#L24 }
passport.serializeUser((user, cb) => cb(null, user))
passport.deserializeUser((user, cb) => cb(null, user))
```

I> We can think of session storage as a simple object with keys and values. The keys are session IDs and the values can be whatever we want. In this case, we want it to be the user object itself. If we kept a lot of user details in the database, we may just want to store the username string when we serialize, and do a database lookup to get the latest, full data when deserializing.

We've now configured `passport` to use to store user info in the session, but we need to configure `express` to use `cookie-parser` and `express-session` as middleware before it will work properly. Out of the box, `express` won't automatically parse cookies, nor will it maintain a session store for us.

```javascript { actualFilename=code/src/05-authentication/01/server.js endLine=38 startLine=31 statedFilename=05-authentication/01/server.js url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-nodejs-book/fullstack-nodejs/code/src/05-authentication/01/server.js#L31 }
app.use(cookieParser())
app.use(
  expressSession({
    secret: sessionSecret,
    resave: false,
    saveUninitialized: false
  })
)
```

Note that when configuring `expressSession`, we provide `sessionSecret` so we can sign the cookies. We also set [`resave`](https://github.com/expressjs/session#resave) and [`saveUninitialized`](https://github.com/expressjs/session#saveuninitialized) to `false` as both are recommended by `express-session` documentation.

Next up, we tell `express` to use `passport` as middleware by using its `initialize()` and `session()` methods:

```javascript { actualFilename=code/src/05-authentication/01/server.js endLine=40 startLine=39 statedFilename=05-authentication/01/server.js url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-nodejs-book/fullstack-nodejs/code/src/05-authentication/01/server.js#L39 }
app.use(passport.initialize())
app.use(passport.session())
```

We've now got `passport` all hooked up, and our app can take advantage of it. The two things we need to do are to handle logins and to protect routes. Here's how we have `passport` handle the login:

```javascript { actualFilename=code/src/05-authentication/01/server.js endLine=44 startLine=42 statedFilename=05-authentication/01/server.js url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-nodejs-book/fullstack-nodejs/code/src/05-authentication/01/server.js#L42 }
app.post('/login', passport.authenticate('local'), (req, res) =>
  res.json({ success: true })
)
```