JWT/OIDC auth method

warning

Note: This engine can use external X.509 certificates as part of TLS or signature validation. Verifying signatures against X.509 certificates that use SHA-1 is deprecated and is no longer usable without a workaround. See the deprecation FAQ for more information.

The jwt auth method can be used to authenticate with OpenBao using OIDC or by providing a JWT.

The OIDC method allows authentication via a configured OIDC provider using the user's web browser. This method may be initiated from the OpenBao UI or the command line. Alternatively, a JWT can be provided directly. The JWT is cryptographically verified using locally-provided keys, or, if configured, an OIDC Discovery service can be used to fetch the appropriate keys. The choice of method is configured per role.

Both methods allow additional processing of the claims data in the JWT. Some of the concepts common to both methods will be covered first, followed by specific examples of OIDC and JWT usage.

OIDC authentication

This section covers the setup and use of OIDC roles. If a JWT is to be provided directly, refer to the JWT Authentication section below. Basic familiarity with OIDC concepts is assumed. The Authorization Code flow makes use of the Proof Key for Code Exchange (PKCE) extension.

OpenBao includes two built-in OIDC login flows: the OpenBao UI, and the CLI using a bao login.

Redirect URIs

Unless you are using callbackmode=device, an important part of OIDC role configuration is properly setting redirect URIs. This must be done both in OpenBao and with the OIDC provider, and these configurations must align. The redirect URIs are specified for a role with the allowed_redirect_uris parameter. There are different redirect URIs to configure the OpenBao UI and CLI flows, so one or both will need to be set up depending on the installation.

CLI

If you plan to support authentication via bao login -method=oidc and are not using callbackmode=device, a redirect URI with a path ending in oidc/callback must be set. With the default callbackmode=client this can usually be http://localhost:8250/oidc/callback. With callbackmode=direct this should be a URI of the form:

https://{host:port}/v1/auth/{path}/oidc/callback

where "host:port" is the OpenBao server name and port, and "path" is the path the JWT backend is mounted at (e.g. "oidc" or "jwt").

Logins via the CLI may specify a different host and/or listening port if needed, and a URI with this host/port must match one of the configured redirected URIs. These same URIs must be added to the provider as well.

OpenBao UI

Logging in via the OpenBao UI requires a redirect URI of the form:

https://{host:port}/ui/vault/auth/{path}/oidc/callback

The "host:port" must be correct for the OpenBao server, and "path" must match the path the JWT backend is mounted at (e.g. "oidc" or "jwt").

If the oidc_response_mode is set to form_post, then logging in via the OpenBao UI requires a redirect URI of the same form as the direct callback mode:

https://{host:port}/v1/auth/{path}/oidc/callback

Select the "OIDC" login method.
Enter a role name if necessary.
Press "Sign In" and complete the authentication with the configured provider.

The CLI login defaults to path of /oidc. If this auth method was enabled at a different path, specify -path=/my-path in the CLI.

$ bao login -method=oidc port=8400 role=test

Complete the login via your OIDC provider. Launching browser to:

    https://myco.auth0.com/authorize?redirect_uri=http%3A%2F%2Flocalhost%3A8400%2Foidc%2Fcallback&client_id=r3qXc2bix9eF...

The browser will open to the generated URL to complete the provider's login. The URL may be entered manually if the browser cannot be automatically opened.

skip_browser (default: "false"). Toggle the automatic launching of the default browser to the login URL.

The callback listener may be customized with the following optional parameters. These are typically not required to be set:

