How to handle authentication with serverless functions
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.
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:
There are many ways to protect for your functions. The list below will walk through them and the pros/cons of each.
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:
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)
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:
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
}
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:
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!
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.