From 88bc642d2d7d23ab320d0f5ffdf4fd4e7a688dbe Mon Sep 17 00:00:00 2001 From: Austin Gebauer Date: Mon, 21 Mar 2022 19:20:44 -0700 Subject: [PATCH] identity/oidc: updates documentation for PKCE, client types, and default resources --- .../secret/identity/oidc-provider.mdx | 76 ++++-- .../content/docs/concepts/oidc-provider.mdx | 92 +++++-- .../docs/secrets/identity/oidc-provider.mdx | 224 ++++++++++-------- 3 files changed, 260 insertions(+), 132 deletions(-) diff --git a/website/content/api-docs/secret/identity/oidc-provider.mdx b/website/content/api-docs/secret/identity/oidc-provider.mdx index 4de357852bc9..1afa28c6572d 100644 --- a/website/content/api-docs/secret/identity/oidc-provider.mdx +++ b/website/content/api-docs/secret/identity/oidc-provider.mdx @@ -21,7 +21,7 @@ This endpoint creates or updates a Provider. Vault's `api_addr` as the `scheme://host:port` component and `/v1/:namespace/identity/oidc/provider/:name` as the path component. If provided explicitly, it must point to a Vault instance that is network reachable by clients for ID token validation. -- `allowed_client_ids` `([]string: )` – The client IDs that are permitted to use the provider. If empty, no clients are allowed. If "*", all clients are allowed. +- `allowed_client_ids` `([]string: )` – The client IDs that are permitted to use the provider. If empty, no clients are allowed. If `"*"` provided, all clients are allowed. - `scopes_supported` `([]string: )` – The scopes available for requesting on the provider. @@ -138,7 +138,8 @@ This endpoint creates or updates a scope. - `name` `(string: )` – The name of the scope. This parameter is specified as part of the URL. The `openid` scope name is reserved. -- `template` `(string: )` - The template string for the scope. This may be provided as escaped JSON or base64 encoded JSON. +- `template` `(string: )` - The [JSON template](/docs/concepts/oidc-provider#scopes) + string for the scope. This may be provided as escaped JSON or base64 encoded JSON. - `description` `(string: )` – A description of the scope. @@ -254,18 +255,40 @@ This endpoint creates or updates a client. - `name` `(string: )` – The name of the client. This parameter is specified as part of the URL. -- `key` `(string: )` – A reference to a named key resource. This cannot be modified after creation. +- `key` `(string: "default")` – A reference to a [named key](/api-docs/secret/identity/tokens#create-a-named-key) + resource. This key will be used to sign ID tokens for the client. This cannot be modified + after creation. If not supplied, defaults to the built-in [default key](/docs/concepts/oidc-provider#keys). - `redirect_uris` `([]string: )` - Redirection URI values used by the client. One of these values must exactly match the `redirect_uri` parameter value used in each [authentication request](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). -- `assignments` `([]string: )` – A list of assignment resources associated with the client. - -- `id_token_ttl` `(int or duration: )` – The time-to-live for ID tokens obtained by the client. +- `assignments` `([]string: )` – A list of assignment resources associated with + the client. Client assignments limit the Vault entities and groups that are allowed to + authenticate through the client. By default, no Vault entities are allowed. To allow all + Vault entities to authenticate through the client, supply the built-in + [allow_all](/docs/concepts/oidc-provider#assignments) assignment. + +- `client_type` `(string: "confidential")` – The [client type](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1) + based on its ability to maintain confidentiality of credentials. The following list details + the differences between confidential and public clients in Vault: + - `confidential` + - Capable of maintaining the confidentiality of its credentials + - Has a client secret + - Uses the `client_secret_basic` [client authentication method](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) + - May use Proof Key for Code Exchange ([PKCE](https://datatracker.ietf.org/doc/html/rfc7636)) + for the authorization code flow + - `public` + - Not capable of maintaining the confidentiality of its credentials + - Does not have a client secret + - Uses the `none` [client authentication method](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) + - Must use Proof Key for Code Exchange ([PKCE](https://datatracker.ietf.org/doc/html/rfc7636)) + for the authorization code flow + +- `id_token_ttl` `(int or duration: "24h")` – The time-to-live for ID tokens obtained by the client. This can be specified as a number of seconds or as a [Go duration format string](https://golang.org/pkg/time/#ParseDuration) like `"30m"` or `"6h"`. The value should be less than the `verification_ttl` on the key. -- `access_token_ttl` `(int or duration: )` – The time-to-live for access tokens obtained by the client. +- `access_token_ttl` `(int or duration: "24h")` – The time-to-live for access tokens obtained by the client. This can be specified as a number of seconds or as a [Go duration format string](https://golang.org/pkg/time/#ParseDuration) like `"30m"` or `"6h"`. ### Sample Payload @@ -317,6 +340,7 @@ $ curl \ "assignments":[], "client_id":"014zXvcvbvIZWwD5NfD1Uzmv7c5JBRMb", "client_secret":"hvo_secret_bZtgQPBZaJXK7F5vOI7JlvEuLOfOUS7DmwynFjE3xKcsen7TyowqPFfYFXG2tbWM", + "client_type": "confidential", "id_token_ttl":3600, "key":"test-key", "redirect_uris":[] @@ -547,7 +571,8 @@ $ curl \ "authorization_code" ], "token_endpoint_auth_methods_supported": [ - "client_secret_basic" + "client_secret_basic", + "none" ]} ``` @@ -622,6 +647,17 @@ to be used for the [Authorization Code Flow](https://openid.net/specs/openid-con - `nonce` `(string: )` - A value that is returned in the ID token nonce claim. It is used to mitigate replay attacks, so we *strongly encourage* providing this optional parameter. +- `max_age` `(integer: )` - The allowable elapsed time in seconds since the last + time the end-user was actively authenticated. + +- `code_challenge` `(string: )` - The [PKCE](https://datatracker.ietf.org/doc/html/rfc7636) + code challenge derived from the client's code verifier. Optional for `confidential` clients. + Required for `public` clients. + +- `code_challenge_method` `(string: "plain")` - The method that was used to derive the + [PKCE](https://datatracker.ietf.org/doc/html/rfc7636) code challenge. The following + methods are supported: `S256`, `plain`. + ### Sample Request ```shell-session @@ -659,23 +695,31 @@ for an OIDC provider. ### Parameters - `name` `(string: )` - The name of the provider. This parameter is -specified as part of the URL. + specified as part of the URL. - `code` `(string: )` - The authorization code received from the -provider's authorization endpoint. + provider's authorization endpoint. - `grant_type` `(string: )` - The authorization grant type. The -following grant types are supported: `authorization_code`. + following grant types are supported: `authorization_code`. - `redirect_uri` `(string: )` - The callback location where the -authorization request was sent. This must match the `redirect_uri` used when the -original authorization code was generated. + authorization request was sent. This must match the `redirect_uri` used when the + original authorization code was generated. + +- `client_id` `(string: )` - The ID of the requesting client. This parameter + is only required for `public` clients which do not have a client secret. `confidential` + clients should not use this parameter. + +- `code_verifier` `(string: )` - The code verifier associated with the given + `code`. Required for authorization codes that were granted using [PKCE](https://datatracker.ietf.org/doc/html/rfc7636). + Required for `public` clients. ### Headers -- Basic Auth `(string: )` - Authenticate the client using the `client_id` -and `client_secret` as described in the [client_secret_basic authentication method](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication). -The authentication method uses the HTTP Basic authentication scheme. +- `Authorization: Basic` `(string: )` - An HTTP Basic authentication scheme header + including the `client_id` and `client_secret` as described in the [client_secret_basic](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) + authentication method. This header is only required for `confidential` clients. ### Sample Request diff --git a/website/content/docs/concepts/oidc-provider.mdx b/website/content/docs/concepts/oidc-provider.mdx index ab6b5836941d..8c14aa18c46f 100644 --- a/website/content/docs/concepts/oidc-provider.mdx +++ b/website/content/docs/concepts/oidc-provider.mdx @@ -7,24 +7,25 @@ description: >- # OIDC Provider -~> **Note:** This feature is currently a ***Tech Preview*** and not recommended for deployment in production. - - -This document describes how Vault can be an **OpenID Connect (OIDC) identity provider** by enabling applications to leverage Vault as a source of identity using the OIDC protocol. - -This feature allows clients speaking the OIDC protocol to take advantage of Vault's various authentication methods and source of identity. Clients can configure their authentication logic to talk to Vault. Once enabled, Vault will act as the bridge to identity providers via its existing authentication methods. Clients will also obtain identity information for their end-users by leveraging custom templating of Vault identity information. - -Vault as an OIDC provider allows mutual Vault and Boundary customers to leverage Vault's identity system to delegate authentication and authorization to Vault. Vault, therefore, acts as an identity provider for Boundary. Other HashiCorp products such as Consul can also leverage Vault's identity system and provide delegated authentication and authorization to its users. Having Vault as an OIDC provider allows a single sign-on experience to their end-users for organizations that want to leverage Vault as an identity provider. +This document provides conceptual information about the Vault **OpenID Connect (OIDC) identity +provider** feature. This feature 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. For more information about the usage of Vault's OIDC provider, +refer to the [OIDC identity provider](/docs/secrets/identity/oidc-provider) documentation. ## Configuration Options The next few sections of the document provide implementation details for each resource that permits Vault configuration as an OIDC identity provider. -### Providers +### OIDC Providers + +Each Vault namespace will contain a built-in provider resource named `default`. The `default` +provider will allow all client applications within the namespace to use it for OIDC flows. +The `default` provider can be modified but not deleted. -A Vault namespace may contain several provider resources. Each configured provider will publish the APIs listed within the OIDC flow. The APIs will be served via backend path-based routing on Vault's listen [address](/docs/configuration/listener/tcp#address). +Additionally, a Vault namespace may contain several provider resources. Each configured provider will publish the APIs listed within the [OIDC flow](/docs/concepts/oidc-provider#oidc-flow) section. The APIs will be served via backend path-based routing on Vault's listen [address](/docs/configuration/listener/tcp#address). -A provider must have the following configuration parameters: +A provider has the following configuration parameters: * **Issuer URL**: used in the `iss` claim of ID tokens * **Allowed client IDs**: limits which clients can access the provider @@ -32,7 +33,9 @@ A provider must have the following configuration parameters: The issuer URL parameter is necessary for the validation of ID tokens by clients. If an URL parameter is not provided explicitly, it will default to a URL with Vault's [api_addr](/docs/configuration#api_addr) as the `scheme://host:port` component and `/v1/:namespace/identity/oidc/provider/:name` as the path component. This means tokens issued by a provider in a specified Vault cluster must be validated within that same cluster. If the issuer URL is provided explicitly, it must point to a Vault instance that is network-reachable by clients for ID token validation. -The allowed client IDs parameter utilizes the list of client IDs that have been generated by Vault as a part of client registration. By default, all clients will be *disallowed*. Providing an asterisk(*) as the parameter value will allow all clients to use the provider. The scopes parameter employs a list of references to named scope resources. The values provided are discoverable by the `scopes_supported` key in the OIDC discovery document of the provider. By default, a provider will have the `openid` scope available. See the scopes section below for more details on the `openid` scope. +The allowed client IDs parameter utilizes the list of client IDs that have been generated by Vault as a part of client registration. By default, all clients will be *disallowed*. Providing an asterisk(*) as the parameter value will allow all clients to use the provider. + +The scopes parameter employs a list of references to named scope resources. The values provided are discoverable by the `scopes_supported` key in the OIDC discovery document of the provider. By default, a provider will have the `openid` scope available. See the scopes section below for more details on the `openid` scope. ### Scopes @@ -85,7 +88,7 @@ Several named scopes can be made available on an individual provider. Note that The `openid` scope is a unique case scope that may not be modified or deleted. The scope will exist in Vault and supported by each provider by default. The scope represents the minimum set of claims required by the OIDC specification for inclusion in ID tokens. As such, templates may not contain top-level keys that overwrite the claims populated by the openid scope. -The following defines the claims key and value mapping for the openid scope: +The following defines the claims key and value mapping for the `openid` scope: * `iss`- configured issuer of the provider * `sub`- unique entity ID of the Vault user @@ -93,31 +96,76 @@ The following defines the claims key and value mapping for the openid scope: * `iat`- time of token issue * `exp`- time of token issue + ID token TTL -### Client registration +### Client Applications -A client resource allows the relying party to [dynamically register](https://openid.net/specs/openid-connect-registration-1_0.html) by providing metadata about itself to Vault. +A client resource represents an application that wants to delegate end-user authentication +to Vault using the OIDC protocol. The information provided by a client resource can be used +to configure an OIDC [relying party](https://openid.net/specs/openid-connect-core-1_0.html#Terminology). The client must have the following configuration parameters: * **Redirect URIs**: limits the valid redirect URIs in an authentication request -* **Assignments**: determines who can authenticate with the client +* **Assignments**: determine who can authenticate with the client * **Key**: used to sign the ID tokens * **ID token TTL**: specifies the time-to-live for ID tokens -* **Access token TTL**: establishes the time-to-live for access tokens +* **Access token TTL**: specifies the time-to-live for access tokens +* **Client type**: determines the client's ability to maintain confidentiality of credentials -A `client_id` and `client_secret` are generated and returned after a successful client registration. Their values are strings using the base62 character set. The `client_id` will have 32 characters, and the `client_secret` will have a prefix of `hvo_secret`. The `client_id` uniquely identifies the client. The `client_secret` will be used to authenticate to the token endpoint as described in [client authentication](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication). +The `key` parameter is optional. The key will be used to sign ID tokens for the client. +It cannot be modified after creation. If not supplied, defaults to the built-in +[default key](/docs/concepts/oidc-provider#keys). -The `key` parameter is required. The user must create a `key` as a required parameter of the client configuration. +A `client_id` is generated and returned after a successful client registration. The +`client_id` uniquely identifies the client. Its value will be a string with 32 random +characters from the base62 character set. ~> **Note**: At least one of the redirect URIs of a client must exactly match the `redirect_uri` parameter used in an authentication request initiated by the client. +#### Client Types + +A client resource has a `client_type` parameter which specifies the OAuth 2.0 +[client type](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1) based on +its ability to maintain confidentiality of credentials. The following sections detail +the differences between confidential and public clients in Vault. + +##### Confidential + +Confidential clients are capable of maintaining the confidentiality of their credentials. +Confidential clients have a `client_secret`. The `client_secret` will have a prefix of +`hvo_secret` followed by 64 random characters in the base62 character set. + +Confidential clients may use Proof Key for Code Exchange ([PKCE](https://datatracker.ietf.org/doc/html/rfc7636)) +during the authorization code flow. + +Confidential clients must authenticate to the token endpoint using the +`client_secret_basic` [client authentication method](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication). + +##### Public + +Public clients are not capable of maintaining the confidentiality of their credentials. +As such, public clients do not have a `client_secret`. + +Public clients must use Proof Key for Code Exchange ([PKCE](https://datatracker.ietf.org/doc/html/rfc7636)) +during the authorization code flow. + +Public clients use the `none` [client authentication method](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication). + ### Assignments Assignment resources are referenced by clients via the `assignments` parameter. This parameter limits the set of Vault users allowed to authenticate. The assignments of an associated client are validated during the authentication request, ensuring that the Vault identity associated with the request is a member of the assignment's entities or groups. +Each Vault namespace will contain a built-in assignment resource named `allow_all`. The +`allow_all` assignment allows all Vault entities to authenticate through a client. The +`allow_all` assignment cannot be modified or deleted. + ### Keys -Key resources are referenced by clients via the key parameter. This parameter specifies the key that will be used to sign ID tokens for the client. See existing [documentation](/api-docs/secret/identity/tokens#create-a-named-key) for details on keyring management, supported signing algorithms, rotation periods, and verification TTLs. Currently, a key referenced by a client cannot be changed. +Key resources are referenced by clients via the `key` parameter. This parameter specifies the key that will be used to sign ID tokens for the client. See existing [documentation](/api-docs/secret/identity/tokens#create-a-named-key) for details on keyring management, supported signing algorithms, rotation periods, and verification TTLs. Currently, a key referenced by a client cannot be changed. + +Each Vault namespace will contain a built-in key resource named `default`. Clients that don't +specify the `key` parameter at creation time will use the `default` key. The `default` key +will use the `RS256` signing algorithm, allow all client IDs, and have rotation and verification +TTLs of `24h`. The `default` key can be modified but not deleted. ## OIDC flow @@ -127,6 +175,10 @@ The following sections provide implementation details for the OIDC compliant API Vault OIDC providers enable registered clients to authenticate and obtain identity information (or "claims") for their end-users. They do this by providing the APIs and behavior required to satisfy the OIDC specification for the [authorization code flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth). All clients are treated as first-party. This means that end-users will not be required to provide consent to the provider as detailed in section [3.1.2.4](https://openid.net/specs/openid-connect-core-1_0.html#Consent) of the OIDC specification. The provider will release information to clients as long as the end-user has ACL access to the provider and their identity has been authorized via an assignment. +Vault OIDC providers implement Proof Key for Code Exchange ([PKCE](https://datatracker.ietf.org/doc/html/rfc7636)) +to mitigate authorization code interception attacks. PKCE is required for `public` client types +and optional for `confidential` client types. + ### OpenID configuration Each provider offers an unauthenticated endpoint that facilitates OIDC Discovery. All required metadata listed in [OpenID Provider Metadata](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata) is included in the discovery document. Additionally, the recommended `userinfo_endpoint` and `scopes_supported` metadata are included. diff --git a/website/content/docs/secrets/identity/oidc-provider.mdx b/website/content/docs/secrets/identity/oidc-provider.mdx index 05225109d01b..f755420852fc 100644 --- a/website/content/docs/secrets/identity/oidc-provider.mdx +++ b/website/content/docs/secrets/identity/oidc-provider.mdx @@ -7,130 +7,162 @@ description: >- # OIDC Identity Provider -~> **Note:** This feature is currently a ***Tech Preview*** and not recommended -for deployment in production. - -Vault as an OIDC identity provider allows clients speaking the OIDC protocol to -take advantage of Vault's various authentication methods and source of -identity. Clients can configure their authentication logic to talk to Vault. -Once enabled, Vault will act as the bridge to identity providers via its -existing authentication methods. Clients will also obtain identity information -for their end-users by leveraging custom templating of Vault identity -information. For more information on the configuration resources and OIDC endpoints, +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. Clients 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. -The Vault OIDC provider feature currently only supports the -[authorization code flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth). - -## OIDC Provider Configuration +## 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. -Most secrets engines must be configured in advance before they can perform -their functions. These steps are usually completed by an operator or -configuration management tool. +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. -1. Create a key that will be used to sign/verify ID tokens: - ```text - $ vault write identity/oidc/key/my-key \ - allowed_client_ids="xxAQWBYzD2WXsB8GiZqwq4jsUwfG0hJV" \ - verification_ttl="1h" \ - rotation_period="1h" \ - algorithm="RS256" - Success! Data written to: identity/oidc/key/my-key - ``` +The following steps show a minimal configuration that allows a client application to use +Vault as an OIDC provider. -1. Create an assignment. This specifies which Vault entities and groups are -authorized to use a specific OIDC client for authentication flows: +1. Enable a Vault auth method: ```text - $ vault write identity/oidc/assignment/my-assignment \ - group_ids="b6ea7804-acbd-e866-7c51-0896456bd4bb" \ - entity_ids="aa786a7a-da2f-dca7-3680-0710771cca51" - Success! Data written to: identity/oidc/assignment/my-assignment + $ vault auth enable userpass + Success! Enabled userpass auth method at: userpass/ ``` -1. Create the 'user' custom scope: + Any Vault auth method may be used within the OIDC flow. For simplicity, enable the + `userpass` auth method. + +2. Create a user: ```text - $ TOKEN_TEMPLATE=$(cat << EOF - { - "username": {{identity.entity.aliases.$MOUNT_ACCESSOR.name}}, - "contact": { - "email": {{identity.entity.metadata.email}}, - "phone_number": {{identity.entity.metadata.phone_number}} - }, - "groups": {{identity.entity.groups.names}} - } - EOF - ) - $ vault write identity/oidc/scope/user \ - description="Scope for user metadata" \ - template="$(echo $TOKEN_TEMPLATE | base64 -)" - Success! Data written to: identity/oidc/scope/user + $ vault write auth/userpass/users/end-user password="securepassword" + Success! Data written to: auth/userpass/users/end-user ``` -1. Create an OIDC client: + 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). + +3. Create a client application: ```text $ vault write identity/oidc/client/my-webapp \ - redirect_uris="http://127.0.0.1:8251/callback,http://127.0.0.1:8500/ui/oidc/callback" \ - assignments="my-assignment" \ - key="my-key" \ - id_token_ttl="30m" \ - access_token_ttl="1h" + redirect_uris="https://localhost:9702/auth/oidc-callback" \ + assignments="allow_all" Success! Data written to: identity/oidc/client/my-webapp ``` -1. Create an OIDC provider: + 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. - ```text - $ vault write identity/oidc/provider/my-provider \ - allowed_client_ids="xxAQWBYzD2WXsB8GiZqwq4jsUwfG0hJV" \ - scopes_supported="user" - Success! Data written to: identity/oidc/provider/my-provider - ``` + 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. -1. Query the OIDC provider configuration: +5. Read client credentials: ```text - $ curl -s http://127.0.0.1:8200/v1/identity/oidc/provider/my-provider/.well-known/openid-configuration - { - "issuer": "http://127.0.0.1:8200/v1/identity/oidc/provider/my-provider", - "jwks_uri": "http://127.0.0.1:8200/v1/identity/oidc/provider/my-provider/.well-known/keys", - "authorization_endpoint": "http://127.0.0.1:8200/ui/vault/identity/oidc/provider/my-provider/authorize", - "token_endpoint": "http://127.0.0.1:8200/v1/identity/oidc/provider/my-provider/token", - "userinfo_endpoint": "http://127.0.0.1:8200/v1/identity/oidc/provider/my-provider/userinfo", - "request_uri_parameter_supported": false, - "id_token_signing_alg_values_supported": [ - "RS256", - "RS384", - "RS512", - "ES256", - "ES384", - "ES512", - "EdDSA" - ], - "response_types_supported": [ - "code" - ], - "scopes_supported": [ - "user", - "openid" - ], - "subject_types_supported": [ - "public" - ], - "grant_types_supported": [ - "authorization_code" - ], - "token_endpoint_auth_methods_supported": [ - "client_secret_basic" - ] - } + $ 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. + +6. 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_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" + ] + } + ``` + + 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). + +## Learn + +Refer to the [Vault as an OIDC Identity Provider](https://learn.hashicorp.com/tutorials/vault/oidc-identity-provider) +guide for an advanced tutorial on configuring 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