mount (default: "oidc")
callbackmode (default: "client"). Mode of callback: "client" for connection to a port on the cli client, direct for direct connection to the OpenBao server, or "device" for device flow which has no callback.
listenaddress (default: "localhost"). Only for client callback mode.
port (default: 8250). Only for client callback mode.
callbackhost (default: the OpenBao's server and port in direct callback mode, else "localhost")
callbackmethod (default: the method used for the OpenBao server in direct callback mode, else "http"). The method to use in an OIDC redirect_uri.
callbackport (default: value set for port in client callback mode, otherwise the port of the OpenBao server and an added /v1/auth/<path> where <path> is from the login -path option) This value is used in the redirect_uri, whereas port is the localhost port that the listener is using. These two may be different in advanced setups.

OIDC provider configuration

The OIDC authentication flow has been successfully tested with a number of providers. A full guide to configuring OAuth/OIDC applications is beyond the scope of OpenBao documentation, but a collection of provider configuration steps has been collected to help get started: OIDC Provider Setup

OIDC configuration troubleshooting

This amount of configuration required for OIDC is relatively small, but it can be tricky to debug why things aren't working. Some tips for setting up OIDC:

If a role parameter (e.g. bound_claims) requires a map value, it can't be set individually using the OpenBao CLI. In these cases the best approach is to write the entire configuration as a single JSON object:

bao write auth/oidc/role/demo -<<EOF
{
  "user_claim": "sub",
  "bound_audiences": "abc123",
  "role_type": "oidc",
  "policies": "demo",
  "ttl": "1h",
  "bound_claims": { "groups": ["mygroup/mysubgroup"] }
}
EOF

Monitor OpenBao's log output. Important information about OIDC validation failures will be emitted.
Ensure Redirect URIs are correct in OpenBao and on the provider. They need to match exactly. Check: http/https, 127.0.0.1/localhost, port numbers, whether trailing slashes are present.
Start simple. The only claim configuration a role requires is user_claim. After authentication is known to work, you can add additional claims bindings and metadata copying.
bound_audiences is optional for OIDC roles and typically not required. OIDC providers will use the client_id as the audience and OIDC validation expects this.
Check your provider for what scopes are required in order to receive all of the information you need. The scopes "profile" and "groups" often need to be requested, and can be added by setting oidc_scopes="profile,groups" on the role.
If you're seeing claim-related errors in logs, review the provider's docs very carefully to see how they're naming and structuring their claims. Depending on the provider, you may be able to construct a simple curl implicit grant request to obtain a JWT that you can inspect. An example of how to decode the JWT (in this case located in the "access_token" field of a JSON response):

cat jwt.json | jq -r .access_token | cut -d. -f2 | base64 -D
The verbose_oidc_logging role option is available which will log the received OIDC token to the server logs if debug-level logging is enabled. This can be helpful when debugging provider setup and verifying that the received claims are what you expect. Since claims data is logged verbatim and may contain sensitive information, this option should not be used in production.
Azure requires some additional configuration when a user is a member of more than 200 groups, described in Azure-specific handling configuration

JWT authentication

The authentication flow for roles of type "jwt" is simpler than OIDC since OpenBao only needs to validate the provided JWT.

JWT verification

JWT signatures will be verified against public keys from the issuer. This process can be done in three different ways, though only one method may be configured for a single backend:

Static Keys. A set of public keys is stored directly in the backend configuration.
JWKS. A JSON Web Key Set (JWKS) URL (and optional certificate chain) is configured. Keys will be fetched from this endpoint during authentication.
OIDC Discovery. An OIDC Discovery URL (and optional certificate chain) is configured. Keys will be fetched from this URL during authentication. When OIDC Discovery is used, OIDC validation criteria (e.g. iss, aud, etc.) will be applied.

If multiple methods are needed, another instance of the backend can be mounted and configured at a different path.

Via the CLI

The default path is /jwt. If this auth method was enabled at a different path, specify -path=/my-path in the CLI.

$ bao write auth/jwt/login role=demo jwt=...

Via the API

The default endpoint is auth/jwt/login. If this auth method was enabled at a different path, use that value instead of jwt.

$ curl \
    --request POST \
    --data '{"jwt": "your_jwt", "role": "demo"}' \
    http://127.0.0.1:8200/v1/auth/jwt/login

The response will contain a token at auth.client_token:

{
  "auth": {
    "client_token": "38fe9691-e623-7238-f618-c94d4e7bc674",
    "accessor": "78e87a38-84ed-2692-538f-ca8b9f400ab3",
    "policies": ["default"],
    "metadata": {
      "role": "demo"
    },
    "lease_duration": 2764800,
    "renewable": true
  }
}

Configuration

Auth methods must be configured in advance before users or machines can authenticate. These steps are usually completed by an operator or configuration management tool.

Enable the JWT auth method. Either the "jwt" or "oidc" name may be used. The backend will be mounted at the chosen name.
```
$ bao auth enable jwt
  or
$ bao auth enable oidc
```
Use the /config endpoint to configure OpenBao. To support JWT roles, either local keys, a JWKS URL, or an OIDC Discovery URL must be present. For OIDC roles, OIDC Discovery URL, OIDC Client ID and OIDC Client Secret are required. For the list of available configuration options, please see the API documentation.
```
$ bao write auth/jwt/config \
    oidc_discovery_url="https://myco.auth0.com/" \
    oidc_client_id="m5i8bj3iofytj" \
    oidc_client_secret="f4ubv72nfiu23hnsj" \
    default_role="demo"
```
If you need to perform JWT verification with JWT token validation, then leave the oidc_client_id and oidc_client_secret blank.
```
$ bao write auth/jwt/config \
   oidc_discovery_url="https://MYDOMAIN.eu.auth0.com/" \
   oidc_client_id="" \
   oidc_client_secret="" \
```

1. Create a named role:

 ```text
 bao write auth/jwt/role/demo \
     allowed_redirect_uris="http://localhost:8250/oidc/callback" \
     bound_subject="r3qX9DljwFIWhsiqwFiu38209F10atW6@clients" \
     bound_audiences="https://vault.plugin.auth.jwt.test" \
     user_claim="https://vault/user" \
     groups_claim="https://vault/groups" \
     policies=webapps \
     ttl=1h

This role authorizes JWTs with the given subject and audience claims, gives it the webapps policy, and uses the given user/groups claims to set up Identity aliases.

For the complete list of configuration options, please see the API documentation.

Bound claims

Once a JWT has been validated as being properly signed and not expired, the authorization flow will validate that any configured "bound" parameters match. In some cases there are dedicated parameters, for example bound_subject, which must match the JWT's sub parameter. A role may also be configured to check arbitrary claims through the bound_claims map. The map contains a set of claims and their required values. For example, assume bound_claims is set to:

{
  "division": "Europe",
  "department": "Engineering"
}

Only JWTs containing both the "division" and "department" claims, and respective matching values of "Europe" and "Engineering", would be authorized. If the expected value is a list, the claim must match one of the items in the list. To limit authorization to a set of email addresses:

{
  "email": ["fred@example.com", "julie@example.com"]
}

Bound claims can optionally be configured with globs. See the API documentation for more details.

Claims as metadata

Data from claims can be copied into the resulting auth token and alias metadata by configuring claim_mappings. This role parameter is a map of items to copy. The map elements are of the form: "<JWT claim>":"<metadata key>". Assume claim_mappings is set to:

{
  "division": "organization",
  "department": "department"
}

This specifies that the value in the JWT claim "division" should be copied to the metadata key "organization". The JWT "department" claim value will also be copied into metadata but will retain the key name. If a claim is configured in claim_mappings, it must existing in the JWT or else the authentication will fail.

Note: the metadata key name "role" is reserved and may not be used for claim mappings.

Claim specifications and JSON pointer

Some parameters (e.g. bound_claims, groups_claim, claim_mappings, user_claim) are used to point to data within the JWT. If the desired key is at the top of level of the JWT, the name can be provided directly. If it is nested at a lower level, a JSON Pointer may be used.

Assume the following JSON data to be referenced:

{
  "division": "North America",
  "groups": {
    "primary": "Engineering",
    "secondary": "Software"
  }
}

A parameter of "division" will reference "North America", as this is a top level key. A parameter "/groups/primary" uses JSON Pointer syntax to reference "Engineering" at a lower level. Any valid JSON Pointer can be used as a selector. Refer to the JSON Pointer RFC for a full description of the syntax.

API

The JWT Auth Plugin has a full HTTP API. Please see the API docs for more details.

OIDC authentication​

Redirect URIs​

OIDC login (OpenBao UI)​

OIDC login (CLI)​

OIDC provider configuration​

OIDC configuration troubleshooting​

JWT authentication​

JWT verification​

Via the CLI​

Via the API​

Configuration​

Bound claims​

Claims as metadata​

Claim specifications and JSON pointer​

API​