Skip to content Menu

serverless-auth-strategies

How to protected & scoped down functions to specific users

Readme

Serverless Auth strategies

How do we keep certain functions protected & scoped down to specific users (i.e. admin/paid users)?

This will walk through the different strategies available for authorizing access to your functions.

The code in this repo covers primarily AWS lambda functions but these strategies can apply to any FAAS provider.

Pick your auth provider

There are a boatload of services that provide out of the box auth for your app. It's recommended to use one of these mainly because it's quite easy to mess up some piece of the security chain rolling your own auth.

Some options out there include:

Choose a strategy

There are many ways to protect for your functions. The list below will walk through them and the pros/cons of each.

1. Inline auth checking

Inlined function authentication happens inside your function code

We do a check on the auth headers or the body of the request to verify the user is okay to access the function.

const checkAuth = require('./utils/auth')

exports.handler = (event, context, callback) => {
  // Use the event data auth header to verify
  checkAuth(event).then((user) => {
    console.log('user', user)
    // Do stuff
    return callback(null, {
      statusCode: 200,
      body: JSON.stringify({
        data: true
      })
    })
  }).catch((error) => {
    console.log('error', error)
    // return error back to app
    return callback(null, {
      statusCode: 401,
      body: JSON.stringify({
        error: error.message,
      })
    })
  })
}

Benefits of this approach:

Drawbacks of this approach:

2. Middleware

Next up we have the middleware approach to authentication. This is still happening at the code level but now your logic that verifies the user is allowed to access the function is abstracted up a level into reusable middleware.

MiddyJs does a great job at enabling a sane middleware approach in lambda functions

const middy = require('middy')
const authMiddleware = require('./utils/middleware')

const protectedFunction = (event, context, callback) => {
  // Do my custom stuff
  console.log('⊂◉‿◉つ This is a protected function')

  return callback(null, {
    statusCode: 200,
    body: JSON.stringify({
      data: 'auth true'
    })
  })
}

exports.handler = middy(protectedFunction).use(authMiddleware())

Our middy middleware looks like this:

const checkAuth = require('./auth')

module.exports = function authMiddleware(config) {
  return ({
    before: (handler, next) => {
      checkAuth(handler.event).then((user) => {
        console.log('user', user)
        // set user data on event
        handler.event.user = user
        // We have the user, trigger next middleware
        return next()
      }).catch((error) => {
        console.log('error', error)
        return handler.callback(null, {
          statusCode: 401,
          body: JSON.stringify({
            error: error.message
          })
        })
      })
    }
  })
}

You can also instrument this yourself as seen in the movie demo(link here)

3. "Legacy" middleware

This middleware approach is using a familiar web framework with express PR flask and using their an auth module from their ecosystem.

In the case of express, you can use passport strategies in a lambda function

const express = require('express')
const cors = require('cors')
const bodyParser = require('body-parser')
const compression = require('compression')
const morgan = require('morgan')
const serverless = require('serverless-http')
const customLogger = require('./utils/logger')
const auth0CheckAuth = require('./utils/auth0')

/* initialize express */
const app = express()
const router = express.Router()

/*  gzip responses */
router.use(compression())

/* Setup protected routes */
router.get('/', auth0CheckAuth, (req, res) => {
  res.json({
    super: 'Secret stuff here'
  })
})

/* Attach request logger for AWS */
app.use(morgan(customLogger))

/* Attach routes to express instance */
const functionName = 'express'
const routerBasePath = (process.env.NODE_ENV === 'dev') ? `/${functionName}` : `/.netlify/functions/${functionName}/`
app.use(routerBasePath, router)

/* Apply express middlewares */
router.use(cors())
router.use(bodyParser.json())
router.use(bodyParser.urlencoded({ extended: true }))

/* Export lambda ready express app */
exports.handler = serverless(app)

Benefits of this approach:

Cons to this approach:

4. Auth decorators

Similar to auth middleware, decorators wrap the function code and return another function

Some developers prefer this more explicit approach as opposed to middleware

@AuthDecorator // <-- ref to auth wrapper function
function protectedFunction(event, context, callback) {
  // protected logic
}

5. Custom authorizers

Custom authorizers are a feature from AWS API gateway.

They are essentially another function that checks if the user is authorized to access the next function. If the auth checks out, then request then invokes the next lambda function.

Benefits to this approach:

Drawbacks to this approach:

6. Proxy level

Similar to custom authorizers, you can verify requests at the proxy level.

This works in Netlify by checking for an http only secure cookie.

If the nf_jwt cookie exists in the request headers, Netlify will deserialize it and pass it into the context object of the lambda function

If the cookie is no valid, you can send the request to a non authorized endpoint (http code X)

# If visitor has 'nf_jwt' with role set, let them see site.
/.netlify/functions/protected-function /.netlify/functions/protected-function 200! Role=*

# Else, redirect them to login portal site.
/.netlify/functions/protected-function /not-allowed 401!

7. Single use access token

Some third party services like AWS, and faunaDB make it possible to use single use tokens in the client to invoke their APIs directly.

This means no function middleman to make the API calls to other services.

Benefits to this approach:

Cons to this approach:

For more information on this approach see AWS Cognito docs.