dfc3ad015a
* Chore (dev portal): update learn nav data links (#15515) * Update docs-nav-data.json * Update docs-nav-data.json * website: fixes internal redirects (#15750) * chore: remove duplicate overview item (#15805) * Use `badge` for `<sup>` tags in nav data JSON files (#15928) * Replacing <sup> tags with badge * Adding type and color to badges * fix broken links in vault docs (#15976) * website: Update old learn links to redirect locations (#16047) * update previews to render developer UI * update redirects * adjust content so it is backwards compat Co-authored-by: HashiBot <62622282+hashibot-web@users.noreply.github.com> Co-authored-by: Kendall Strautman <36613477+kendallstrautman@users.noreply.github.com> Co-authored-by: Ashlee M Boyer <43934258+ashleemboyer@users.noreply.github.com>
173 lines
6.7 KiB
Plaintext
173 lines
6.7 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: OIDC Identity Provider
|
|
description: >-
|
|
Setup and configuration for Vault as an OpenID Connect (OIDC) identity provider.
|
|
---
|
|
|
|
# OIDC Identity Provider
|
|
|
|
Vault is an OpenID Connect ([OIDC](https://openid.net/specs/openid-connect-core-1_0.html))
|
|
identity provider. This enables client applications that speak the OIDC protocol to leverage
|
|
Vault's source of [identity](/docs/concepts/identity) and wide range of [authentication methods](/docs/auth)
|
|
when authenticating end-users. Client applications can configure their authentication logic
|
|
to talk to Vault. Once enabled, Vault will act as the bridge to other identity providers via
|
|
its existing authentication methods. Client applications can also obtain identity information
|
|
for their end-users by leveraging custom templating of Vault identity information.
|
|
|
|
\-> **Note**: For more detailed information on the configuration resources and OIDC endpoints,
|
|
please visit the [OIDC provider](/docs/concepts/oidc-provider) concepts page.
|
|
|
|
## Setup
|
|
|
|
The Vault OIDC provider system is built on top of the identity secrets engine.
|
|
This secrets engine is mounted by default and cannot be disabled or moved.
|
|
|
|
Each Vault namespace has a default OIDC [provider](/docs/concepts/oidc-provider#providers)
|
|
and [key](/docs/concepts/oidc-provider#key). This built-in configuration enables client
|
|
applications to begin using Vault as a source of identity with minimal configuration. For
|
|
details on the built-in configuration and advanced options, see the [OIDC provider](/docs/concepts/oidc-provider)
|
|
concepts page.
|
|
|
|
The following steps show a minimal configuration that allows a client application to use
|
|
Vault as an OIDC provider.
|
|
|
|
1. Enable a Vault auth method:
|
|
|
|
```text
|
|
$ vault auth enable userpass
|
|
Success! Enabled userpass auth method at: userpass/
|
|
```
|
|
|
|
Any Vault auth method may be used within the OIDC flow. For simplicity, enable the
|
|
`userpass` auth method.
|
|
|
|
2. Create a user:
|
|
|
|
```text
|
|
$ vault write auth/userpass/users/end-user password="securepassword"
|
|
Success! Data written to: auth/userpass/users/end-user
|
|
```
|
|
|
|
This user will authenticate to Vault through a client application, otherwise known as
|
|
an OIDC [relying party](https://openid.net/specs/openid-connect-core-1_0.html#Terminology).
|
|
|
|
2. Create a client application:
|
|
|
|
```text
|
|
$ vault write identity/oidc/client/my-webapp \
|
|
redirect_uris="https://localhost:9702/auth/oidc-callback" \
|
|
assignments="allow_all"
|
|
Success! Data written to: identity/oidc/client/my-webapp
|
|
```
|
|
|
|
This operation creates a client application which can be used to configure an OIDC
|
|
relying party. See the [client applications](/docs/concepts/oidc-provider#client-applications)
|
|
section for details on different client types, including `confidential` and `public` clients.
|
|
|
|
The `assignments` parameter limits the Vault entities and groups that are allowed to
|
|
authenticate through the client application. By default, no Vault entities are allowed.
|
|
To allow all Vault entities to authenticate, the built-in [allow_all](/docs/concepts/oidc-provider#assignments)
|
|
assignment is provided.
|
|
|
|
2. Read client credentials:
|
|
|
|
```text
|
|
$ vault read identity/oidc/client/my-webapp
|
|
|
|
Key Value
|
|
--- -----
|
|
access_token_ttl 24h
|
|
assignments [allow_all]
|
|
client_id GSDTnn3KaOrLpNlVGlYLS9TVsZgOTweO
|
|
client_secret hvo_secret_gBKHcTP58C4aq7FqPWsuqKgpiiegd7ahpifGae9WGkHRCwFEJTZA9KGdNVpzE0r8
|
|
client_type confidential
|
|
id_token_ttl 24h
|
|
key default
|
|
redirect_uris [https://localhost:9702/auth/oidc-callback]
|
|
```
|
|
|
|
The `client_id` and `client_secret` are the client application's credentials. These
|
|
values are typically required when configuring an OIDC relying party.
|
|
|
|
2. Read OIDC discovery configuration:
|
|
|
|
```text
|
|
$ curl -s http://127.0.0.1:8200/v1/identity/oidc/provider/default/.well-known/openid-configuration
|
|
{
|
|
"issuer": "http://127.0.0.1:8200/v1/identity/oidc/provider/default",
|
|
"jwks_uri": "http://127.0.0.1:8200/v1/identity/oidc/provider/default/.well-known/keys",
|
|
"authorization_endpoint": "http://127.0.0.1:8200/ui/vault/identity/oidc/provider/default/authorize",
|
|
"token_endpoint": "http://127.0.0.1:8200/v1/identity/oidc/provider/default/token",
|
|
"userinfo_endpoint": "http://127.0.0.1:8200/v1/identity/oidc/provider/default/userinfo",
|
|
"request_parameter_supported": false,
|
|
"request_uri_parameter_supported": false,
|
|
"id_token_signing_alg_values_supported": [
|
|
"RS256",
|
|
"RS384",
|
|
"RS512",
|
|
"ES256",
|
|
"ES384",
|
|
"ES512",
|
|
"EdDSA"
|
|
],
|
|
"response_types_supported": [
|
|
"code"
|
|
],
|
|
"scopes_supported": [
|
|
"openid"
|
|
],
|
|
"subject_types_supported": [
|
|
"public"
|
|
],
|
|
"grant_types_supported": [
|
|
"authorization_code"
|
|
],
|
|
"token_endpoint_auth_methods_supported": [
|
|
"none",
|
|
"client_secret_basic",
|
|
"client_secret_post"
|
|
]
|
|
}
|
|
```
|
|
|
|
Each Vault OIDC provider publishes [discovery metadata](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata).
|
|
The `issuer` value is typically required when configuring an OIDC relying party.
|
|
|
|
## Usage
|
|
|
|
After configuring a Vault auth method and client application, the following details can
|
|
be used to configure an OIDC relying party to delegate end-user authentication to Vault.
|
|
|
|
- `client_id` - The ID of the client application
|
|
- `client_secret` - The secret of the client application
|
|
- `issuer` - The issuer of the Vault OIDC provider
|
|
|
|
A number of HashiCorp products provide OIDC authentication methods. This means that they
|
|
can leverage Vault as a source of identity using the OIDC protocol. See the following links
|
|
for details on configuring OIDC authentication for other HashiCorp products:
|
|
|
|
- [Boundary](https://learn.hashicorp.com/tutorials/boundary/oidc-auth)
|
|
- [Consul](https://www.consul.io/docs/security/acl/auth-methods/oidc)
|
|
- [Waypoint](https://www.waypointproject.io/docs/server/auth/oidc)
|
|
|
|
Otherwise, refer to the documentation of the specific OIDC relying party for usage details.
|
|
|
|
## Supported Flows
|
|
|
|
The Vault OIDC provider feature currently supports the following authentication flow:
|
|
|
|
- [Authorization Code Flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth).
|
|
|
|
## Tutorial
|
|
|
|
Refer to the [Vault as an OIDC Identity Provider](https://learn.hashicorp.com/tutorials/vault/oidc-identity-provider)
|
|
tutorial to learn how to configure a HashiCorp [Boundary](https://www.boundaryproject.io/)
|
|
to leverage Vault as a source of identity using the OIDC protocol.
|
|
|
|
## API
|
|
|
|
The Vault OIDC provider feature has a full HTTP API. Please see the
|
|
[OIDC identity provider API](/api-docs/secret/identity/oidc-provider) for more
|
|
details.
|