Enable Bearer authentication for an HTTP trigger - Function Compute

Bearer authentication lets you restrict access to an HTTP trigger by requiring callers to present a secret token in every request. Function Compute checks the token against the values you configure — no external identity provider required.

How it works

When a request arrives at the trigger, Function Compute:

Checks for an Authorization: Bearer <token> header. If the header is absent, the request is rejected with "Authorization header is expected but missing".
Extracts the token value and compares it against all enabled tokens stored for that trigger.
Grants access if any token matches; otherwise rejects the request with "access denied due to invalid bearer token".

This check runs before your function code executes, so unauthorized requests never reach your function.

Prerequisites

Before you begin, make sure you have:

A function. See Create a function.
An HTTP trigger on that function. See Configure an HTTP trigger.

Limitations

Constraint	Details
Tokens per trigger	1–20
Token name length	Up to 128 characters; letters, digits, underscores, and hyphens only; cannot start with a digit or hyphen
Token value length	32–128 characters; only standard Base64 characters: `A-Z`, `a-z`, `0-9`, `+`, `/`, `=`, `-`, `~`, `.`
Token name uniqueness	Each name must be unique within a single trigger
Token value uniqueness	Values should differ across triggers and within the same trigger
Protocol requirement	Use HTTPS in production environments. HTTP should only be used for development and testing. Function Compute is not responsible for security issues caused by token leakage when using HTTP.

Enable Bearer authentication

Log on to the Function Compute console. In the left navigation pane, click Functions.
In the top navigation bar, select a region. Click the function you want to manage.
On the function details page, click the Triggers tab. In the Actions column for the HTTP trigger, click Edit.
In the Edit Trigger panel, set Authentication Method to Bearer Authentication and Token Type to Opaque.
In the Authentication Token section, enter your token value in tokenData. To configure multiple tokens, use the following JSON structure:
Warning
The tokenData values below are placeholders. Replace them with your own token values before saving. Do not use the example values in production.
```
{
    "tokens": [
        {
            "enable": true,
            "tokenData": "<your-token-value>",
            "tokenName": "<your-token-name>"
        },
        {
            "enable": true,
            "tokenData": "<your-second-token-value>",
            "tokenName": "<your-second-token-name>"
        }
    ]
}
```
Field
Description
Example
tokenData
The secret token string (32–128 characters)
token-8g***5
tokenName
A unique label for this token
primary-token
enable
Whether the token is active
true or false
To disable a token without deleting it, set "enable": false.
Click OK. Bearer authentication is now active for this trigger.

Verify the configuration

Warning

Always use HTTPS in production. HTTP transmits tokens in plaintext, which risks exposure. Function Compute is not responsible for security issues from HTTP use.

Send a test request with your token in the Authorization header:

curl --data your-data -X POST \
  -H "Authorization: Bearer <your-token-value>" \
  https://<your-http-trigger-endpoint>

A successful response confirms your function received the request. If you receive an error, see Troubleshooting.

Security

Rotate tokens without downtime

Each trigger supports up to 20 tokens, so you can rotate a token without interrupting callers:

Add a new token to the trigger (keep the old token enabled).
Update your clients to send the new token.
After all clients are using the new token, set the old token's enable field to false or remove it.

This zero-downtime approach works for both planned rotations and for incident response when a token is compromised.

Token management responsibilities

Function Compute stores and verifies your tokens. You are responsible for:

Rotating tokens that have been leaked or compromised
Proactively rotating tokens that have been in use for an extended period
Generating token values that are long and random — avoid predictable combinations

Troubleshooting

"Authorization header is expected but missing"

The request reached the trigger without an Authorization header. Add the header to your request:

Authorization: Bearer <your-token-value>

"access denied due to invalid bearer token"

The token was present but did not match any enabled token on the trigger. Check that you are sending the exact tokenData value, including any special characters.

Billing

Bearer authentication has no additional cost. Function Compute charges for the gateway feature as part of the standard function invocation count, whether or not Bearer authentication is enabled.

Field	Description	Example
`tokenData`	The secret token string (32–128 characters)	`token-8g***5`
`tokenName`	A unique label for this token	`primary-token`
`enable`	Whether the token is active	`true` or `false`