# Protect your Function with JSON Web Token

> \[!WARNING]
>
> This example uses headers and cookies, which are only accessible when your Function is running `@twilio/runtime-handler` version `1.2.0` or later. Consult the [Runtime Handler guide](/docs/serverless/functions-assets/handler) to learn more about the latest version and how to update.

When protecting your public Functions and any sensitive data that they can expose, from unwanted requests and bad actors, it is important to consider some form of [authentication](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication) to validate that only intended users are making requests. In this example, we'll be covering one of the most common forms of authentication: [Bearer Authentication](https://datatracker.ietf.org/doc/html/rfc6750#section-2.1) using [JSON Web Token (JWT)](https://jwt.io/).

If you want to learn an alternative approach, you can also see this example of [using Basic Auth](/docs/serverless/functions-assets/quickstart/basic-auth).

Let's create a Function that will only accept requests with valid JWTs, and reject all other traffic.

## Create and host a Function

In order to run any of the following examples, you will first need to create a Function into which you can paste the example code. You can create a Function using the Twilio Console or the [Serverless Toolkit](/docs/labs/serverless-toolkit) as explained below:

## Console

If you prefer a UI-driven approach, creating and deploying a Function can be done entirely using the Twilio Console and the following steps:

1. Log in to the Twilio Console and navigate to the [Functions tab](https://www.twilio.com/console/functions/overview). If you need an account, you can sign up for a free Twilio account [here](https://www.twilio.com/try-twilio)!
2. Functions are contained within **Services**. Create a **[Service](/docs/serverless/functions-assets/functions/create-service)** by clicking the **[Create Service](https://www.twilio.com/console/functions/overview/services)** button and providing a name such as *test-function*.
3. Once you've been redirected to the new Service, click the **Add +** button and select **Add Function** from the dropdown.
4. This will create a new [Protected](/docs/serverless/functions-assets/visibility) Function for you with the option to rename it. The name of the file will be path it is accessed from.
5. Copy any one of the example code snippets from this page that you want to experiment with, and paste the code into your newly created Function. You can quickly switch examples by using the dropdown menu of the code rail.
6. Click **Save** to save your Function's contents.
7. Click **Deploy All** to build and deploy the Function. After a short delay, your Function will be accessible from: `https://<service-name>-<random-characters>-<optional-domain-suffix>.twil.io/<function-path>`\
   For example: `test-function-3548.twil.io/hello-world`.

## Serverless Toolkit

The [Serverless Toolkit](/docs/labs/serverless-toolkit) enables you with local development, project deployment, and other functionality via the [Twilio CLI](/docs/twilio-cli/quickstart). To get up and running with these examples using Serverless Toolkit, follow this process:

1. From the CLI, run `twilio serverless:init <your-service-name> --empty` to bootstrap your local environment.
2. Navigate into your new project directory using `cd <your-service-name>`
3. In the `/functions` directory, create a new JavaScript file that is named respective to the purpose of the Function. For example, `sms-reply.protected.js` for a [Protected](/docs/serverless/functions-assets/visibility) Function intended to handle incoming SMS.
4. Populate the file using the code example of your choice and save. **Note** A Function can only export a single handler. You will want to create separate files if you want to run and/or deploy multiple examples at once.

Once your Function(s) code is written and saved, you can test it either by running it locally (and optionally tunneling requests to it via a tool like [ngrok](https://ngrok.com/)), or by deploying the Function and executing against the deployed url(s).

### Run your Function in local development

Run `twilio serverless:start` from your CLI to start the project locally. The Function(s) in your project will be accessible from `http://localhost:3000/sms-reply`

* If you want to test a Function as a [Twilio webhook](/docs/usage/webhooks/getting-started-twilio-webhooks), run: `twilio phone-numbers:update <your Twilio phone number> --sms-url "http://localhost:3000/sms-reply"`\
  This will automatically generate an ngrok tunnel from Twilio to your locally running Function, so you can start sending texts to it. You can apply the same process but with the `voice-url` flag instead if you want to test with [Twilio Voice](/docs/voice).
* If your code does *not* connect to Twilio Voice/Messages as a webhook, you can start your dev server and start an ngrok tunnel in the same command with the `ngrok` flag. For example: `twilio serverless:start --ngrok=""`

### Deploy your Function

To deploy your Function and have access to live url(s), run `twilio serverless:deploy` from your CLI. This will deploy your Function(s) to Twilio under a development environment by default, where they can be accessed from:

`https://<service-name>-<random-characters>-dev.twil.io/<function-path>`

For example: `https://incoming-sms-examples-3421-dev.twil.io/sms-reply`

Your Function is now ready to be invoked by HTTP requests, set as the [webhook](/docs/usage/webhooks/getting-started-twilio-webhooks) of a Twilio phone number, invoked by a Twilio Studio **[Run Function Widget](/docs/studio/widget-library/run-function)**, and more!

## Configure your Function to require Bearer Authentication

First, create a new `auth` [Service](/docs/serverless/functions-assets/functions/create-service) and add two **Public** Functions using the directions above. These will be named:

* `/jwt`
* `/bearer`

Replace the default contents of each Function with the JWT generation code (Generate a JSON Web Token for Function Authentication) for `/jwt`, and the JWT validation snippet (Authenticate Function requests using Bearer Authorization and JWT) for `/bearer` respectively. Save both Functions once they contain the new code.

```js title="Generate a JSON Web Token for Function Authentication"
const jwt = require('jsonwebtoken');

// Hardcoded credentials for this example
const creds = {
  username: 'twilio',
  password: 'ahoy',
};
// Hardcoded secret for this example. In a real app, you would
// generate this and store it securely as an environment variable
// and access it via context.SECRET or similar
const secret = 'secret_key';

// Function to generate a JWT token
exports.handler = (context, event, callback) => {
  // Retrieve the username and password from the request
  const { username, password } = event;
  // Prepare a new Twilio response
  const response = new Twilio.Response();

  // If the provided credentials are invalid, return 401 Unauthorized.
  // In a real app you would check the credentials against your database.
  if (username !== creds.username || password !== creds.password) {
    response
      .setBody('Username or password is incorrect')
      .setStatusCode(401);

    return callback(null, response);
  }

  // Create a new signed JWT for the user that will expire in 1 day.
  // To understand more about JWT and what sub, iss, and these
  // other options are, see https://jwt.io/
  const token = jwt.sign(
    {
      sub: username,
      iss: 'twil.io',
      org: 'twilio',
      perms: ['read'],
    },
    secret,
    { expiresIn: '1d' }
  );

  // Set the token as the access_token header and return the response
  response.setBody('OK').appendHeader('access_token', token);

  return callback(null, response);
};
```

```js title="Authenticate Function requests using Bearer Authorization and JWT"
const jwt = require('jsonwebtoken');

const employeeSalaries = [
  {
    username: 'jdoe',
    salary: '$2000.00',
  },
  {
    username: 'mturner',
    salary: '$2500.00',
  },
];
const secret = 'secret_key'; // keep this in env variables

// Function that exposes sensitive information and requires
// a valid JWT token to be present in the request header to access.
exports.handler = (context, event, callback) => {
  // Grab the auth token from the request header
  const authHeader = event.request.headers.authorization;
  // Prepare a new Twilio response
  const response = new Twilio.Response();
  // Reject requests that don't have an Authorization header
  if (!authHeader) return callback(null, setUnauthorized(response));

  // The auth type and token are separated by a space, split them
  const [authType, authToken] = authHeader.split(' ');
  // If the auth type is not Bearer, return a 401 Unauthorized response
  if (authType.toLowerCase() !== 'bearer')
    return callback(null, setUnauthorized(response));

  try {
    // Verify the token against the secret. If the token is invalid,
    // jwt.verify will throw an error and we'll proceed to the catch block
    jwt.verify(authToken, secret);
    // At this point, the request has been validated and you could do
    // whatever you want with the request.
    // For this example, we'll just return the employee salaries
    return callback(null, employeeSalaries);
  } catch (e) {
    // If an error was thrown, the token is invalid and we should
    // return a 401 Unauthorized response
    return callback(null, setUnauthorized(response));
  }
};

// Helper method to format the response as a 401 Unauthorized response
// with the appropriate headers and values
const setUnauthorized = (response) => {
  response
    .setBody('Unauthorized')
    .setStatusCode(401)
    .appendHeader(
      'WWW-Authenticate',
      'Bearer realm="Access to read salaries"'
    );

  return response;
};
```

> \[!NOTE]
>
> Remember to change the [visibility](/docs/serverless/functions-assets/visibility) of your new Function to be **Public**. By default, the Console UI will create new Functions as **Protected**, which will prevent access to your Function except by Twilio requests.

Next, notice that the code snippets require the [jsonwebtoken](https://www.npmjs.com/package/jsonwebtoken) dependency. Be sure to add this as a [Dependency](/docs/serverless/functions-assets/functions/dependencies) to your Service.

Once all Functions have been saved and your Dependencies have been set, deploy the Function by clicking on **Deploy All** in the Console UI.

## Verify that Bearer Authentication is working

We can check that authentication is working first by sending an unauthenticated request to our deployed Function. You can get the URL of your Function by clicking the **Copy URL** button next to the Function.

Then, using your client of choice, make a `GET` or `POST` request to your Function. It should return a `401 Unauthorized` since the request contains no valid Authorization header.

```bash
curl -i -L -X POST 'https://auth-4173-dev.twil.io/bearer'
```

Result:

```bash
$ curl -i -L -X POST 'https://auth-4173-dev.twil.io/bearer' -i

HTTP/2 401
date: Tue, 03 Aug 2021 23:01:55 GMT
content-type: application/octet-stream
content-length: 12
www-authenticate: Bearer realm="Access to read salaries"
x-shenanigans: none

Unauthorized
```

Great! Requests are successfully being blocked from non-authenticated requests.

To make an authenticated request and get back a `200 OK`, we'll need to first generate a valid JWT by calling `/jwt`. We can then include that token in the Authorization header of our request to `/bearer`.

To get a valid JWT, we'll need to submit a valid username and password to the /jwt Function. Right now, these are hardcoded in the Function as `twilio` and `ahoy` respectively. The JWT generator Function is expecting the username and password to be passed in the body of the request, so you'll need to create a `POST` request with a JSON body composed of those values. Using cURL, that would look like this:

```bash
curl -i -L -X POST 'https://auth-4173-dev.twil.io/jwt' \
-H 'Content-Type: application/json' \
--data-raw '{
    "username": "twilio",
    "password": "ahoy"
}'
```

and the response would be:

```bash
$ curl -i -L -X POST 'https://auth-4173-dev.twil.io/jwt' \
-H 'Content-Type: application/json' \
--data-raw '{
    "username": "twilio",
    "password": "ahoy"
}'

HTTP/2 200
date: Tue, 03 Aug 2021 23:16:35 GMT
content-type: application/octet-stream
content-length: 2
access_token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ0d2lsaW8iLCJpc3MiOiJ0d2lsLmlvIiwib3JnIjoidHdpbGlvIiwicGVybXMiOlsicmVhZCJdLCJpYXQiOjE2MjgwMzI1OTUsImV4cCI6MTYyODExODk5NX0.uZzHuN5PpK6qM5wCu01_S8lkFPDpIcxQJq6A7sDr6gc
x-shenanigans: none
x-content-type-options: nosniff
x-xss-protection: 1; mode=block

OK
```

The header `access_token` contains the valid JWT that was just generated for us. Go ahead and try your request to `/bearer` again, but this time including the Authorization header including this JWT:

```bash
curl -i -L -X POST 'https://auth-4173-dev.twil.io/bearer' \
-H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ0d2lsaW8iLCJpc3MiOiJ0d2lsLmlvIiwib3JnIjoidHdpbGlvIiwicGVybXMiOlsicmVhZCJdLCJpYXQiOjE2MjgwMzA3ODIsImV4cCI6MTYyODExNzE4Mn0.gBusSFmlRt_o3H3E2UB4GGxjbZJLOOS0bKFXTxAgnlw'
```

the response should be:

```bash
$ curl -i -L -X POST 'https://auth-4173-dev.twil.io/bearer' \
-H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ0d2lsaW8iLCJpc3MiOiJ0d2lsLmlvIiwib3JnIjoidHdpbGlvIiwicGVybXMiOlsicmVhZCJdLCJpYXQiOjE2MjgwMzA3ODIsImV4cCI6MTYyODExNzE4Mn0.gBusSFmlRt_o3H3E2UB4GGxjbZJLOOS0bKFXTxAgnlw'

HTTP/2 200
date: Tue, 03 Aug 2021 23:20:10 GMT
content-type: application/json
content-length: 84
x-shenanigans: none
x-content-type-options: nosniff
x-xss-protection: 1; mode=block

[{"username":"jdoe","salary":"$2000.00"},{"username":"mturner","salary":"$2500.00"}]
```

At this point, Bearer Authentication is working for your Function!

To make this example your own, you could experiment with the following:

* Refactor the common `'secret_key'` into an [Environment Variable](/docs/serverless/functions-assets/functions/variables) so that it is stored securely and only needs to be changed in one place.
* Use Environment Variables to store the approved credentials, or even create a database of approved usernames and passwords to support multiple users.
* Instead of using a hardcoded array of data, retrieve values from a database.
