HashiCorp Vault's revocation list not respected

@@ -1033,3 +1033,310 @@ func TestLoadConfigFile_EnforceConsistency(t *testing.T) {
 		t.Fatal(diff)
 	}
 }
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_All(t *testing.T) {
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-all.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{"auto-auth", "caching", "templating"},
+		DisableIdleConnsCaching:    true,
+		DisableIdleConnsAutoAuth:   true,
+		DisableIdleConnsTemplating: true,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_Auto_Auth(t *testing.T) {
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-auto-auth.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{"auto-auth"},
+		DisableIdleConnsCaching:    false,
+		DisableIdleConnsAutoAuth:   true,
+		DisableIdleConnsTemplating: false,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_Templating(t *testing.T) {
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-templating.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{"templating"},
+		DisableIdleConnsCaching:    false,
+		DisableIdleConnsAutoAuth:   false,
+		DisableIdleConnsTemplating: true,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_Caching(t *testing.T) {
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-caching.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{"caching"},
+		DisableIdleConnsCaching:    true,
+		DisableIdleConnsAutoAuth:   false,
+		DisableIdleConnsTemplating: false,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_Empty(t *testing.T) {
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-empty.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{},
+		DisableIdleConnsCaching:    false,
+		DisableIdleConnsAutoAuth:   false,
+		DisableIdleConnsTemplating: false,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_Env(t *testing.T) {
+	err := os.Setenv(DisableIdleConnsEnv, "auto-auth,caching,templating")
+	defer os.Unsetenv(DisableIdleConnsEnv)
+ 
+	if err != nil {
+		t.Fatal(err)
+	}
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-empty.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{"auto-auth", "caching", "templating"},
+		DisableIdleConnsCaching:    true,
+		DisableIdleConnsAutoAuth:   true,
+		DisableIdleConnsTemplating: true,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Bad_Value_Disable_Idle_Conns(t *testing.T) {
+	_, err := LoadConfig("./test-fixtures/bad-config-disable-idle-connections.hcl")
+	if err == nil {
+		t.Fatal("should have error, it didn't")
+	}
+}

@@ -0,0 +1,228 @@
+---
+layout: docs
+page_title: OIDC Provider Setup - Auth Methods - Kubernetes
+description: OIDC provider configuration for Kubernetes
+---
+ 
+## Kubernetes
+ 
+Kubernetes can function as an OIDC provider such that Vault can validate its
+service account tokens using JWT/OIDC auth.
+ 
+-> **Note:** The JWT auth engine does **not** use Kubernetes' `TokenReview` API
+during authentication, and instead uses public key cryptography to verify the
+contents of JWTs. This means tokens that have been revoked by Kubernetes will
+still be considered valid by Vault until their expiry time. To mitigate this
+risk, use short TTLs for service account tokens or use
+[Kubernetes auth](/docs/auth/kubernetes) which _does_ use the `TokenReview` API.
+ 
+### Using service account issuer discovery
+ 
+When using service account issuer discovery, you only need to provide the JWT
+auth mount with an OIDC discovery URL, and sometimes a TLS certificate authority
+to trust. This makes it the most straightforward method to configure if your
+Kubernetes cluster meets the requirements.
+ 
+Kubernetes cluster requirements:
+ 
+* [`ServiceAccountIssuerDiscovery`][k8s-sa-issuer-discovery] feature enabled.
+  * Present from 1.18, defaults to enabled from 1.20.
+* kube-apiserver's `--service-account-issuer` flag is set to a URL that is
+  reachable from Vault. Public by default for most managed Kubernetes solutions.
+* Must use short-lived service account tokens when logging in.
+  * Tokens mounted into pods default to short-lived from 1.21.
+ 
+Configuration steps:
+ 
+1. Ensure OIDC discovery URLs do not require authentication, as detailed
+   [here][k8s-sa-issuer-discovery]:
+ 
+   ```bash
+   kubectl create clusterrolebinding oidc-reviewer  \
+      --clusterrole=system:service-account-issuer-discovery \
+      --group=system:unauthenticated
+   ```
+ 
+1. Find the issuer URL of the cluster.
+ 
+   ```bash
+   ISSUER="$(kubectl get --raw /.well-known/openid-configuration | jq -r '.issuer')"
+   ```
+ 
+1. Enable and configure JWT auth in Vault.
+ 
+  1. If Vault is running in Kubernetes:
+ 
+     ```bash
+     kubectl exec vault-0 -- vault auth enable jwt
+     kubectl exec vault-0 -- vault write auth/jwt/config \
+        oidc_discovery_url=https://kubernetes.default.svc.cluster.local \
+        oidc_discovery_ca_pem=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
+     ```
+ 
+  1. Alternatively, if Vault is _not_ running in Kubernetes:
+ 
+     -> **Note:** When Vault is outside the cluster, the `$ISSUER` endpoint below may
+     or may not be reachable. If not, you can configure JWT auth using
+     [`jwt_validation_pubkeys`](#using-jwt-validation-public-keys) instead.
+ 
+     ```bash
+     vault auth enable jwt
+     vault write auth/jwt/config oidc_discovery_url="${ISSUER}"
+     ```
+ 
+1. Configure a role and log in as detailed [below](#creating-a-role-and-logging-in).
+ 
+[k8s-sa-issuer-discovery]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery
+ 
+### Using JWT validation public keys
+ 
+This method can be useful if Kubernetes' API is not reachable from Vault or if
+you would like a single JWT auth mount to service multiple Kubernetes clusters
+by chaining their public signing keys.
+ 
+Kubernetes cluster requirements:
+ 
+* [`ServiceAccountIssuerDiscovery`][k8s-sa-issuer-discovery] feature enabled.
+  * Present from 1.18, defaults to enabled from 1.20.
+  * This requirement can be avoided if you can access the Kubernetes master
+    nodes to read the public signing key directly from disk at
+    `/etc/kubernetes/pki/sa.pub`. In this case, you can skip the steps to
+    retrieve and then convert the key as it will already be in PEM format.
+* Must use short-lived service account tokens when logging in.
+  * Tokens mounted into pods default to short-lived from 1.21.
+ 
+Configuration steps:
+ 
+1. Fetch the service account signing public key from your cluster's JWKS URI.
+ 
+   ```bash
+   # Query the jwks_uri specified in /.well-known/openid-configuration
+   kubectl get --raw "$(kubectl get --raw /.well-known/openid-configuration | jq -r '.jwks_uri' | sed -r 's/.*\.[^/]+(.*)/\1/')"
+   ```
+ 
+1. Convert the keys from JWK format to PEM. You can use a CLI tool or an online
+   converter such as [this one][jwk-to-pem].
+ 
+1. Configure the JWT auth mount with those public keys.
+ 
+   ```bash
+   vault write auth/jwt/config \
+      jwt_validation_pubkeys="-----BEGIN PUBLIC KEY-----
+   MIIBIjANBgkqhkiG9...
+   -----END PUBLIC KEY-----","-----BEGIN PUBLIC KEY-----
+   MIIBIjANBgkqhkiG9...
+   -----END PUBLIC KEY-----"
+   ```
+ 
+1. Configure a role and log in as detailed [below](#creating-a-role-and-logging-in).
+ 
+[jwk-to-pem]: https://8gwifi.org/jwkconvertfunctions.jsp
+ 
+### Creating a role and logging in
+ 
+Once your JWT auth mount is configured, you're ready to configure a role and
+log in. The following assumes you use the projected service account token
+available in all pods by default. See [Specifying TTL and audience](#specifying-ttl-and-audience)
+below if you'd like to control the audience or TTL.
+ 
+1. Choose any value from the array of default audiences. In these examples,
+   there is only one audience in the `aud` array,
+   `https://kubernetes.default.svc.cluster.local`.
+ 
+   To find the default audiences, either create a fresh token (requires
+   `kubectl` v1.24.0+):
+ 
+   ```shell-session
+   $ kubectl create token default | cut -f2 -d. | base64 --decode
+   {"aud":["https://kubernetes.default.svc.cluster.local"], ... "sub":"system:serviceaccount:default:default"}
+   ```
+ 
+   Or read a token from a running pod's filesystem:
+ 
+   ```shell-session
+   $ kubectl exec my-pod -- cat /var/run/secrets/kubernetes.io/serviceaccount/token | cut -f2 -d. | base64 --decode
+   {"aud":["https://kubernetes.default.svc.cluster.local"], ... "sub":"system:serviceaccount:default:default"}
+   ```
+ 
+1. Create a role for JWT auth that the `default` service account from the
+   `default` namespace can use.
+ 
+   ```bash
+   vault write auth/jwt/role/my-role \
+      role_type="jwt" \
+      bound_audiences="<AUDIENCE-FROM-PREVIOUS-STEP>" \
+      user_claim="sub" \
+      bound_subject="system:serviceaccount:default:default" \
+      policies="default" \
+      ttl="1h"
+   ```
+ 
+1. Pods or other clients with access to a service account JWT can then log in.
+ 
+   ```bash
+   vault write auth/jwt/login \
+      role=my-role \
+      jwt=@/var/run/secrets/kubernetes.io/serviceaccount/token
+   # OR equivalent to:
+   curl \
+      --fail \
+      --request POST \
+      --header "X-Vault-Request: true" \
+      --data '{"jwt":"<JWT-TOKEN-HERE>","role":"my-role"}' \
+      "${VAULT_ADDR}/v1/auth/jwt/login"
+   ```
+ 
+### Specifying TTL and audience
+ 
+If you would like to specify a custom TTL or audience for service account tokens,
+the following pod spec illustrates a volume mount that overrides the default
+admission injected token. This is especially relevant if you are unable to
+disable the [--service-account-extend-token-expiration][k8s-extended-tokens]
+flag for `kube-apiserver` and want to use short TTLs.
+ 
+When using the resulting token, you will need to set `bound_audiences=vault`
+when creating roles in Vault's JWT auth mount.
+ 
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  # automountServiceAccountToken is redundant in this example because the
+  # mountPath used overlaps with the default path. The overlap stops the default
+  # admission injected token from being created. You can use this option to
+  # ensure only a single token is mounted if you choose a different mount path.
+  automountServiceAccountToken: false
+  containers:
+    - name: nginx
+      image: nginx
+      volumeMounts:
+      - name: custom-token
+        mountPath: /var/run/secrets/kubernetes.io/serviceaccount
+  volumes:
+  - name: custom-token
+    projected:
+      defaultMode: 420
+      sources:
+      - serviceAccountToken:
+          path: token
+          expirationSeconds: 600 # 10 minutes is the minimum TTL
+          audience: vault        # Must match your JWT role's `bound_audiences`
+      # The remaining sources are included to mimic the rest of the default
+      # admission injected volume.
+      - configMap:
+          name: kube-root-ca.crt
+          items:
+          - key: ca.crt
+            path: ca.crt
+      - downwardAPI:
+          items:
+          - fieldRef:
+              apiVersion: v1
+              fieldPath: metadata.namespace
+            path: namespace
+```
+ 
+[k8s-extended-tokens]: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/#options

@@ -0,0 +1,107 @@
+---
+layout: docs
+page_title: OIDC Provider Setup - Auth Methods - Google
+description: OIDC provider configuration for Google
+---
+ 
+## Google
+ 
+Main reference: [Using OAuth 2.0 to Access Google APIs](https://developers.google.com/identity/protocols/OAuth2)
+ 
+1. Visit the [Google API Console](https://console.developers.google.com).
+1. Create or a select a project.
+1. Create a new credential via Credentials > Create Credentials > OAuth Client ID.
+1. Configure the OAuth Consent Screen. Application Name is required. Save.
+1. Select application type: "Web Application".
+1. Configure Authorized Redirect URIs.
+1. Save client ID and secret.
+ 
+### Optional Google-specific Configuration
+ 
+Google-specific configuration is available when using Google as an identity provider from the
+Vault JWT/OIDC auth method. The configuration allows Vault to obtain Google Workspace group membership and
+user information during the JWT/OIDC authentication flow. The group membership obtained from Google Workspace
+may be used for Identity group alias association. The user information obtained from Google Workspace can be
+used to copy claims data into resulting auth token and alias metadata via [claim_mappings](/api-docs/auth/jwt#claim_mappings).
+ 
+#### Setup
+ 
+To set up the Google-specific handling, you'll need:
+ 
+- A Google Workspace account with the [super admin role](https://support.google.com/a/answer/2405986?hl=en)
+  for granting domain-wide delegation API client access.
+- The ability to create a service account in [Google Cloud Platform](https://console.developers.google.com/iam-admin/serviceaccounts).
+- To enable the [Admin SDK API](https://console.developers.google.com/apis/api/admin.googleapis.com/overview).
+- An OAuth 2.0 application with an [external user type](https://support.google.com/cloud/answer/10311615#user-type).
+ 
+The Google-specific handling that's used to fetch Google Workspace groups and user information in Vault uses
+[Google Workspace Domain-Wide Delegation of Authority](https://developers.google.com/admin-sdk/directory/v1/guides/delegation)
+for authentication and authorization. You need to follow **all steps** in the [guide](https://developers.google.com/admin-sdk/directory/v1/guides/delegation)
+to obtain the key file for a Google service account capable of making requests to the Google Workspace
+[User Accounts](https://developers.google.com/admin-sdk/directory/v1/guides/manage-users) and
+[Groups](https://developers.google.com/admin-sdk/directory/v1/guides/manage-groups) APIs.
+ 
+In **step 5** within the section titled
+[Delegate domain-wide authority to your service account](https://developers.google.com/admin-sdk/directory/v1/guides/delegation#delegate_domain-wide_authority_to_your_service_account),
+the only OAuth scopes that should be granted are:
+ 
+- `https://www.googleapis.com/auth/admin.directory.group.readonly`
+- `https://www.googleapis.com/auth/admin.directory.user.readonly`
+ 
+~> This is an **important security step** in order to give the service account the least set of privileges
+that enable the feature.
+ 
+The Google service account key file obtained from the steps in the guide must be made available on the
+host that Vault is running on.
+ 
+#### Configuration
+ 
+- `provider` `(string: <required>)` - Name of the provider. Must be set to "gsuite".
+- `gsuite_service_account` `(string: <required>)` - Either the path to or the contents of a Google service
+  account key file in JSON format. If given as a file path, it must refer to a file that's readable on
+  the host that Vault is running on. If given directly as JSON contents, the JSON must be properly escaped.
+- `gsuite_admin_impersonate` `(string: <required>)` - Email address of a Google Workspace admin to impersonate.
+- `fetch_groups` `(bool: false)` - If set to true, groups will be fetched from Google Workspace.
+- `fetch_user_info` `(bool: false)` - If set to true, user info will be fetched from Google Workspace using the configured [user_custom_schemas](#user_custom_schemas).
+- `groups_recurse_max_depth` `(int: <optional>)` - Group membership recursion max depth. Defaults to 0, which means don't recurse.
+- `user_custom_schemas` `(string: <optional>)` - Comma-separated list of Google Workspace [custom schemas](https://developers.google.com/admin-sdk/directory/v1/guides/manage-schemas).
+  Values set for Google Workspace users using custom schema fields will be fetched and made available as claims that can be used with [claim_mappings](/api-docs/auth/jwt#claim_mappings). Required if [fetch_user_info](#fetch_user_info) is set to true.
+ 
+Example configuration:
+ 
+```
+vault write auth/oidc/config -<<EOF
+{
+    "oidc_discovery_url": "https://accounts.google.com",
+    "oidc_client_id": "your_client_id",
+    "oidc_client_secret": "your_client_secret",
+    "default_role": "your_default_role",
+    "provider_config": {
+        "provider": "gsuite",
+        "gsuite_service_account": "/path/to/service-account.json",
+        "gsuite_admin_impersonate": "admin@gsuitedomain.com",
+        "fetch_groups": true,
+        "fetch_user_info": true,
+        "groups_recurse_max_depth": 5,
+        "user_custom_schemas": "Education,Preferences"
+    }
+}
+EOF
+```
+ 
+#### Role
+ 
+The [user_claim](/api-docs/auth/jwt#user_claim) value of the role must be set to
+one of either `sub` or `email` for the Google Workspace group and user information
+queries to succeed.
+ 
+Example role:
+ 
+```
+vault write auth/oidc/role/your_default_role \
+    allowed_redirect_uris="http://localhost:8200/ui/vault/auth/oidc/oidc/callback,http://localhost:8250/oidc/callback" \
+    user_claim="sub" \
+    groups_claim="groups" \
+    claim_mappings="/Education/graduation_date"="graduation_date" \
+    claim_mappings="/Preferences/shirt_size"="shirt_size"
+```

@@ -0,0 +1,127 @@
+---
+layout: docs
+page_title: OIDC Provider Setup - Auth Methods - Azure Active Directory
+description: OIDC provider configuration for Azure Active Directory
+---
+ 
+## Azure Active Directory (AAD)
+ 
+~> **Note:** Azure Active Directory Applications that have custom signing keys as a result of using
+the [claims-mapping](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-claims-mapping)
+feature are currently not supported for OIDC authentication.
+ 
+Reference: [Azure Active Directory v2.0 and the OpenID Connect protocol](https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc)
+ 
+1. Choose your Azure tenant.
+ 
+1. Go to **Azure Active Directory** and
+   [register an application](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app)
+   for Vault.
+ 
+1. Add Redirect URIs with the "Web" type. You may include two redirect URIs,
+   one for CLI access another one for Vault UI access.
+  - `http://localhost:8250/oidc/callback`
+  - `https://hostname:port_number/ui/vault/auth/oidc/oidc/callback`
+ 
+1. Record the "Application (client) ID" as you will need it as the `oidc_client_id`.
+ 
+1. Under **Endpoints**, copy the OpenID Connect metadata document URL, omitting the `/well-known...` portion.
+  - The endpoint URL (`oidc_discovery_url`) will look like: https://login.microsoftonline.com/tenant-guid-dead-beef-aaaa-aaaa/v2.0
+ 
+1. Under **Certificates & secrets**,
+   [add a client secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#add-a-client-secret)
+   Record the secret's value as you will need it as the `oidc_client_secret` for Vault.
+ 
+### Connect AD group with Vault external group
+ 
+Reference: [Azure Active Directory with OIDC Auth Method and External Groups](https://learn.hashicorp.com/tutorials/vault/oidc-auth-azure)
+ 
+To connect the AD group with a [Vault external groups](/docs/secrets/identity#external-vs-internal-groups),
+you will need
+[Azure AD v2.0 endpoints](https://docs.microsoft.com/en-gb/azure/active-directory/develop/azure-ad-endpoint-comparison).
+You should set up a [Vault policy](https://learn.hashicorp.com/tutorials/vault/policies) for the Azure AD group to use.
+ 
+1. Go to **Azure Active Directory** and choose your Vault application.
+ 
+1. Go to **Token configuration** and **Add groups claim**. Select "All" or "SecurityGroup" based on
+   [which groups for a user](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims)
+   you want returned in the claim.
+ 
+1. In Vault, enable the OIDC auth method.
+ 
+1. Configure the OIDC auth method with the `oidc_client_id` (application ID), `oidc_client_secret`
+   (client secret), and `oidc_discovery_url` (endpoint URL) you recorded from Azure.
+   ```shell
+   vault write auth/oidc/config \
+      oidc_client_id="your_client_id" \
+      oidc_client_secret="your_client_secret" \
+      default_role="your_default_role" \
+      oidc_discovery_url="https://login.microsoftonline.com/tenant_id/v2.0"
+   ```
+ 
+1. Configure the [OIDC Role](/api-docs/auth/jwt#create-role) with the following:
+  - `user_claim` should be `"sub"` or `"oid"` following the
+  [recommendation](https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens#using-claims-to-reliably-identify-a-user-subject-and-object-id)
+  from Azure.
+  - `allowed_redirect_uris` should be the two redirect URIs for Vault CLI and UI access.
+  - `groups_claim` should be set to `"groups"`.
+  - `oidc_scopes` should be set to `"https://graph.microsoft.com/.default"`.
+   ```shell
+   vault write auth/oidc/role/your_default_role \
+      user_claim="sub" \
+      allowed_redirect_uris="http://localhost:8250/oidc/callback,https://online_version_hostname:port_number/ui/vault/auth/oidc/oidc/callback"  \
+      groups_claim="groups" \
+      oidc_scopes="https://graph.microsoft.com/.default" \
+      policies=default
+   ```
+ 
+1. In Vault, create the [external group](/api-docs/secret/identity/group).
+   Record the group ID as you will need it for the group alias.
+ 
+1. From Vault, retrieve the [OIDC accessor ID](/api-docs/system/auth#list-auth-methods)
+   from the OIDC auth method as you will need it for the group alias's `mount_accessor`.
+ 
+1. Go to the Azure AD Group you want to attach to Vault's external group. Record the `objectId`
+   as you will need it as the group alias name in Vault.
+ 
+1. In Vault, create a [group alias](/api-docs/secret/identity/group-alias)
+   for the external group and set the `objectId` as the group alias name.
+   ```shell
+   vault write identity/group-alias \
+      name="your_ad_group_object_id" \
+      mount_accessor="vault_oidc_accessor_id" \
+      canonical_id="vault_external_group_id"
+   ```
+ 
+### Optional Azure-specific Configuration
+ 
+If a user is a member of more than 200 groups (directly or indirectly), extra configuration
+is required so that Vault can fetch the groups properly.
+ 
+- In Azure, under the applications **API Permissions**, grant the following permissions:
+  - Microsoft Graph API permission [Directory.Read.All](https://docs.microsoft.com/en-us/graph/permissions-reference#application-permissions-19)
+ 
+- In Vault, set `"provider_config"` to Azure.
+  ```shell
+  vault write auth/oidc/config -<<"EOH"
+  {
+     "oidc_client_id": "your_client_id",
+     "oidc_client_secret": "your_client_secret",
+     "default_role": "your_default_role",
+     "oidc_discovery_url": "https://login.microsoftonline.com/tenant_id/v2.0",
+     "provider_config": {
+        "provider": "azure"
+     }
+  }
+  EOH
+  ```
+ 
+- In Vault, add `"profile"` to `oidc_scopes` so the user's id comes back on the JWT.
+  ```shell
+  vault write auth/oidc/role/your_default_role \
+   user_claim="email" \
+   allowed_redirect_uris="http://localhost:8250/oidc/callback,https://online_version_hostname:port_number/ui/vault/auth/oidc/oidc/callback"  \
+   groups_claim="groups" \
+   oidc_scopes="profile" \
+   policies="default"
+  ```

@@ -9,17 +9,36 @@ description: >-
  
 ## What is Vault?
  
-Vault is an identity-based **secrets** and encryption management system. A secret is anything that you want to tightly control access to, such as API encryption keys, passwords, or certificates. Vault provides encryption services that are gated by authentication and authorization methods. Using Vault’s UI, CLI, or HTTP API, access to secrets and other sensitive data can be securely stored and managed, tightly controlled (restricted), and auditable.
+HashiCorp Vault is an identity-based secrets and encryption management system. A _secret_ is anything that you want to tightly control access to, such as API encryption keys, passwords, and certificates. Vault provides encryption services that are gated by authentication and authorization methods. Using Vault’s UI, CLI, or HTTP API, access to secrets and other sensitive data can be securely stored and managed, tightly controlled (restricted), and auditable.
  
-A modern system requires access to a multitude of secrets: database credentials,
+A modern system requires access to a multitude of secrets, including database credentials,
 API keys for external services, credentials for service-oriented architecture
-communication, etc. Understanding who is accessing what secrets is already very
-difficult and platform-specific. Adding on key rolling, secure storage, and
+communication, etc. It can be difficult to understand who is accessing which secrets, especially since this can be platform-specific. Adding on key rolling, secure storage, and
 detailed audit logs is almost impossible without a custom solution. This is
 where Vault steps in.
  
-Examples work best to showcase Vault. Please see the
-[use cases](/docs/use-cases).
+Vault validates and authorizes clients (users, machines, apps) before providing them access to secrets or stored sensitive data.
+ 
+![How Vault Works](/img/how-vault-works.png)
+ 
+### How does Vault work?
+ 
+Vault works primarily with tokens and a token is associated to the client's policy. Each policy is path-based and policy rules contrains the actions and accessibility to the paths for each client. With Vault, you can create tokens manually and assign them to your clients, or the clients can log in and obtain a token. The illustration below displays Vault's core workflow.
+ 
+![Vault Workflow](/img/vault-workflow-diagram1.png)
+ 
+ The core Vault workflow consists of four stages:
+ 
+* **Authenticate:** Authentication in Vault is the process by which a client supplies information that Vault uses to determine if they are who they say they are. Once the client is authenticated against an auth method, a token is generated and associated to a policy.
+* **Validation:** Vault validates the client against third-party trusted sources, such as Github, LDAP, AppRole, and more.
+* **Authorize**: A client is matched against the Vault security policy.  This policy is a set of rules defining which API endpoints a client has access to with its Vault token. Policies provide a declarative way to grant or forbid access to certain paths and operations in Vault.
+* **Access**: Vault grants access to secrets, keys, and encryption capabilities by issuing a token based on policies associated with the client’s identity. The client can then use their Vault token for future operations.
+ 
+### Why Vault?
+ 
+Most enterprises today have credentials sprawled across their organizations. Passwords, API keys, and credentials are stored in plain text, app source code, config files, and other locations. Because these credentials live everywhere, the sprawl can make it difficult and daunting to really know who has access and authorization to what. Having credentials in plain text also increases the potential for malicious attacks, both by internal and external attackers.
+ 
+Vault was designed with these challenges in mind. Vault takes all of these credentials and centralizes them so that they are defined in one location, which reduces unwanted exposure to credentials. But Vault takes it a few steps further by making sure users, apps, and systems are authenticated and explicitly authorized to access resources, while also providing an audit trail that captures and preserves a history of clients' actions.
  
 The key features of Vault are:
  
@@ -51,16 +70,18 @@ The key features of Vault are:
   Revocation assists in key rolling as well as locking down systems in the
   case of an intrusion.
  
-## What is HCP Vault?
+-> **Tip**: Learn more about Vault [use cases](/docs/use-cases).
+ 
+### What is HCP Vault?
  
-HCP Vault is a hosted version of Vault, which is operated by HashiCorp to allow organizations to get up and running quickly. HCP Vault uses the same binary as self-hosted Vault, which means you will have a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with a self-hosted Vault.
+HashiCorp Cloud Platform (HCP) Vault is a hosted version of Vault, which is operated by HashiCorp to allow organizations to get up and running quickly. HCP Vault uses the same binary as self-hosted Vault, which means you will have a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with a self-hosted Vault. Refer to the [HCP Vault](https://cloud.hashicorp.com/docs/vault) documentation to learn more.
  
-~> **Note**: Currently, HCP Vault clusters are located on AWS running in multiple regions across North America, Asia, and Europe. We will support additional cloud providers in the future.
+> **Hands On:** Try the [Get started](https://learn.hashicorp.com/collections/vault/cloud) tutorial on HashiCorp Learn to set up a managed Vault cluster.
  
-To learn more about HCP Vault, see the [HCP Vault documentation](https://cloud.hashicorp.com/docs/vault). You can also get started with HCP Vault by using the HCP portal to set up your managed Vault cluster. Refer to the [Getting Started with HCP Vault](https://learn.hashicorp.com/collections/vault/cloud) tutorial.
+### Community
  
-## Next Steps
+We welcome questions, suggestions, and contributions from the community.
  
-See the page on [Vault use cases](/docs/use-cases) to learn about the multiple ways
-Vault can be used. Then, continue onwards with the [Getting Started](https://learn.hashicorp.com/collections/vault/getting-started) tutorial to use Vault
-to read, write, and create real secrets and see how it works in practice.
+* Ask questions in [HashiCorp Discuss](https://discuss.hashicorp.com/c/vault/30).
+* Read our [contributing guide](https://github.com/hashicorp/tutorials/blob/main/CONTRIBUTING.md).
+* [Submit an issue](https://github.com/hashicorp/vault/issues/new/choose) for bugs and feature requests.

@@ -0,0 +1,42 @@
+---
+layout: docs
+page_title: OIDC Provider Setup - Auth Methods - ForgeRock
+description: OIDC provider configuration for ForgeRock
+---
+ 
+## ForgeRock
+ 
+1. Navigate to Applications -> OAuth 2.0 -> Clients in ForgeRock Access Management.
+1. Create new client.
+1. Configure Client ID, Client Secret, Scopes and Redirection URIs.
+  - `client ID`
+  - `client secret`
+  - `allowed_redirect_uris` should be the two redirect URIs for Vault CLI and UI access.
+  - `oidc_scopes` should be set to the OIDC scopes.
+1. Save Client ID and Client Secret.
+ 
+### Configuration
+ 
+1. In Vault, enable the OIDC auth method.
+ 
+1. Configure the OIDC auth method with the `oidc_client_id` (client ID), `oidc_client_secret`
+   (client secret), and `oidc_discovery_url` (endpoint URL) from ForgeRock.
+   ```shell
+   vault write auth/oidc/config \
+      oidc_client_id="your_client_id" \
+      oidc_client_secret="your_client_secret" \
+      default_role="your_default_role" \
+      oidc_discovery_url="https://openam.example.com:8443/openam/oauth2"
+   ```
+ 
+1. Configure the [OIDC Role](/api-docs/auth/jwt) with the following:
+  - `user_claim` should be `"sub"`.
+  - `allowed_redirect_uris` should be the two redirect URIs for Vault CLI and UI access.
+  - `oidc_scopes` should be set to the OIDC scopes.
+   ```shell
+   vault write auth/oidc/role/your_default_role \
+      user_claim="sub" \
+      allowed_redirect_uris="http://localhost:8250/oidc/callback,https://online_version_hostname:port_number/ui/vault/auth/oidc/oidc/callback"  \
+      oidc_scopes="your_oidc_scopes" \
+      policies=default
+   ```

@@ -0,0 +1,25 @@
+---
+layout: docs
+page_title: OIDC Provider Setup - Auth Methods
+description: OIDC provider configuration quick starts
+---
+ 
+# OIDC Provider Configuration
+ 
+This page collects high-level setup steps on how to configure an OIDC
+application for various providers. For more general usage and operation
+information, see the [Vault JWT/OIDC method documentation](/docs/auth/jwt).
+ 
+OIDC providers are often highly configurable, and you should become familiar with
+their recommended settings and best practices. The guides listed below are
+largely community-driven and intended to help you get started. Corrections
+and additions may be submitted via the [Vault Github repository](https://github.com/hashicorp/vault).
+ 
+- [Auth0](/docs/auth/jwt/oidc-providers/auth0)
+- [Azure AD](/docs/auth/jwt/oidc-providers/azuread)
+- [ForgeRock](/docs/auth/jwt/oidc-providers/forgerock)
+- [Gitlab](/docs/auth/jwt/oidc-providers/gitlab)
+- [Google](/docs/auth/jwt/oidc-providers/google)
+- [Keycloak](/docs/auth/jwt/oidc-providers/keycloak)
+- [Kubernetes](/docs/auth/jwt/oidc-providers/kubernetes)
+- [Okta](/docs/auth/jwt/oidc-providers/kubernetes)

@@ -783,22 +783,24 @@ func signCert(b *backend,
 		// We update the value of KeyBits and SignatureBits here (from the
 		// role), using the specified key type. This allows us to convert
 		// the default value (0) for SignatureBits and KeyBits to a
-		// meaningful value. In the event KeyBits takes a zero value, we also
-		// update that to a new value.
+		// meaningful value.
 		//
-		// This is mandatory because on some roles, with KeyType any, we'll
-		// set a default SignatureBits to 0, but this will need to be updated
-		// in order to behave correctly during signing.
-		roleBitsWasZero := data.role.KeyBits == 0
-		if data.role.KeyBits, data.role.SignatureBits, err = certutil.ValidateDefaultOrValueKeyTypeSignatureLength(actualKeyType, data.role.KeyBits, data.role.SignatureBits); err != nil {
+		// We ignore the role's original KeyBits value if the KeyType is any
+		// as legacy (pre-1.10) roles had default values that made sense only
+		// for RSA keys (key_bits=2048) and the older code paths ignored the role value
+		// set for KeyBits when KeyType was set to any. This also enforces the
+		// docs saying when key_type=any, we only enforce our specified minimums
+		// for signing operations
+		if data.role.KeyBits, data.role.SignatureBits, err = certutil.ValidateDefaultOrValueKeyTypeSignatureLength(
+			actualKeyType, 0, data.role.SignatureBits); err != nil {
 			return nil, errutil.InternalError{Err: fmt.Sprintf("unknown internal error updating default values: %v", err)}
 		}
  
-		// We're using the KeyBits field as a minimum value, and P-224 is safe
+		// We're using the KeyBits field as a minimum value below, and P-224 is safe
 		// and a previously allowed value. However, the above call defaults
-		// to P-256 as that's a saner default than P-224 (w.r.t. generation).
-		// So, override our fake Role value if it was previously zero.
-		if actualKeyType == "ec" && roleBitsWasZero {
+		// to P-256 as that's a saner default than P-224 (w.r.t. generation), so
+		// override it here to allow 224 as the smallest size we permit.
+		if actualKeyType == "ec" {
 			data.role.KeyBits = 224
 		}
 	}

@@ -24,14 +24,20 @@ import (
 type Config struct {
 	*configutil.SharedConfig `hcl:"-"`
  
-	AutoAuth       *AutoAuth                  `hcl:"auto_auth"`
-	ExitAfterAuth  bool                       `hcl:"exit_after_auth"`
-	Cache          *Cache                     `hcl:"cache"`
-	Vault          *Vault                     `hcl:"vault"`
-	TemplateConfig *TemplateConfig            `hcl:"template_config"`
-	Templates      []*ctconfig.TemplateConfig `hcl:"templates"`
+	AutoAuth                   *AutoAuth                  `hcl:"auto_auth"`
+	ExitAfterAuth              bool                       `hcl:"exit_after_auth"`
+	Cache                      *Cache                     `hcl:"cache"`
+	Vault                      *Vault                     `hcl:"vault"`
+	TemplateConfig             *TemplateConfig            `hcl:"template_config"`
+	Templates                  []*ctconfig.TemplateConfig `hcl:"templates"`
+	DisableIdleConns           []string                   `hcl:"disable_idle_connections"`
+	DisableIdleConnsCaching    bool                       `hcl:"-"`
+	DisableIdleConnsTemplating bool                       `hcl:"-"`
+	DisableIdleConnsAutoAuth   bool                       `hcl:"-"`
 }
  
+const DisableIdleConnsEnv = "VAULT_AGENT_DISABLE_IDLE_CONNECTIONS"
+ 
 func (c *Config) Prune() {
 	for _, l := range c.Listeners {
 		l.RawConfig = nil
@@ -260,6 +266,28 @@ func LoadConfig(path string) (*Config, error) {
 		result.Vault.Retry.NumRetries = 0
 	}
  
+	if disableIdleConnsEnv := os.Getenv(DisableIdleConnsEnv); disableIdleConnsEnv != "" {
+		result.DisableIdleConns, err = parseutil.ParseCommaStringSlice(strings.ToLower(disableIdleConnsEnv))
+		if err != nil {
+			return nil, fmt.Errorf("error parsing environment variable %s: %v", DisableIdleConnsEnv, err)
+		}
+	}
+ 
+	for _, subsystem := range result.DisableIdleConns {
+		switch subsystem {
+		case "auto-auth":
+			result.DisableIdleConnsAutoAuth = true
+		case "caching":
+			result.DisableIdleConnsCaching = true
+		case "templating":
+			result.DisableIdleConnsTemplating = true
+		case "":
+			continue
+		default:
+			return nil, fmt.Errorf("unknown disable_idle_connections value: %s", subsystem)
+		}
+	}
+ 
 	return result, nil
 }
  

@@ -377,8 +377,8 @@ export default Service.extend({
   },
  
   async authSuccess(options, response) {
-    // persist selectedAuth to sessionStorage to rehydrate auth form on logout
-    sessionStorage.setItem('selectedAuth', options.selectedAuth);
+    // persist selectedAuth to localStorage to rehydrate auth form on logout
+    localStorage.setItem('selectedAuth', options.selectedAuth);
     const authData = await this.persistAuthData(options, response, this.namespaceService.path);
     await this.permissions.getPaths.perform();
     return authData;
@@ -397,8 +397,8 @@ export default Service.extend({
   },
  
   getAuthType() {
-    // check sessionStorage first
-    const selectedAuth = sessionStorage.getItem('selectedAuth');
+    // check localStorage first
+    const selectedAuth = localStorage.getItem('selectedAuth');
     if (selectedAuth) return selectedAuth;
     // fallback to authData which discerns backend type from token
     return this.authData ? this.authData.backend.type : null;

@@ -18,6 +18,8 @@ services and applications to perform cryptographic operations without having to
 manage cryptographic material, otherwise known as managed objects, by delegating
 its storage and lifecycle to a key management server.
  
+Vault's KMIP secrets engine listens on a separate port from the standard Vault listener. Each Vault server in a Vault cluster configured with a KMIP secrets engine uses the same listener configuration. The KMIP listener defaults to port 5696 and is configurable to alternative ports, for example, if there are multiple KMIP secrets engine mounts configured.  KMIP clients connect and authenticate to this KMIP secrets engine listener port using generated TLS certificates. KMIP clients may connect directly to any of the Vault servers on the configured KMIP port. A layer 4 tcp load balancer may be used in front of the Vault server's KMIP ports. The load balancer should support long-lived connections and it may use a round robin routing algorithm as Vault servers will forward to the primary Vault server, if necessary.
+ 
 ## KMIP Conformance
  
 Vault implements version 1.4 of the following Key Management Interoperability Protocol Profiles:
 <82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
 cd3a0b6914e14b49515270659c83bc04a8596d8a (#16247)
 website/content/docs/commands/index.mdx    | 18 ++++++++++--
 website/content/docs/concepts/policies.mdx | 33 +++++++++++++---------
 2 files changed, 34 insertions(+), 17 deletions(-)

@@ -0,0 +1,102 @@
+---
+layout: api
+page_title: /sys/loggers - HTTP API
+description: The `/sys/loggers` endpoint is used modify the verbosity level of logging.
+---
+ 
+# `/sys/loggers`
+ 
+The `/sys/loggers` endpoint is used modify the verbosity level of logging.
+ 
+## Modify verbosity level of all loggers
+ 
+| Method  | Path           |
+| :------ | :------------- |
+| `POST`  | `/sys/loggers` |
+ 
+### Parameters
+ 
+- `level` `(string: <required>)` – Specifies the log verbosity level to be set for all loggers.
+Supported values (in order of detail) are `"trace"`, `"debug"`, `"info"`, `"warn"`, and `"error"`.
+ 
+### Sample Payload
+ 
+```json
+{
+  "level": "debug",
+}
+```
+ 
+### Sample Request
+ 
+```shell-session
+$ curl \
+    --header "X-Vault-Token: ..." \
+    --request POST \
+    --data @payload.json \
+    http://127.0.0.1:8200/v1/sys/loggers
+```
+ 
+## Modify verbosity level of a single logger
+ 
+| Method  | Path                 |
+| :------ | :------------------- |
+| `POST`  | `/sys/loggers/:name` |
+ 
+### Parameters
+ 
+- `name` `(string: <required>)` – Specifies the logger to be modified (e.g. `audit`, `core`, `expiration`).
+- `level` `(string: <required>)` – Specifies the log verbosity level to be set for the provided logger.
+Supported values (in order of detail) are `"trace"`, `"debug"`, `"info"`, `"warn"`, and `"error"`.
+ 
+### Sample Payload
+ 
+```json
+{
+  "level": "debug",
+}
+```
+ 
+### Sample Request
+ 
+```shell-session
+$ curl \
+    --header "X-Vault-Token: ..." \
+    --request POST \
+    --data @payload.json \
+    http://127.0.0.1:8200/v1/sys/loggers/core
+```
+ 
+## Revert verbosity of all loggers to configured level
+ 
+| Method    | Path           |
+| :-------- | :------------- |
+| `DELETE`  | `/sys/loggers` |
+ 
+### Sample Request
+ 
+```shell-session
+$ curl \
+    --header "X-Vault-Token: ..." \
+    --request DELETE \
+    http://127.0.0.1:8200/v1/sys/loggers
+```
+ 
+## Revert verbosity of a single logger to configured level
+ 
+| Method    | Path                 |
+| :-------- | :------------------- |
+| `DELETE`  | `/sys/loggers/:name` |
+ 
+### Parameters
+ 
+- `name` `(string: <required>)` – Specifies the logger to be modified (e.g. `audit`, `core`, `expiration`).
+ 
+### Sample Request
+ 
+```shell-session
+$ curl \
+    --header "X-Vault-Token: ..." \
+    --request DELETE \
+    http://127.0.0.1:8200/v1/sys/loggers/core
+```

@@ -57,13 +57,29 @@ KV store:
 {{ end }}
 ```
  
-The following is an example of a template that retrieves a PKI certificate from
-Vault's PKI secrets engine. The fetching of a certificate from a PKI role
+The following is an example of a template that issues a PKI certificate in
+Vault's PKI secrets engine. The fetching of the certificate or key from a PKI role
 through this function will be based on the certificate's expiration.
+ 
+To generate a new certificate and create a bundle with the key, certificate, and CA, use:
 ```
-{{ pkiCert "pki/issue/my-domain-dot-com" "common_name=foo.example.com" }}
+{{ with pkiCert "pki/issue/my-domain-dot-com" "common_name=foo.example.com" }}
+{{ .Data.Key }}
+{{ .Data.Cert }}
+{{ .Data.CA }}
+{{ end }}
 ```
  
+To fetch only the issuing CA for this mount, use:
+ 
+```
+{{- with secret "pki/cert/ca" -}}
+{{ .Data.certificate }}
+{{- end -}}
+```
+ 
+Alternatively, `pki/cert/ca_chain` can be used to fetch the full CA chain.
+ 
 ## Global Configurations
  
 The top level `template_config` block has the following configuration entries that affect
 builtin/credential/aws/path_config_rotate_root_test.go | 1 -
 command/operator_diagnose.go                           | 2 +-
 helper/identity/sentinel.go                            | 1 +
 plugins/database/mssql/mssql.go                        | 2 +-
 vault/cluster.go                                       | 3 +--
 vault/ha.go                                            | 3 ++-
 6 files changed, 6 insertions(+), 6 deletions(-)

@@ -318,14 +318,19 @@ func (c *Core) startClusterListener(ctx context.Context) error {
 	networkLayer := c.clusterNetworkLayer
  
 	if networkLayer == nil {
-		networkLayer = cluster.NewTCPLayer(c.clusterListenerAddrs, c.logger.Named("cluster-listener.tcp"))
+		tcpLogger := c.logger.Named("cluster-listener.tcp")
+		networkLayer = cluster.NewTCPLayer(c.clusterListenerAddrs, tcpLogger)
+		c.AddLogger(tcpLogger)
 	}
  
+	listenerLogger := c.logger.Named("cluster-listener")
 	c.clusterListener.Store(cluster.NewListener(networkLayer,
 		c.clusterCipherSuites,
-		c.logger.Named("cluster-listener"),
+		listenerLogger,
 		5*c.clusterHeartbeatInterval))
  
+	c.AddLogger(listenerLogger)
+ 
 	err := c.getClusterListener().Run(ctx)
 	if err != nil {
 		return err

@@ -12,6 +12,7 @@ For upgrade instructions, see [upgrading](/docs/platform/mssql/upgrading).
 ## Prerequisites
  
 * Vault Enterprise server 1.9+ with a license for the Advanced Data Protection Key Management module
+* Microsoft Windows Server operating system
 * Microsoft SQL Server for Windows (SQL Server for Linux [does not support EKM][linux-ekm])
 * An authenticated Vault client
  
@@ -40,7 +41,7 @@ EKM provider to use it.
  
     ```bash
     vault auth enable approle
-    vault write auth/approle/role/tde-role \
+    vault write auth/approle/role/ekm-encryption-key-role \
         token_ttl=20m \
         max_token_ttl=30m \
         token_policies=tde-policy
@@ -158,6 +159,10 @@ installation.
     PROVIDER_KEY_NAME = 'ekm-encryption-key';
     ```
  
+    -> **Note:** This is the first step at which the EKM provider will communicate with Vault. If
+    Vault is misconfigured, this step is likely to fail. See
+    [troubleshooting](/docs/platform/mssql/troubleshooting) for tips on specific error codes.
+ 
 1. Create another login from the new asymmetric key:
  
     ```sql
@@ -244,4 +249,4 @@ GO
 ALTER DATABASE ENCRYPTION KEY
 ENCRYPTION BY SERVER ASYMMETRIC KEY TransitVaultAsymmetric;
 GO
-```
+```

@@ -0,0 +1,304 @@
+---
+layout: docs
+page_title: Vault Lambda Extension Caching
+description: >-
+  Supports caching to the local proxy server for the Vault Lambda Extension.
+---
+ 
+# Vault Lambda Extension
+ 
+AWS Lambda lets you run code without provisioning and managing servers.
+You can use the [quick-start](https://github.com/hashicorp/vault-lambda-extension/tree/0af1a648bfa4b9f37a04dd4311d8355f5c3902c3/quick-start) directory which has an end-to-end example if you would like to try out the extension from scratch.
+ 
+~> **Note**: If you decide to create one from scratch, be aware that this will create real infrastructure with an associated cost as per AWS' pricing.
+ 
+## Usage
+ 
+To use the extension, include the following ARN as a layer in your Lambda function:
+ 
+```text
+arn:aws:lambda:us-east-1:634166935893:layer:vault-lambda-extension:11
+```
+ 
+Where region may be any of `af-south-1`, `ap-east-1`, `ap-northeast-1`,
+`ap-northeast-2`, `ap-northeast-3`, `ap-south-1`, `ap-southeast-1`,
+`ap-southeast-2`, `ca-central-1`, `eu-central-1`, `eu-north-1`, `eu-south-1`,
+`eu-west-1`, `eu-west-2`, `eu-west-3`, `me-south-1`, `sa-east-1`, `us-east-1`,
+`us-east-2`, `us-west-1`, `us-west-2`.
+ 
+The extension authenticates with Vault using [AWS IAM auth](/docs/auth/aws),
+and all configuration is supplied via environment variables. There are two methods
+to read secrets, which can both be used side-by-side:
+ 
+- **Recommended**: Make unauthenticated requests to the extension's local proxy
+  server at `http://127.0.0.1:8200`, which will add an authentication header and
+  proxy to the configured `VAULT_ADDR`. Responses from Vault are returned without
+  modification.
+- Configure environment variables such as `VAULT_SECRET_PATH` for the extension
+  to read a secret and write it to disk.
+ 
+### Adding the extension to your existing Lambda and Vault infrastructure
+ 
+#### Requirements
+ 
+- ARN of the role your Lambda runs as
+- An instance of Vault accessible from AWS Lambda
+- An authenticated `vault` client
+- A secret in Vault that you want your Lambda to access, and a policy giving read access to it
+- Your Lambda function must use one of the [supported runtimes][lambda-supported-runtimes] for extensions
+ 
+#### Step 1. Configure Vault
+ 
+Enable the aws auth method.
+ 
+```shell-session
+$ vault auth enable aws
+```
+ 
+Configure the AWS client to use the default options.
+ 
+```shell-session
+$ vault write -force auth/aws/config/client
+```
+ 
+Create a role prefixed with the AWS environment name.
+ 
+```shell-session
+$ vault write auth/aws/role/vault-lambda-role \
+    auth_type=iam \
+    bound_iam_principal_arn="${YOUR_ARN}" \
+    policies="${YOUR_POLICY}" \
+    ttl=1h
+```
+ 
+#### Step 2. Option a) Install the extension for Lambda functions packaged in zip archives
+ 
+If you deploy your Lambda function as a zip file, you can add the extension
+to your Lambda layers using the console or [cli](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html#configuration-layers-using):
+ 
+```text
+arn:aws:lambda:<your-region>:634166935893:layer:vault-lambda-extension:11
+```
+ 
+#### Step 2. Option b) Install the extension for Lambda functions packaged in container images
+ 
+Alternatively, if you deploy your Lambda function as a container image, simply
+place the built binary in the `/opt/extensions` directory of your image.
+ 
+Fetch the binary from
+[releases.hashicorp.com](https://releases.hashicorp.com/vault-lambda-extension/).
+The following command requires cURL.
+ 
+```shell-session
+$ curl --silent https://releases.hashicorp.com/vault-lambda-extension/0.5.0/vault-lambda-extension_0.5.0_linux_amd64.zip \
+  --output vault-lambda-extension.zip
+```
+ 
+Unzip the donwloaded binary.
+ 
+```shell-session
+$ unzip vault-lambda-extension.zip
+```
+ 
+Optionally, you can verify the integrity of the downloaded zip using the release
+archive checksum verification instructions
+[here](https://www.hashicorp.com/security).
+ 
+Or to build the binary from source. This requires Golang installed. Run from the root of this repository.
+ 
+```shell-session
+$ GOOS=linux GOARCH=amd64 go build -o vault-lambda-extension main.go
+```
+ 
+#### Step 3. Configure vault-lambda-extension
+ 
+Configure the extension using [Lambda environment
+variables](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html):
+ 
+Set the Vault API address.
+ 
+```shell-session
+$ VAULT_ADDR=http://vault.example.com:8200
+```
+ 
+Set the AWS IAM auth mount point (i.e. the path segment after `auth/` from above).
+ 
+```shell-session
+$ VAULT_AUTH_PROVIDER=aws
+```
+ 
+Set the Vault role to authenticate as. Must be configured for the ARN of your
+Lambda's role.
+ 
+```shell-session
+$ VAULT_AUTH_ROLE=vault-lambda-role
+```
+ 
+The path to a secret in Vault. Can be static or dynamic. Unless
+VAULT_SECRET_FILE is specified, JSON response will be written to
+`/tmp/vault/secret.json`.
+ 
+```shell-session
+$ VAULT_SECRET_PATH=secret/lambda-app/token
+```
+ 
+If everything is correctly set up, your Lambda function can then read secret
+material from `/tmp/vault/secret.json`. The exact contents of the JSON object
+will depend on the secret read, but its schema is the [Secret struct](https://github.com/hashicorp/vault/blob/api/v1.0.4/api/secret.go#L15)
+from the Vault API module.
+ 
+Alternatively, you can send normal Vault API requests over HTTP to the local
+proxy at `http://127.0.0.1:8200`, and the extension will add authentication
+before forwarding the request. Vault responses will be returned unmodified.
+Although local communication is over plain HTTP, the proxy server will use TLS
+to communicate with Vault if configured to do so as detailed below.
+ 
+## Configuration
+ 
+The extension is configured via [Lambda environment variables](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html).
+Most of the [Vault CLI client's environment variables](/docs/commands#environment-variables) are available,
+as well as some additional variables to configure auth, which secret(s) to read and
+where to write secrets.
+ 
+| Environment variable              | Description                                                                                                                                                                                                                                                                                                           | Required | Example value               |
+| --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | --------------------------- |
+| `VLE_VAULT_ADDR`                  | Vault address to connect to. Takes precedence over `VAULT_ADDR` so that clients of the proxy server can be configured using the standard `VAULT_ADDR`                                                                                                                                                                 | No       | `https://x.x.x.x:8200`      |
+| `VAULT_ADDR`                      | Vault address to connect to if `VLE_VAULT_ADDR` is not set. Required if `VLE_VAULT_ADDR` is not set                                                                                                                                                                                                                   | No       | `https://x.x.x.x:8200`      |
+| `VAULT_AUTH_PROVIDER`             | Name of the configured AWS IAM auth route on Vault                                                                                                                                                                                                                                                                    | Yes      | `aws`                       |
+| `VAULT_AUTH_ROLE`                 | Vault role to authenticate as                                                                                                                                                                                                                                                                                         | Yes      | `lambda-app`                |
+| `VAULT_IAM_SERVER_ID`             | Value to pass to the Vault server via the [`X-Vault-AWS-IAM-Server-ID` HTTP Header for AWS Authentication](/api-docs/auth/aws#iam_server_id_header_value)                                                                                                                                                             | No       | `vault.example.com`         |
+| `VAULT_SECRET_PATH`               | Secret path to read, written to `/tmp/vault/secret.json` unless `VAULT_SECRET_FILE` is specified                                                                                                                                                                                                                      | No       | `database/creds/lambda-app` |
+| `VAULT_SECRET_FILE`               | Path to write the JSON response for `VAULT_SECRET_PATH`                                                                                                                                                                                                                                                               | No       | `/tmp/db.json`              |
+| `VAULT_SECRET_PATH_FOO`           | Additional secret path to read, where FOO can be any name, as long as a matching `VAULT_SECRET_FILE_FOO` is specified                                                                                                                                                                                                 | No       | `secret/lambda-app/token`   |
+| `VAULT_SECRET_FILE_FOO`           | Must exist for any correspondingly named `VAULT_SECRET_PATH_FOO`. Name has no further effect beyond matching to the correct path variable                                                                                                                                                                             | No       | `/tmp/token`                |
+| `VAULT_TOKEN_EXPIRY_GRACE_PERIOD` | Period at the end of the proxy server's auth token TTL where it will consider the token expired and attempt to re-authenticate to Vault. Must have a unit and be parseable by `time.Duration`. Defaults to 10s.                                                                                                       | No       | `1m`                        |
+| `VAULT_STS_ENDPOINT_REGION`       | The region of the STS regional endpoint to authenticate with. If the AWS IAM auth mount specified uses a regional STS endpoint, then this needs to match the region of that endpoint. Defaults to using the global endpoint, or the region the Lambda resides in if `AWS_STS_REGIONAL_ENDPOINTS` is set to `regional` | No       | `eu-west-1`                 |
+ 
+The remaining environment variables are not required, and function exactly as
+described in the [Vault Commands (CLI)](/docs/commands#environment-variables) documentation. However,
+note that `VAULT_CLIENT_TIMEOUT` cannot extend the timeout beyond the 10s
+initialization timeout imposed by the Extensions API when writing files to disk.
+ 
+| Environment variable          | Description                                                                                                                                                                     | Required | Example value       |
+| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------- |
+| `VAULT_CACERT`                | Path to a PEM-encoded CA certificate _file_ on the local disk                                                                                                                   | No       | `/tmp/ca.crt`       |
+| `VAULT_CAPATH`                | Path to a _directory_ of PEM-encoded CA certificate files on the local disk                                                                                                     | No       | `/tmp/certs`        |
+| `VAULT_CLIENT_CERT`           | Path to a PEM-encoded client certificate on the local disk                                                                                                                      | No       | `/tmp/client.crt`   |
+| `VAULT_CLIENT_KEY`            | Path to an unencrypted, PEM-encoded private key on disk which corresponds to the matching client certificate                                                                    | No       | `/tmp/client.key`   |
+| `VAULT_CLIENT_TIMEOUT`        | Timeout for Vault requests. Default value is 60s. Ignored by proxy server. **Any value over 10s will exceed the Extensions API timeout and therefore have no effect**           | No       | `5s`                |
+| `VAULT_MAX_RETRIES`           | Maximum number of retries on `5xx` error codes. Defaults to 2. Ignored by proxy server                                                                                          | No       | `2`                 |
+| `VAULT_SKIP_VERIFY`           | Do not verify Vault's presented certificate before communicating with it. Setting this variable is not recommended and voids Vault's [security model](/docs/internals/security) | No       | `true`              |
+| `VAULT_TLS_SERVER_NAME`       | Name to use as the SNI host when connecting via TLS                                                                                                                             | No       | `vault.example.com` |
+| `VAULT_RATE_LIMIT`            | Only applies to a single invocation of the extension. See [Vault Commands (CLI)](/docs/commands#environment-variables) documentation for details. Ignored by proxy server       | No       | `10`                |
+| `VAULT_NAMESPACE`             | The namespace to use for pre-configured secrets. Ignored by proxy server                                                                                                        | No       | `education`         |
+| `VAULT_DEFAULT_CACHE_TTL`     | The time to live configuration (aka, TTL) of the cache used by proxy server. Must have a unit and be parsable as a time.Duration. Required for caching to be enabled.           | No       | `15m`               |
+| `VAULT_DEFAULT_CACHE_ENABLED` | Enable caching for all requests, without needing to set the X-Vault-Cache-Control header for each request. Must be set to a boolean value.                                      | No       | `true`              |
+ 
+### AWS STS client configuration
+ 
+In addition to Vault configuration, you can configure certain aspects of the STS
+client the extension uses through the usual AWS environment variables. For example,
+if your Vault instance's IAM auth is configured to use regional STS endpoints:
+ 
+```shell-session
+$ vault write auth/aws/config/client \
+     sts_endpoint="https://sts.eu-west-1.amazonaws.com" \
+     sts_region="eu-west-1"
+```
+ 
+Then you may need to configure the extension's STS client to also use the regional
+STS endpoint by setting `AWS_STS_REGIONAL_ENDPOINTS=regional`, because both the AWS Golang
+SDK and Vault IAM auth method default to using the global endpoint in many regions.
+See documentation on [`sts_regional_endpoints`](https://docs.aws.amazon.com/credref/latest/refdocs/setting-global-sts_regional_endpoints.html) for more information.
+ 
+### Caching
+ 
+Caching can be configured for the extension's local proxy server so that it does
+not forward every HTTP request to Vault. The main consideration behind caching
+design is to make caching an explicit opt-in at the request level, so that it is
+only enabled for scenarios where caching makes sense without negative impact in
+others. To turn on caching, set the environment variable
+`VAULT_DEFAULT_CACHE_TTL` to a valid value that is parsable as a time.Duration
+in Go, for example, "15m", "1h", "2m3s" or "1h2m3s", depending on application
+needs. An invalid or negative value will be treated the same as a missing value,
+in which case, caching will not be set up and enabled.
+ 
+Then requests with HTTP method of "GET", and the HTTP header
+`X-Vault-Cache-Control: cache` will be returned directly from the cache if
+there's a cache hit. On a cache miss the request will be forwarded to Vault and
+the response returned and cached. If the header is set to
+`X-Vault-Cache-Control: recache`, the cache lookup will be skipped, and the
+request will be forwarded to Vault and the response returned and cached.
+Currently, the cache key is a hash of the request URL path, headers, body, and
+token.
+ 
+Caching may also be enabled for all requests by setting the environment variable
+`VAULT_DEFAULT_CACHE_ENABLE` to `true`. Then all requests will be fetched and/or
+cached as though the header `X-Vault-Cache-Control: cache` was present. Setting
+the header to `nocache` on a request will opt-out of caching entirely in this
+configuration. Setting the header to `recache` will skip the cache lookup and
+return and cache the response from Vault as described previously.
+ 
+## Limitations
+ 
+Secrets written to disk or returned from the proxy server will not be automatically
+refreshed when they expire. This is particularly important if you configure the
+extension to write secrets to disk, because the extension will only write to disk
+once per execution environment, rather than once per function invocation. If you
+use [provisioned concurrency](https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html#configuration-concurrency-provisioned) or if your Lambda
+is invoked often enough that execution contexts live beyond the lifetime of the
+secret, then secrets on disk are likely to become invalid.
+ 
+In line with [Lambda best practices](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html), we recommend avoiding
+writing secrets to disk where possible, and exclusively consuming secrets via
+the proxy server. However, the proxy server will still not perform any additional
+processing with returned secrets such as automatic lease renewal. The proxy server's
+own Vault auth token is the only thing that gets automatically refreshed. It will
+synchronously refresh its own token before proxying requests if the token is
+expired (including a grace window), and it will attempt to renew its token if the
+token is nearly expired but renewable.
+ 
+## Performance impact
+ 
+AWS Lambda pricing is based on [number of invocations, time of execution and memory
+used](https://aws.amazon.com/lambda/pricing/). The following table details some approximate performance
+related statistics to help assess the cost impact of this extension. Note that AWS
+Lambda allocates [CPU power in proportion to memory](https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html) so results
+will vary widely. These benchmarks were run with the minimum 128MB of memory allocated
+so aim to give an approximate baseline.
+ 
+| Metric         | Value                                                                              | Description                                                                                                                      | Derivation                                                                         |
+| -------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
+| Layer size     | 8.5MB                                                                              | The size of the unpacked extension binary                                                                                        | `ls -la`                                                                           |
+| Init latency   | 8.5ms (standard deviation 2.4ms) + one network round trip to authenticate to Vault | Extension initialization time in a new execution environment. Authentication round trip time will be highly deployment-dependent | Instrumented in code                                                               |
+| Invoke latency | <1ms                                                                               | The base processing time for each function invocation, assuming no calls to the proxy server                                     | Instrumented in code                                                               |
+| Memory impact  | 12MB                                                                               | The marginal impact on "Max Memory Used" when running the extension                                                              | As reported by Lambda when running Hello World function with and without extension |
+ 
+## Uploading to your own AWS account and region
+ 
+If you would like to upload the extension as a Lambda layer in your own AWS
+account and region, you can do the following:
+ 
+```shell-session
+$ curl --silent https://releases.hashicorp.com/vault-lambda-extension/0.5.0/vault-lambda-extension_0.5.0_linux_amd64.zip \
+  --output vault-lambda-extension.zip
+```
+ 
+Set your target AWS region.
+ 
+```shell-session
+$ export REGION="YOUR REGION HERE"
+```
+ 
+Upload the extension as a Lambda layer.
+ 
+```shell-session
+$ aws lambda publish-layer-version \
+     --layer-name vault-lambda-extension \
+     --zip-file  "fileb://vault-lambda-extension.zip" \
+     --region "${REGION}"
+```
+ 
+## Learn
+ 
+For step-by-step instructions, refer to the [Vault AWS Lambda Extension](https://learn.hashicorp.com/tutorials/vault/aws-lambda) tutorial for details on how to create an AWS Lambda function and use the Vault Lambda Extension to authenticate with Vault.

@@ -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. 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.
  
-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
 actions-packaging-linux@v1 (#14642)
 .github/workflows/build.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@@ -0,0 +1,151 @@
+---
+layout: docs
+page_title: 1.10
+description: |-
+  This page contains release notes for Vault 1.10
+---
+ 
+# Vault 1.10 Release notes
+ 
+**Software Release date:** Mar 23, 2022
+ 
+**Summary:** Vault version 1.10 offers features and enhancements that improve the user experience while closing the loop on key issues previously encountered by our customers. We are providing a summary of these improvements in these release notes.
+ 
+We encourage you to upgrade to the latest release to take advantage of the new benefits that we are providing. Additionally, with this latest release, we offer solutions to critical feature gaps that have been identified previously. For further information on product improvements, including a comprehensive list of bug fixes, please refer to the [Changelog](https://github.com/hashicorp/vault/blob/main/CHANGELOG.md) within the Vault 1.10 release.
+ 
+Some of these enhancements and changes in this release include:
+ 
+- Ability to view client counts per auth and changes to clients over months, therefore, providing more granular visibility into clients.
+- Extended the `sys/remount` API endpoint to support moving secrets engines and auth method mounts from one location to another, within a namespace or across namespaces.
+- Improved security posture that includes MFA on login for Vault OSS customers.
+- Ability to implicitely achieve consistency via tokens.
+- Support of PKCE on Vault’s OIDC auth method with Telemetry support for the Vault Agent.
+- Improvement of key areas and parity to support using Terraform Provider with Vault.
+ 
+## New Features
+ 
+This section describes the new features introduced as part of Vault 1.10
+ 
+### Multi-Factor Authentication (MFA) for Vault OSS
+ 
+Vault has had support for the [Step-up Enterprise MFA](docs/enterprise/mfa) as part of its Enterprise edition. The Step-up Enterprise MFA allows having an MFA on login, or for step-up access to sensitive resources in Vault.
+ 
+With Vault 1.10, MFA as part of [login](/docs/auth.login-mfa) is now supported for Vault OSS. This demonstrates HashiCorp’s thought leadership in security and its continued endeavor to enable all Vault users to employ strong security policies with Vault.
+ 
+~> **Note:** The Legacy MFA in Vault OSS is a [deprecated](https://www.vaultproject.io/docs/deprecation) feature and will be removed in Vault 1.11.
+ 
+Refer to the [Login MFA FAQ](/auth/login-mfa/faq) to understand the various MFA workflows that are supported in Vault 1.10.
+ 
+### Vault OIDC provider with PKCE support
+ 
+Vault’s support to act as an OIDC provider is now generally available. Furthermore, Vault’s OIDC provider functionality can now support PKCE for authorization code flow as well. Thanks to all the excellent community feedback received, we have simplified the user experience around configuration of OIDC provider functionality.
+ 
+### Caching support for Vault Lambda Extension
+ 
+With 0.6.0, Vault Lambda Extension supports [caching](https://github.com/hashicorp/vault-lambda-extension#caching) in the local proxy server to avoid proxying every request to enable setting expiry time and invalidate cache, as needed.
+ 
+### Terraform Provider for Vault
+ 
+We have introduced three new resources to enable configuration of the [KMIP secrets engine](https://registry.terraform.io/providers/hashicorp/vault/latest/docs/resources/kmip_secret_backend) using the Terraform Provider for Vault. In addition, frequent releases on the Terraform Provider for Vault have been incorporating the ability to configure newer resources and data sources. Please read the [documentation](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) for more details.
+ 
+### KV Secrets Engine v2 patch operations
+ 
+We now support an additional method for managing [KV v2 secrets](/api-docs/secret/kv/kv-v2) to maintain least privilege security in certain types of automated environments. This feature creates a new PATCH capability that enables partial updates to KV v2 secrets without requiring the READ privilege to the entire endpoint for an entity.
+ 
+### DB2 Dynamic Secrets support
+ 
+Vault operators can leverage the openldap secrets engine to manage credentials for IBM DB2 and the LDAP security plugin for Db2. This allows Db2 to offload authentication and authorization to the LDAP security plugin and allows Vault to manage static credentials or even generate dynamic users. For more details, refer to the For more details, refer to the [IBM Db2 Credentials Management](https://learn.hashicorp.com/tutorials/vault/ibm-db2-openldap) tutorial.
+ 
+### Temporal Transit Key rotation
+ 
+Proper key management includes occasionally rotating encryption keys to reduce the risks of a nonce reuse and opportunities for keys to be compromised. Previously, there was no automated way to rotate keys that is native to Vault. Now, we have provided a new configuration element on transit keys and tokenization transform configurations where a time interval triggers the keys to automatically rotate after the interval has lapsed.
+ 
+### PKI HSM Forwarding
+ 
+To address security and compliance needs, customers may require that keys be either created or stored within Hardware Security Models (HSMs). Vault 1.10 introduces an accommodation for this requirement with regards to the PKI Secrets Engine. We now support offloading selected PKI operations to HSMs, in particular allowing customers to both generate new PKI key pairs and sign/verify some certificate workflows. All of these operations are conducted in a way that never allows the private key material to leave the secure confines of the HSM itself.
+ 
+### AWS and AKV KMS Forwarding
+ 
+The work done above to support HSM-backed PKI operations inspired us to consider what other key possession paradigms we could support. This led us to extend the implementation to support Cloud Key Management Systems in addition to HSMs. In Vault 1.10, users may generate new PKI pairs and perform sign/verify certificate workflows, all with those keys never leaving the cloud KMS itself. Vault 1.10 provides support for AWS Key Management Service and Azure Key Vault Key Management Service.
+ 
+### Server Side Consisten Tokens
+ 
+Vault’s [eventual consistency](/docs/enterprise/consistency) model precludes read-after-write guarantees when clients interact with performance standbys or performance replication clusters. The [Client Controlled Consistency](/docs/enterprise/consistency#vault-1-7-mitigations) mitigations supported with Vault 1.7 provide ways to achieve consistency through client modifications or by using the agent for proxied requests, which is not possible in all cases. The Server Side Consistent Tokens feature provides an implicit way to achieve consistency by embedding the minimum Write-Ahead-Log state information in the Service tokens returned from logins or token-create requests. This feature introduces changes in the token format and the new tokesn will be the default tokens starting in Vault 1.10. Vault 1.10 is backwards compatible with old tokens.
+ 
+See [Replication](/docs/configuration/replication), [Vault Eventual Consistency](/docs/enterprise/consistency), [Upgrade to 1.10](/docs/upgrading/upgrade-to-1.10.x) and [Service Side Consistent Token FAQ](/docs/faq/ssct) to understand the various consistency options available with Vault 1.10 and the considerations to be aware of prior to selecting an option for your use case.
+ 
+## Vault Agent Features
+ 
+### Support for Telemetry
+ 
+Starting with Vault 1.10, the Vault Agent supports a new metrics endpoint and [Telemetry](/docs/agent#telemetry-stanza) metrics around run time, authentication success, authentication failures, cache hits, cache misses, proxy succes, and proxy client errors. This Vault Agent Telemetry should greatly help with the retrieval of key operational insights for Vault Agent deployments.
+ 
+### User-assigned managed identities for auto auth in Azure
+ 
+With this [enhancement](/docs/agent/autoauth/methods/azure), users can specify user-assigned managed identities via the `object_id` and `client_id` when configuring Vault agent auto-auth for Azure. This enables users that have more than one user-assigned managed identity associated with their VM to specify which one they'd like to use when authenticating via the Vault's Azure auth method. Note that providing these parameters is an "exclusive or" operation.
+ 
+### Quit API endpoint with config
+ 
+Previously, for instances where the Agent is a sidecar in a Kubernetes job and the job hangs, you must either use `shareProcessNamespace: true` for the container so that the process kill signals can be sent, or avoid the sidecar container entirely and solely rely on an init container. With this [enhancement](/docs/agent#quit), we have added support for a Quit API endpoint to automatically shut down the Vault Agent, therefore eliminating the need to perform the workarounds.
+ 
+## Other Features and Enhancements
+ 
+This section describes other features and enhancements introduced as part of the Vault 1.10 release.
+ 
+### Client Count improvements
+ 
+We have introduced auth mount-based attribution of clients to help better understand where clients are being used within a cluster. This is available via UI and API. This is an enhancement on top of the namespace attribution capability we introduced in Vault 1.9.
+ 
+We have also introduced the ability to view changes to clients month over month via the client count API, and made other UI enhancements. Refer to [What is a Client?](/docs/concepts/client-count) and [Client Count FAQ](/docs/concepts/client-count/faq) for more details.
+ 
+### Mount Migration
+ 
+We have made improvements to the `sys/remount` API endpoint to simplify the complexities of moving data, such as secret engine and authentication method configuration from one mount to another, within a namespace or across namespaces. This can help with restructuring namespaces and mounts for various reasons, including migrating mounts from root to other namespaces when transitioning to using namespaces for the first time. For step-by-step instructions, refer to the [Mount Move](https://learn.hashicorp.com/tutorials/vault/mount-move) tutorial.
+ 
+### Scaling External Database plugins
+ 
+Database plugins can now implement [plugin multiplexing](/docs/internals/plugins#plugin-development) which allows a single plugin process to be used for multiple database connections. Database plugin multiplexing will be enabled on the Oracle Database plugin starting in v0.6.0. We will extend this functionality to additional database plugins in subsequent releases.
+ 
+Any external database plugins that want to adopt multiplexing support will have to update their main.go call from [dbplugin.Serve()](https://github.com/hashicorp/vault/blob/sdk/v0.4.1/sdk/database/dbplugin/v5/plugin_server.go#L13) to [dbplugin.ServeMultiplex()](https://github.com/hashicorp/vault/blob/sdk/v0.4.1/sdk/database/dbplugin/v5/plugin_server.go#L42). Multiplexable database plugins are compatible with older versions of Vault down to Vault 1.6. Refer to this [Oracle Database PR](https://github.com/hashicorp/vault-plugin-database-oracle/pull/74) as an example of the upgrade process.
+ 
+### Consul Secrets Engine enhancements
+ 
+Consul has supported [namespace](https://www.consul.io/docs/enterprise/namespaces), [admin partitions](https://www.consul.io/docs/enterprise/admin-partitions) and [ACL roles](https://www.consul.io/commands/acl/role) for some time now. In this release we have added enhancements to the Consul Secrets engine to support [namespace]() awareness and add admin partition and role support for Consul ACL tokens. This significantly simplifies the integrations for customers who want to achieve a zero trust security posture with both Vault and Consul.
+ 
+### Using sessionStorage instead of localStorage for the Vault UI
+ 
+Prior to Vault 1.10, the Vault UI used localStorage to store authentication information. The data in localStorage was persisted in browsers and removed only on demand. Now, we have switched the Vault UI to use sessionStorage instead, which ensures that the authentication information is stored in the current browser tab alone, thereby improving security.
+ 
+### Advanced I/O Handling for Transform FPE
+ 
+The Transform Secrets Engine allows users to securely encrypt data while providing control over the output format. In Vault 1.9, we introduced [additional format fields](/docs/release-notes/1.9.0#advanced-i-o-handling-for-tranform-fpe-adp-transform) on the templates used for this workflow. In Vault 1.10, we have now added those two new fields, `encode_format` and `decode_format`, to the Create Template page on the UI under Advanced Templating.
+ 
+## Breaking changes
+ 
+The following section details breaking changes introduced in Vault 1.10.
+ 
+### LDAP auth method entity alias mapping
+ 
+In Vault 1.9, we added support to provide custom user filters through the [userfilter](/api-docs/auth/ldap#userfilter) parameter. This support changed the way that entity alias was mapped to an entity. Prior to Vault 1.9, alias names were always based on the [login username](/api-docs/auth/ldap#username-3) (which in turn is based on the value of the [userattr](/api-docs/auth/ldap#userattr)). In Vault 1.9, alias names no longer mapped to the login username. Instead, the mapping depends on other config values as well, such as [updomain](/api-docs/auth/ldap#upndomain), [binddn](/api-docs/auth/ldap#binddn), [discoverydn](/api-docs/auth/ldap#discoverdn), and [userattr](/api-docs/auth/ldap#userattr).
+ 
+With Vault 1.10, we re-introduced the option to force the alias name to map to the login username with the optional parameter username_as_alias. Users that have the LDAP auth method enabled prior to Vault 1.9 may want to consider setting this to true to revert back to the old behavior. Otherwise, depending on the other aforementioned config values, logins may generate a new and different entity for an existing user with a previous entity associated in Vault. This in turn affects client counts since there may be more than one entity tied to this user. The username_as_alias flag was also made available in subsequent Vault 1.8.x and Vault 1.9.x releases to allow for this to be set prior to a Vault 1.10 upgrade.
+ 
+## Known issues
+ 
+### Single Vault follower restart causes election even with established quorum
+ 
+We now support Server Side Consistent Tokens (See [Replication](/docs/configuration/replication), [Vault Eventual Consistency](/docs/enterprise/consistency), and [Upgrade to 1.10](/docs/upgrading/upgrade-to-1.10.x).), which introduces a new token format that can only be used on nodes of 1.10 or higher version. This new format is enabled by default upon upgrading to the new version. Old format tokens can be read by Vault 1.10, but the new format Vault 1.10 tokens cannot be read by older Vault versions.
+ 
+For more details, see the [Server Side Consistent Tokens FAQ](/docs/faq/ssct).
+ 
+Since service tokens are always created on the leader, as long as the leader is not upgraded before performance standbys, service tokens will be of the old format and still be usable during the upgrade process. However, the usual upgrade process we recommend can't be relied upon to always upgrade the leader last. Due to this known [issue](https://github.com/hashicorp/vault/issues/14153), a Vault cluster using Integrated Storage may result in a leader not being upgraded last, and this can trigger a re-election. This re-election can cause the upgraded node to become the leader, resulting in the newly created tokens on the leader to be unusable on nodes that have not yet been upgraded. Note that this issue does not impact Vault OSS users.
+ 
+We will have a fix for this issue in Vault 1.10.1. Until this issue is fixed, you may be at risk of having performance standbys unable to service requests until all nodes are upgraded. We recommended that you plan for a maintenance window to upgrade.
+ 
+### Limited policy shows unhelpful message in UI after mounting a secret engine
+ 
+When a user has a policy that allows creating a secret engine but not reading it, after successful creation, the user sees a message `n is undefined` instead of a permissions error. We will have a fix for this issue in an upcoming minor release.
+ 
+## Feature Deprecations and EOL
+ 
+Please refer to the [Deprecation Plans and Notice](/docs/deprecation) page for up-to-date information on feature deprecations and plans. An [Feature Deprecation FAQ](/deprecation/faq) page is also available to address questions concerning decisions made about Vault feature deprecations.

@@ -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:
+A client has 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.

@@ -89,14 +89,14 @@ These metrics represent operational aspects of the running Vault instance.
 | `vault.core.activity.segment_write`                 | Duration of time taken writing activity log segments to storage.                                                                                                                                                                                                                                                                                                                                                                            | ms           | summary |
 | `vault.core.check_token`                            | Duration of time taken by token checks handled by Vault core                                                                                                                                                                                                                                                                                                                                                                                | ms           | summary |
 | `vault.core.fetch_acl_and_token`                    | Duration of time taken by ACL and corresponding token entry fetches handled by Vault core                                                                                                                                                                                                                                                                                                                                                   | ms           | summary |
-| `vault.core.handle_request`                         | Duration of time taken by non-login requests handled by Vault core                                                                                                                                                                                                                                                                                                                                                                                    | ms           | summary |
+| `vault.core.handle_request`                         | Duration of time taken by non-login requests handled by Vault core                                                                                                                                                                                                                                                                                                                                                                          | ms           | summary |
 | `vault.core.handle_login_request`                   | Duration of time taken by login requests handled by Vault core                                                                                                                                                                                                                                                                                                                                                                              | ms           | summary |
 | `vault.core.in_flight_requests`                     | Number of in-flight requests.                                                                                                                                                                                                                                                                                                                                                                                                               | requests     | gauge   |
 | `vault.core.leadership_setup_failed`                | Duration of time taken by cluster leadership setup failures which have occurred in a highly available Vault cluster. This should be monitored and alerted on for overall cluster leadership status.                                                                                                                                                                                                                                         | ms           | summary |
 | `vault.core.leadership_lost`                        | Duration of time taken by cluster leadership losses which have occurred in a highly available Vault cluster. This should be monitored and alerted on for overall cluster leadership status.                                                                                                                                                                                                                                                 | ms           | summary |
-| `vault.core.license.expiration_time_epoch`          | Time as epoch (seconds since Jan 1 1970) at which license will expire.                                                                                                                                                                                                                                                                                                                                                                      | seconds      | gauge  |
-| `vault.core.mount_table.num_entries`                | Number of mounts in a particular mount table. This metric is labeled by table type (auth or logical) and whether or not the table is replicated (local or not)                                                                                                                                                                                                                                                                              | objects      | gauge |
-| `vault.core.mount_table.size`                       | Size of a particular mount table. This metric is labeled by table type (auth or logical) and whether or not the table is replicated (local or not)                                                                                                                                                                                                                                                                                          | objects      | gauge |
+| `vault.core.license.expiration_time_epoch`          | Time as epoch (seconds since Jan 1 1970) at which license will expire.                                                                                                                                                                                                                                                                                                                                                                      | seconds      | gauge   |
+| `vault.core.mount_table.num_entries`                | Number of mounts in a particular mount table. This metric is labeled by table type (auth or logical) and whether or not the table is replicated (local or not)                                                                                                                                                                                                                                                                              | objects      | gauge   |
+| `vault.core.mount_table.size`                       | Size of a particular mount table. This metric is labeled by table type (auth or logical) and whether or not the table is replicated (local or not)                                                                                                                                                                                                                                                                                          | objects      | gauge   |
 | `vault.core.post_unseal`                            | Duration of time taken by post-unseal operations handled by Vault core                                                                                                                                                                                                                                                                                                                                                                      | ms           | summary |
 | `vault.core.pre_seal`                               | Duration of time taken by pre-seal operations                                                                                                                                                                                                                                                                                                                                                                                               | ms           | summary |
 | `vault.core.seal-with-request`                      | Duration of time taken by requested seal operations                                                                                                                                                                                                                                                                                                                                                                                         | ms           | summary |
@@ -119,17 +119,17 @@ These metrics represent operational aspects of the running Vault instance.
  
 These metrics collect information from Vault's Go runtime, such as memory usage information.
  
-| Metric                            | Description                                                                                                                                                  | Unit       | Type   |
-| :-------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------- | :----- |
-| `vault.runtime.alloc_bytes`       | Number of bytes allocated by the Vault process. This could burst from time to time, but should return to a steady state value.                               | bytes      | gauge  |
-| `vault.runtime.free_count`        | Number of freed objects                                                                                                                                      | objects    | gauge  |
-| `vault.runtime.heap_objects`      | Number of objects on the heap. This is a good general memory pressure indicator worth establishing a baseline and thresholds for alerting.                   | objects    | gauge  |
-| `vault.runtime.malloc_count`      | Cumulative count of allocated heap objects                                                                                                                   | objects    | gauge  |
-| `vault.runtime.num_goroutines`    | Number of goroutines. This serves as a general system load indicator worth establishing a baseline and thresholds for alerting.                              | goroutines | gauge  |
-| `vault.runtime.sys_bytes`         | Number of bytes allocated to Vault. This includes what is being used by Vault's heap and what has been reclaimed but not given back to the operating system. | bytes      | gauge  |
-| `vault.runtime.total_gc_pause_ns` | The total garbage collector pause time since Vault was last started                                                                                          | ns         | gauge  |
+| Metric                            | Description                                                                                                                                                  | Unit       | Type    |
+| :-------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------- | :------ |
+| `vault.runtime.alloc_bytes`       | Number of bytes allocated by the Vault process. This could burst from time to time, but should return to a steady state value.                               | bytes      | gauge   |
+| `vault.runtime.free_count`        | Number of freed objects                                                                                                                                      | objects    | gauge   |
+| `vault.runtime.heap_objects`      | Number of objects on the heap. This is a good general memory pressure indicator worth establishing a baseline and thresholds for alerting.                   | objects    | gauge   |
+| `vault.runtime.malloc_count`      | Cumulative count of allocated heap objects                                                                                                                   | objects    | gauge   |
+| `vault.runtime.num_goroutines`    | Number of goroutines. This serves as a general system load indicator worth establishing a baseline and thresholds for alerting.                              | goroutines | gauge   |
+| `vault.runtime.sys_bytes`         | Number of bytes allocated to Vault. This includes what is being used by Vault's heap and what has been reclaimed but not given back to the operating system. | bytes      | gauge   |
+| `vault.runtime.total_gc_pause_ns` | The total garbage collector pause time since Vault was last started                                                                                          | ns         | gauge   |
 | `vault.runtime.gc_pause_ns`       | Total duration of the last garbage collection run                                                                                                            | ns         | summary |
-| `vault.runtime.total_gc_runs`     | Total number of garbage collection runs since Vault was last started                                                                                         | operations | gauge  |
+| `vault.runtime.total_gc_runs`     | Total number of garbage collection runs since Vault was last started                                                                                         | operations | gauge   |
  
 ## Policy Metrics
  
@@ -153,9 +153,8 @@ These metrics cover measurement of token, identity, and lease operations, and co
 | `vault.expire.num_leases`                                                                       | Number of all leases which are eligible for eventual expiry                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         | leases   | gauge   |
 | `vault.expire.num_irrevocable_leases`                                                           | Number of leases that cannot be revoked automatically                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               | leases   | gauge   |
 | `vault.expire.leases.by_expiration` (cluster,gauge,expiring,namespace)                          | Number of leases set to expire, grouped by a time interval. This time interval and total number of time intervals are configurable via `lease_metrics_epsilon` and `num_lease_metrics_buckets` in the telemetry stanza of a vault server configuration. The default values for these are `1hr` and `168` respectively, so the metric will report the number of leases that will expire each hour from the current time to a week from the current time. One can additionally group lease expiration by namespace by setting `add_lease_metrics_namespace_labels` to `true` in the config file (default is `false`). | leases   | gauge   |
-| `vault.expire.lease_expiration`                                                                 | Count of lease expirations                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          | leases   | counter |
-| `vault.expire.job_manager.total_jobs`                                                           | Total pending revocation jobs                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       | leases   | summary  |
-| `vault.expire.job_manager.queue_length`                                                         | Total pending revocation jobs by auth method                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | leases   | summary  |
+| `vault.expire.job_manager.total_jobs`                                                           | Total pending revocation jobs                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       | leases   | summary |
+| `vault.expire.job_manager.queue_length`                                                         | Total pending revocation jobs by auth method                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | leases   | summary |
 | `vault.expire.lease_expiration`                                                                 | Count of lease expirations                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          | leases   | counter |
 | `vault.expire.lease_expiration.time_in_queue`                                                   | Time taken for lease to get to the front of the revoke queue                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | ms       | summary |
 | `vault.expire.lease_expiration.error`                                                           | Count of lease expiration errors                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    | errors   | counter |
@@ -222,10 +221,10 @@ These metrics relate to internal operations on Merkle Trees and Write Ahead Logs
  
 These metrics are emitted on standbys when talking to the active node, and in some cases by performance standbys as well.
  
-| Metric                                  | Description                                                                 | Unit  | Type    |
-| :---------------------------------------| :---------------------------------------------------------------------------| :---- | :------ |
-| `vault.ha.rpc.client.forward`           | Time taken to forward a request from a standby to the active node           | ms    | summary |
-| `vault.ha.rpc.client.forward.errors`    | Number of standby request forwarding failures                               | errors| counter |
+| Metric                               | Description                                                       | Unit   | Type    |
+| :----------------------------------- | :---------------------------------------------------------------- | :----- | :------ |
+| `vault.ha.rpc.client.forward`        | Time taken to forward a request from a standby to the active node | ms     | summary |
+| `vault.ha.rpc.client.forward.errors` | Number of standby request forwarding failures                     | errors | counter |
  
 ## Replication Metrics
  
@@ -290,7 +289,7 @@ These metrics relate to [Vault Enterprise Replication](/docs/enterprise/replicat
 These metrics relate to the supported [secrets engines][secrets-engines].
  
 | Metric                                                                                       | Description                                                                                                                                                                | Unit        | Type    |
-| :------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-----      | :------ |
+| :------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------- | :------ |
 | `database.Initialize`                                                                        | Time taken to initialize a database secret engine across all database secrets engines                                                                                      | ms          | summary |
 | `database.<name>.Initialize`                                                                 | Time taken to initialize a database secret engine for the named database secrets engine `<name>`, for example: `database.postgresql-prod.Initialize`                       | ms          | summary |
 | `database.Initialize.error`                                                                  | Number of database secrets engine initialization operation errors across all database secrets engines                                                                      | errors      | counter |
@@ -402,79 +401,80 @@ These metrics relate to the supported [storage backends][storage-backends].
  
 These metrics relate to raft based [integrated storage][integrated-storage].
  
-| Metric                                                                 | Description                                                                                                                                                                                                       | Unit                              | Type    |
-| :--------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------- | :------ |
-| `vault.raft.apply`                                                     | Number of Raft transactions occurring over the interval, which is a general indicator of the write load on the Raft servers.                                                                                      | raft transactions / interval      | counter |
-| `vault.raft.barrier`                                                   | Number of times the node has started the barrier i.e the number of times it has issued a blocking call, to ensure that the node has all the pending operations that were queued, to be applied to the node's FSM. | blocks / interval                 | counter |
-| `vault.raft.candidate.electSelf`                                       | Time to request for a vote from a peer.                                                                                                                                                                           | ms                                | summary |
-| `vault.raft.commitNumLogs`                                             | Number of logs processed for application to the FSM in a single batch.                                                                                                                                            | logs                              | gauge   |
-| `vault.raft.commitTime`                                                | Time to commit a new entry to the Raft log on the leader.                                                                                                                                                         | ms                                | timer   |
-| `vault.raft.compactLogs`                                               | Time to trim the logs that are no longer needed.                                                                                                                                                                  | ms                                | summary |
-| `vault.raft.delete`                                                    | Time to delete file from raft's underlying storage.                                                                                                                                                               | ms                                | summary |
-| `vault.raft.delete_prefix`                                             | Time to delete files under a prefix from raft's underlying storage.                                                                                                                                               | ms                                | summary |
-| `vault.raft.fsm.apply`                                                 | Number of logs committed since the last interval.                                                                                                                                                                 | commit logs / interval            | summary |
-| `vault.raft.fsm.applyBatch`                                            | Time to apply batch of logs.                                                                                                                                                                                      | ms                                | summary |
-| `vault.raft.fsm.applyBatchNum`                                         | Number of logs applied in batch.                                                                                                                                                                                  | ms                                | summary |
-| `vault.raft.fsm.enqueue`                                               | Time to enqueue a batch of logs for the FSM to apply.                                                                                                                                                             | ms                                | timer   |
-| `vault.raft.fsm.restore`                                               | Time taken by the FSM to restore its state from a snapshot.                                                                                                                                                       | ms                                | summary |
-| `vault.raft.fsm.snapshot`                                              | Time taken by the FSM to record the current state for the snapshot.                                                                                                                                               | ms                                | summary |
-| `vault.raft.fsm.store_config`                                          | Time to store the configuration.                                                                                                                                                                                  | ms                                | summary |
-| `vault.raft.get`                                                       | Time to retrieve file from raft's underlying storage.                                                                                                                                                             | ms                                | summary |
-| `vault.raft.leader.dispatchLog`                                        | Time for the leader to write log entries to disk.                                                                                                                                                                 | ms                                | timer   |
-| `vault.raft.leader.dispatchNumLogs`                                    | Number of logs committed to disk in a batch.                                                                                                                                                                      | logs                              | gauge   |
-| `vault.raft.list`                                                      | Time to retrieve list of keys from raft's underlying storage.                                                                                                                                                     | ms                                | summary |
-| `vault.raft.peers`                                                     | Number of peers in the raft cluster configuration.                                                                                                                                                                | peers                             | gauge   |
-| `vault.raft.put`                                                       | Time to persist key in raft's underlying storage.                                                                                                                                                                 | ms                                | summary |
-| `vault.raft.replication.appendEntries.log`                             | Number of logs replicated to a node, to bring it up to speed with the leader's logs.                                                                                                                              | logs appended / interval          | counter |
-| `vault.raft.replication.appendEntries.rpc`                             | Time taken by the append entries RFC, to replicate the log entries of a leader node onto its follower node(s).                                                                                                    | ms                                | timer   |
-| `vault.raft.replication.heartbeat`                                     | Time taken to invoke appendEntries on a peer, so that it doesn’t timeout on a periodic basis.                                                                                                                     | ms                                | timer   |
-| `vault.raft.replication.installSnapshot`                               | Time taken to process the installSnapshot RPC call. This metric should only be seen on nodes which are currently in the follower state.                                                                           | ms                                | timer   |
-| `vault.raft.restore`                                                   | Number of times the restore operation has been performed by the node. Here, restore refers to the action of raft consuming an external snapshot to restore its state.                                             | operation invoked / interval      | counter |
-| `vault.raft.restoreUserSnapshot`                                       | Time taken by the node to restore the FSM state from a user's snapshot.                                                                                                                                           | ms                                | timer   |
-| `vault.raft.rpc.appendEntries`                                         | Time taken to process an append entries RPC call from a node.                                                                                                                                                     | ms                                | timer   |
-| `vault.raft.rpc.appendEntries.processLogs`                             | Time taken to process the outstanding log entries of a node.                                                                                                                                                      | ms                                | timer   |
-| `vault.raft.rpc.appendEntries.storeLogs`                               | Time taken to add any outstanding logs for a node, since the last appendEntries was invoked.                                                                                                                      | ms                                | timer   |
-| `vault.raft.rpc.installSnapshot`                                       | Time taken to process the installSnapshot RPC call. This metric should only be seen on nodes which are currently in the follower state.                                                                           | ms                                | timer   |
-| `vault.raft.rpc.processHeartbeat`                                      | Time taken to process a heartbeat request.                                                                                                                                                                        | ms                                | timer   |
-| `vault.raft.rpc.requestVote`                                           | Time taken to complete requestVote RPC call.                                                                                                                                                                      | ms                                | summary |
-| `vault.raft.snapshot.create`                                           | Time taken to initialize the snapshot process.                                                                                                                                                                    | ms                                | timer   |
-| `vault.raft.snapshot.persist`                                          | Time taken to dump the current snapshot taken by the node to the disk.                                                                                                                                            | ms                                | timer   |
-| `vault.raft.snapshot.takeSnapshot`                                     | Total time involved in taking the current snapshot (creating one and persisting it) by the node.                                                                                                                  | ms                                | timer   |
-| `vault.raft.state.follower`                                            | Number of times node has entered the follower mode. This happens when a new node joins the cluster or after the end of a leader election.                                                                         | follower state entered / interval | counter |
-| `vault.raft.transition.heartbeat_timeout`                              | Number of times node has transitioned to the Candidate state, after receive no heartbeat messages from the last known leader.                                                                                     | timeouts / interval               | counter |
-| `vault.raft.transition.leader_lease_timeout`                           | Number of times quorum of nodes were not able to be contacted.                                                                                                                                                    | contact failures                  | counter |
-| `vault.raft.verify_leader`                                             | Number of times node checks whether it is still the leader or not.                                                                                                                                                | checks / interval                 | counter |
-| `vault.raft-storage.delete`                                            | Time to insert log entry to delete path.                                                                                                                                                                          | ms                                | timer   |
-| `vault.raft-storage.get`                                               | Time to retrieve value for path from FSM.                                                                                                                                                                         | ms                                | timer   |
-| `vault.raft-storage.put`                                               | Time to insert log entry to persist path.                                                                                                                                                                         | ms                                | timer   |
-| `vault.raft-storage.list`                                              | Time to list all entries under the prefix from the FSM.                                                                                                                                                           | ms                                | timer   |
-| `vault.raft-storage.transaction`                                       | Time to insert operations into a single log.                                                                                                                                                                      | ms                                | timer   |
-| `vault.raft-storage.entry_size`                                        | The total size of a Raft entry during log application in bytes.                                                                                                                                                   | bytes                             | summary  |
-| `vault.raft_storage.bolt.freelist.`<br/>`free_pages`                          | Number of free pages in the freelist.                                                                                                                                                                      | pages                             | gauge  |
-| `vault.raft_storage.bolt.freelist.`<br/>`pending_pages`                       | Number of pending pages in the freelist.                                                                                                                                                                   | pages                             | gauge  |
-| `vault.raft_storage.bolt.freelist.`<br/>`allocated_bytes`                     | Total bytes allocated in free pages.                                                                                                                                                                       | bytes                             | gauge  |
-| `vault.raft_storage.bolt.freelist.`<br/>`used_bytes`                          | Total bytes used by the freelist.                                                                                                                                                                          | bytes                             | gauge  |
-| `vault.raft_storage.bolt.transaction.`<br/>`started_read_transactions`        | Number of started read transactions.                                                                                                                                                                       | transactions                      | gauge  |
-| `vault.raft_storage.bolt.transaction.`<br/>`currently_open_read_transactions` | Number of currently open read transactions.                                                                                                                                                                | transactions                      | gauge  |
-| `vault.raft_storage.bolt.page.count`                                   | Number of page allocations.                                                                                                                                                                                       | allocations                       | gauge  |
-| `vault.raft_storage.bolt.page.`<br/>`bytes_allocated`                         | Total bytes allocated.                                                                                                                                                                                     | bytes                             | gauge  |
-| `vault.raft_storage.bolt.cursor.count`                                 | Number of cursors created.                                                                                                                                                                                        | cursors                           | gauge  |
-| `vault.raft_storage.bolt.node.count`                                   | Number of node allocations.                                                                                                                                                                                       | nodes                             | gauge  |
-| `vault.raft_storage.bolt.node.dereferences`                            | Number of node dereferences.                                                                                                                                                                                      | dereferences                      | gauge  |
-| `vault.raft_storage.bolt.rebalance.count`                              | Number of node rebalances.                                                                                                                                                                                        | rebalances                        | gauge  |
-| `vault.raft_storage.bolt.rebalance.time`                               | Time taken rebalancing.                                                                                                                                                                                           | ms                                | summary  |
-| `vault.raft_storage.bolt.split.count`                                  | Number of nodes split.                                                                                                                                                                                            | nodes                             | gauge  |
-| `vault.raft_storage.bolt.spill.count`                                  | Number of nodes spilled.                                                                                                                                                                                          | nodes                             | gauge  |
-| `vault.raft_storage.bolt.spill.time`                                   | Time taken spilling.                                                                                                                                                                                              | ms                                | summary  |
-| `vault.raft_storage.bolt.write.count`                                  | Number of writes performed.                                                                                                                                                                                       | writes                            | gauge  |
-| `vault.raft_storage.bolt.write.time`                                   | Time taken writing to disk.                                                                                                                                                                                       | ms                                | summary  |
+| Metric                                                                        | Description                                                                                                                                                                                                       | Unit                              | Type    |
+| :---------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------- | :------ |
+| `vault.raft.apply`                                                            | Number of Raft transactions occurring over the interval, which is a general indicator of the write load on the Raft servers.                                                                                      | raft transactions / interval      | counter |
+| `vault.raft.barrier`                                                          | Number of times the node has started the barrier i.e the number of times it has issued a blocking call, to ensure that the node has all the pending operations that were queued, to be applied to the node's FSM. | blocks / interval                 | counter |
+| `vault.raft.candidate.electSelf`                                              | Time to request for a vote from a peer.                                                                                                                                                                           | ms                                | summary |
+| `vault.raft.commitNumLogs`                                                    | Number of logs processed for application to the FSM in a single batch.                                                                                                                                            | logs                              | gauge   |
+| `vault.raft.commitTime`                                                       | Time to commit a new entry to the Raft log on the leader.                                                                                                                                                         | ms                                | timer   |
+| `vault.raft.compactLogs`                                                      | Time to trim the logs that are no longer needed.                                                                                                                                                                  | ms                                | summary |
+| `vault.raft.delete`                                                           | Time to delete file from raft's underlying storage.                                                                                                                                                               | ms                                | summary |
+| `vault.raft.delete_prefix`                                                    | Time to delete files under a prefix from raft's underlying storage.                                                                                                                                               | ms                                | summary |
+| `vault.raft.fsm.apply`                                                        | Number of logs committed since the last interval.                                                                                                                                                                 | commit logs / interval            | summary |
+| `vault.raft.fsm.applyBatch`                                                   | Time to apply batch of logs.                                                                                                                                                                                      | ms                                | summary |
+| `vault.raft.fsm.applyBatchNum`                                                | Number of logs applied in batch.                                                                                                                                                                                  | ms                                | summary |
+| `vault.raft.fsm.enqueue`                                                      | Time to enqueue a batch of logs for the FSM to apply.                                                                                                                                                             | ms                                | timer   |
+| `vault.raft.fsm.restore`                                                      | Time taken by the FSM to restore its state from a snapshot.                                                                                                                                                       | ms                                | summary |
+| `vault.raft.fsm.snapshot`                                                     | Time taken by the FSM to record the current state for the snapshot.                                                                                                                                               | ms                                | summary |
+| `vault.raft.fsm.store_config`                                                 | Time to store the configuration.                                                                                                                                                                                  | ms                                | summary |
+| `vault.raft.get`                                                              | Time to retrieve file from raft's underlying storage.                                                                                                                                                             | ms                                | summary |
+| `vault.raft.leader.dispatchLog`                                               | Time for the leader to write log entries to disk.                                                                                                                                                                 | ms                                | timer   |
+| `vault.raft.leader.dispatchNumLogs`                                           | Number of logs committed to disk in a batch.                                                                                                                                                                      | logs                              | gauge   |
+| `vault.raft.list`                                                             | Time to retrieve list of keys from raft's underlying storage.                                                                                                                                                     | ms                                | summary |
+| `vault.raft.peers`                                                            | Number of peers in the raft cluster configuration.                                                                                                                                                                | peers                             | gauge   |
+| `vault.raft.put`                                                              | Time to persist key in raft's underlying storage.                                                                                                                                                                 | ms                                | summary |
+| `vault.raft.replication.appendEntries.log`                                    | Number of logs replicated to a node, to bring it up to speed with the leader's logs.                                                                                                                              | logs appended / interval          | counter |
+| `vault.raft.replication.appendEntries.rpc`                                    | Time taken by the append entries RFC, to replicate the log entries of a leader node onto its follower node(s).                                                                                                    | ms                                | timer   |
+| `vault.raft.replication.heartbeat`                                            | Time taken to invoke appendEntries on a peer, so that it doesn’t timeout on a periodic basis.                                                                                                                     | ms                                | timer   |
+| `vault.raft.replication.installSnapshot`                                      | Time taken to process the installSnapshot RPC call. This metric should only be seen on nodes which are currently in the follower state.                                                                           | ms                                | timer   |
+| `vault.raft.restore`                                                          | Number of times the restore operation has been performed by the node. Here, restore refers to the action of raft consuming an external snapshot to restore its state.                                             | operation invoked / interval      | counter |
+| `vault.raft.restoreUserSnapshot`                                              | Time taken by the node to restore the FSM state from a user's snapshot.                                                                                                                                           | ms                                | timer   |
+| `vault.raft.rpc.appendEntries`                                                | Time taken to process an append entries RPC call from a node.                                                                                                                                                     | ms                                | timer   |
+| `vault.raft.rpc.appendEntries.processLogs`                                    | Time taken to process the outstanding log entries of a node.                                                                                                                                                      | ms                                | timer   |
+| `vault.raft.rpc.appendEntries.storeLogs`                                      | Time taken to add any outstanding logs for a node, since the last appendEntries was invoked.                                                                                                                      | ms                                | timer   |
+| `vault.raft.rpc.installSnapshot`                                              | Time taken to process the installSnapshot RPC call. This metric should only be seen on nodes which are currently in the follower state.                                                                           | ms                                | timer   |
+| `vault.raft.rpc.processHeartbeat`                                             | Time taken to process a heartbeat request.                                                                                                                                                                        | ms                                | timer   |
+| `vault.raft.rpc.requestVote`                                                  | Time taken to complete requestVote RPC call.                                                                                                                                                                      | ms                                | summary |
+| `vault.raft.snapshot.create`                                                  | Time taken to initialize the snapshot process.                                                                                                                                                                    | ms                                | timer   |
+| `vault.raft.snapshot.persist`                                                 | Time taken to dump the current snapshot taken by the node to the disk.                                                                                                                                            | ms                                | timer   |
+| `vault.raft.snapshot.takeSnapshot`                                            | Total time involved in taking the current snapshot (creating one and persisting it) by the node.                                                                                                                  | ms                                | timer   |
+| `vault.raft.state.follower`                                                   | Number of times node has entered the follower mode. This happens when a new node joins the cluster or after the end of a leader election.                                                                         | follower state entered / interval | counter |
+| `vault.raft.transition.heartbeat_timeout`                                     | Number of times node has transitioned to the Candidate state, after receive no heartbeat messages from the last known leader.                                                                                     | timeouts / interval               | counter |
+| `vault.raft.transition.leader_lease_timeout`                                  | Number of times quorum of nodes were not able to be contacted.                                                                                                                                                    | contact failures                  | counter |
+| `vault.raft.verify_leader`                                                    | Number of times node checks whether it is still the leader or not.                                                                                                                                                | checks / interval                 | counter |
+| `vault.raft-storage.delete`                                                   | Time to insert log entry to delete path.                                                                                                                                                                          | ms                                | timer   |
+| `vault.raft-storage.get`                                                      | Time to retrieve value for path from FSM.                                                                                                                                                                         | ms                                | timer   |
+| `vault.raft-storage.put`                                                      | Time to insert log entry to persist path.                                                                                                                                                                         | ms                                | timer   |
+| `vault.raft-storage.list`                                                     | Time to list all entries under the prefix from the FSM.                                                                                                                                                           | ms                                | timer   |
+| `vault.raft-storage.transaction`                                              | Time to insert operations into a single log.                                                                                                                                                                      | ms                                | timer   |
+| `vault.raft-storage.entry_size`                                               | The total size of a Raft entry during log application in bytes.                                                                                                                                                   | bytes                             | summary |
+| `vault.raft_storage.bolt.freelist.`<br/>`free_pages`                          | Number of free pages in the freelist.                                                                                                                                                                             | pages                             | gauge   |
+| `vault.raft_storage.bolt.freelist.`<br/>`pending_pages`                       | Number of pending pages in the freelist.                                                                                                                                                                          | pages                             | gauge   |
+| `vault.raft_storage.bolt.freelist.`<br/>`allocated_bytes`                     | Total bytes allocated in free pages.                                                                                                                                                                              | bytes                             | gauge   |
+| `vault.raft_storage.bolt.freelist.`<br/>`used_bytes`                          | Total bytes used by the freelist.                                                                                                                                                                                 | bytes                             | gauge   |
+| `vault.raft_storage.bolt.transaction.`<br/>`started_read_transactions`        | Number of started read transactions.                                                                                                                                                                              | transactions                      | gauge   |
+| `vault.raft_storage.bolt.transaction.`<br/>`currently_open_read_transactions` | Number of currently open read transactions.                                                                                                                                                                       | transactions                      | gauge   |
+| `vault.raft_storage.bolt.page.count`                                          | Number of page allocations.                                                                                                                                                                                       | allocations                       | gauge   |
+| `vault.raft_storage.bolt.page.`<br/>`bytes_allocated`                         | Total bytes allocated.                                                                                                                                                                                            | bytes                             | gauge   |
+| `vault.raft_storage.bolt.cursor.count`                                        | Number of cursors created.                                                                                                                                                                                        | cursors                           | gauge   |
+| `vault.raft_storage.bolt.node.count`                                          | Number of node allocations.                                                                                                                                                                                       | nodes                             | gauge   |
+| `vault.raft_storage.bolt.node.dereferences`                                   | Number of node dereferences.                                                                                                                                                                                      | dereferences                      | gauge   |
+| `vault.raft_storage.bolt.rebalance.count`                                     | Number of node rebalances.                                                                                                                                                                                        | rebalances                        | gauge   |
+| `vault.raft_storage.bolt.rebalance.time`                                      | Time taken rebalancing.                                                                                                                                                                                           | ms                                | summary |
+| `vault.raft_storage.bolt.split.count`                                         | Number of nodes split.                                                                                                                                                                                            | nodes                             | gauge   |
+| `vault.raft_storage.bolt.spill.count`                                         | Number of nodes spilled.                                                                                                                                                                                          | nodes                             | gauge   |
+| `vault.raft_storage.bolt.spill.time`                                          | Time taken spilling.                                                                                                                                                                                              | ms                                | summary |
+| `vault.raft_storage.bolt.write.count`                                         | Number of writes performed.                                                                                                                                                                                       | writes                            | gauge   |
+| `vault.raft_storage.bolt.write.time`                                          | Time taken writing to disk.                                                                                                                                                                                       | ms                                | summary |
  
 ## Integrated Storage (Raft) Autopilot
-| Metric                              | Description                                                                                           | Unit      | Type    |
-| :---------------------------------- | :-----------------------------------------------------------------------------------------------------| :-------- | :------ |
-| `vault.autopilot.node.healthy`      | Set to 1 if the node_id is deemed healthy by Autopilot, 0 if not                                      | bool      | gauge   |
-| `vault.autopilot.healthy`           | Set to 1 if Autopilot considers all nodes healthy                                                     | bool      | gauge   |
-| `vault.autopilot.failure_tolerance` | How many nodes can be lost while maintaining quorum, i.e. number of healthy nodes in excess of quorum | nodes     | gauge   |
+ 
+| Metric                              | Description                                                                                           | Unit  | Type  |
+| :---------------------------------- | :---------------------------------------------------------------------------------------------------- | :---- | :---- |
+| `vault.autopilot.node.healthy`      | Set to 1 if the node_id is deemed healthy by Autopilot, 0 if not                                      | bool  | gauge |
+| `vault.autopilot.healthy`           | Set to 1 if Autopilot considers all nodes healthy                                                     | bool  | gauge |
+| `vault.autopilot.failure_tolerance` | How many nodes can be lost while maintaining quorum, i.e. number of healthy nodes in excess of quorum | nodes | gauge |
  
 Since Autopilot runs only the on the active node, these metrics are only emitted by the active node.
  
 <82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
 createHMAC into release/1.10.x (#14766)
 builtin/credential/approle/path_login_test.go | 21 +++++++++++++++++++
 builtin/credential/approle/validation.go      |  7 +++++++
 changelog/14746.txt                           |  3 +++
 3 files changed, 31 insertions(+)
 create mode 100644 changelog/14746.txt

@@ -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: <optional>)` – 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: <optional>)` – 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: <optional>)` – The scopes available for requesting on the provider.
  
@@ -138,7 +138,8 @@ This endpoint creates or updates a scope.
  
 - `name` `(string: <required>)` – The name of the scope. This parameter is specified as part of the URL. The `openid` scope name is reserved.
  
-- `template` `(string: <optional>)` - The template string for the scope. This may be provided as escaped JSON or base64 encoded JSON.
+- `template` `(string: <optional>)` - 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: <optional>)` – A description of the scope.
  
@@ -254,18 +255,40 @@ This endpoint creates or updates a client.
  
 - `name` `(string: <required>)` – The name of the client. This parameter is specified as part of the URL.
  
-- `key` `(string: <required>)` – 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: <optional>)` - 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: <optional>)` – A list of assignment resources associated with the client.
- 
-- `id_token_ttl` `(int or duration: <optional>)` – The time-to-live for ID tokens obtained by the client.
+- `assignments` `([]string: <optional>)` – 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: <optional>)` – 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: <optional>)` - 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: <optional>)` - The allowable elapsed time in seconds since the last
+  time the end-user was actively authenticated.
+ 
+- `code_challenge` `(string: <optional>)` - 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: <required>)` - The name of the provider. This parameter is
-specified as part of the URL.
+  specified as part of the URL.
  
 - `code` `(string: <required>)` - The authorization code received from the
-provider's authorization endpoint.
+  provider's authorization endpoint.
  
 - `grant_type` `(string: <required>)` - The authorization grant type. The
-following grant types are supported: `authorization_code`.
+  following grant types are supported: `authorization_code`.
  
 - `redirect_uri` `(string: <required>)` - 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: <required>)` - 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: <optional>)` - 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: <required>)` - 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: <required>)` - 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
  

@@ -6,32 +6,38 @@ description: An FAQ page to answer the most commonly asked questions about clien
  
 # Frequently Asked Questions (FAQ)
  
+~> **Note**: Note: Starting in Vault 1.9, Vault changed the non-entity token computation logic to deduplicate non-entity tokens. For non-entity tokens (where there is no entity to which tokens map) Vault uses the contents of the token to generate a unique client identifier, based on the namespace ID and policies. The clientID will prevent the same token from being duplicated in the overall client count. Non-entity token tracking is done on access instead of creation. Since the change was made, Vault 1.10 (via the UI, API, documentation, etc.) refers to these non-entity tokens as non-entity clients, and unique entities as entity clients. To summarize, starting in Vault 1.9, the terms used are: total clients = entity clients + non entity clients. Previously, the terms used were: total clients = unique entities + non-entity tokens.
+ 
 This FAQ section contains frequently asked questions about the client count feature.
  
 - [Q: What is a client?](#q-what-is-a-client)
 - [Q: Where can I learn more about Vault clients?](#q-where-can-i-learn-more-about-vault-clients)
-- [Q: What is the difference between a direct entity and a non-entity token?](#q-what-is-the-difference-between-a-direct-entity-and-a-non-entity-token)
+- [Q: What is the difference between a direct entity (entity client) and a non-entity token (non-entity client)?](#q-what-is-the-difference-between-a-direct-entity-entity-client-and-a-non-entity-token-non-entity-client)
 - [Q: Which Vault version reflects the most accurate client counts?](#q-which-vault-version-reflects-the-most-accurate-client-counts)
-- [Q: For customers using older versions prior to Vault 1.6, what’s the best way to compute clients?](#q-for-customers-using-older-versions-of-vault-1-6-what-s-the-best-way-to-compute-clients)
+- [Q: For customers using versions of Vault older than 1.6, what’s the best way to compute clients](#q-for-customers-using-versions-of-vault-older-than-1-6-what-s-the-best-way-to-compute-clients)
 - [Q: For customers using newer versions than Vault 1.6, what's the best way to compute clients?](#q-for-customers-using-newer-versions-than-vault-1-6-what-s-the-best-way-to-compute-clients)
 - [Q: Why do we have two different tools (auditor tool and UI/API) to compute clients? Do we plan to deprecate one in the future?](#q-why-do-we-have-two-different-tools-auditor-tool-and-ui-api-to-compute-clients-do-we-plan-to-deprecate-one-in-the-future)
 - [Q: How can I compute KMIP clients for Vault?](#q-how-can-i-compute-kmip-clients-for-vault)
 - [Q: Why do the Vault auditor tool and the usage metrics UI show me different results for the total number of clients?](#q-why-do-the-vault-auditor-tool-and-the-usage-metrics-ui-show-me-different-results-for-the-total-number-of-clients)
 - [Q: When I upgrade to a version of Vault that's greater than Vault 1.6, will the clients be available for the entire history of the billing period, or only available after the upgrade occurred during the billing period?](#q-when-i-upgrade-to-a-version-of-vault-that-s-greater-vault-1-6-will-the-clients-be-available-for-the-entire-history-of-the-billing-period-or-only-available-after-the-upgrade-occurred-during-the-billing-period)
-- [Q: If I upgrade from Vault 1.8 to 1.9, how will the changes to non-entity token logic and local auth mount made in Vault 1.9 affect the clients created prior to the upgrade?](#q-if-i-upgrade-from-vault-1-8-to-1-9-how-will-the-changes-to-non-entity-token-logic-and-local-auth-mount-made-in-vault-1-9-affect-the-clients-created-prior-to-the-upgrade)
+- [Q: If I upgrade from Vault 1.8 to 1.9+, how will the changes to non-entity token logic and local auth mount made in Vault 1.9 affect the clients created prior to the upgrade?](#q-if-i-upgrade-from-vault-1-8-to-1-9-+-how-will-the-changes-to-non-entity-token-logic-and-local-auth-mount-made-in-vault-1-9-affect-the-clients-created-prior-to-the-upgrade)
 - [Q: Post Vault 1.9, will the clientID be viewable via the audit logs when non-entity tokens are used?](#q-post-vault-1-9-will-the-clientid-be-viewable-via-the-audit-logs-when-non-entity-tokens-are-used)
 - [Q: What happens if audit logs are unreadable for use by the Vault auditor tool?](#q-what-happens-if-audit-logs-are-unreadable-for-use-by-the-vault-auditor-tool)
 - [Q: What does the usage metrics UI look like for Vault 1.9?](#q-what-does-the-usage-metrics-ui-look-like-for-vault-1-9)
-- [Q: In versions prior to Vault 1.9, how do I compute changes to clients month to month from the UI?](#q-in-versions-prior-to-vault-1-9-how-do-i-compute-changes-to-clients-month-to-month-from-the-ui)
+- [Q: What does the usage metrics look like for Vault 1.10?](#q-what-does-the-usage-metrics-look-like-for-vault-1-10)
+- [Q: In versions prior to Vault 1.10, how do I compute changes to clients month to month from the UI?](#q-in-versions-prior-to-vault-1-10-how-do-i-compute-changes-to-clients-month-to-month-from-the-ui)
 - [Q: What if I selected an inaccurate billing period via the UI/API?](#q-what-if-i-selected-an-inaccurate-billing-period-via-the-ui-api)
 - [Q: What if I want to skip computation of clients for a period of time during the billing period?](#q-what-if-i-want-to-skip-computation-of-clients-for-a-period-of-time-during-the-billing-period)
 - [Q: What are the known client count issues in the auditor tool as well as in the UI/API?](#q-what-are-the-known-client-count-issues-in-the-auditor-tool-as-well-as-in-the-ui-api)
-- [Q: Under what conditions can cause the loss of client data?](#q-under-what-conditions-can-cause-the-loss-of-client-data)
+- [Q: What conditions can cause the loss of client data?](#q-what-conditions-can-cause-the-loss-of-client-data)
 - [Q: How can I disable the counting of client activity?](http://localhost:3000/docs/concepts/client-count/faq#q-how-can-i-disable-the-counting-of-client-activity)
 - [Q: If I request data for January 2021 - December 2021, but April’s data does not exist, what will be included in the total client count result?](#q-if-i-request-data-for-january-2021-december-2021-but-april-s-data-does-not-exist-what-will-be-included-in-the-total-client-count-result)
 - [Q: How can I configure the activity for log retention?](#q-how-can-i-configure-the-activity-for-log-retention)
 - [Q: Do child namespaces create duplicate tokens?](#q-do-child-namespaces-create-duplicate-tokens)
 - [Q: How does the Nomad Vault integration affect client counts?](#q-how-does-the-nomad-vault-integration-affect-client-counts)
+- [Q: Starting in Vault 1.9, Vault does not allow creating two aliases from the same auth mount under a single entity. What changed and how does this impact client counting?](#q-starting-in-vault-1-9-vault-does-not-allow-creating-two-aliases-from-the-same-auth-mount-under-a-single-entity-what-changed-and-how-does-this-impact-client-counting)
+- [Q: How does mount migration impact the client count metric?](#q-how-does-mount-migration-impact-the-client-count-metric)
+- [Q: Vault 1.9 added support for providing custom user filters through the userfilter parameter. How does this affect client counts?](#q-vault-1-9-added-support-for-providing-custom-user-filters-through-the-userfilter-parameter-how-does-this-affect-client-counts)
  
 ### Q: What is a client?
  
@@ -50,7 +56,7 @@ Refer to the table below for documentation resources.
 | [Client Count API](https://www.vaultproject.io/api-docs/system/internal-counters#client-count)     | Provides information about the client count API endpoints                                                        |
 | [Vault Auditor Tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) | Provides a walkthrough on how to use the vault-auditor tool to extract metrics from the server audit device logs |
  
-### Q: What is the difference between a direct entity and a non-entity token?
+### Q: What is the difference between a direct entity (entity client) and a non-entity token (non-entity client)?
  
 While the definition of clients appears to be simple on the surface, there are many nuances involved in the computation of clients. As mentioned, clients are unique applications, services, and/or users that authenticate to a Vault cluster. When anything authenticates to Vault, it is associated with a unique identity entity within the [Vault Identity system](/docs/secrets/identity). The name reported to the identity systems by the different types of authentication methods varies, and each entity is created or verified during authorization.
  
@@ -71,15 +77,21 @@ Although client counts have been available via the usage metrics UI since Vault
  
 - Vault 1.6: Introduction of client counts in the usage metrics UI
 - Vault 1.8:
-  - Eliminated wrapped tokens and control groups from client count, thereby reducing the non-entity token count. Previously, the creation and usage of control groups and wrapping tokens affected the client count each time the response is read (in the case of a wrapping token) and each time a control group was created (a non-entity token was created)
+  - Eliminated wrapped tokens and control groups from client count, thereby reducing the non-entity token count. Previously, the creation and usage of control groups and wrapping tokens incremented the client count via non-entity tokens, each time a wrapped token and a control group were created.
   - Changed the logic of counting of active identity entities on usage instead of at create time, resulting in more accurate client counts
 - Vault 1.9:
-  - Changed the non-entity token computation logic to deduplicate non-entity tokens, reducing the overall client count. Moving forward, non-entity tokens, where there is no entity to map tokens, Vault will use the contents fo the token to generate a unique client identifier based on the namespace ID and associated policies. The clientID will prevent duplicating the same token in the overall client count when the token is used again during the billing period.
+ 
+  - Changed the non-entity token computation logic to deduplicate non-entity tokens, reducing the overall client count. Moving forward, non-entity tokens, where there is no entity to map tokens, Vault will use the contents of the token to generate a unique client identifier based on the namespace ID and associated policies. The clientID will prevent duplicating the same token in the overall client count when the token is used again during the billing period.
   - Changed the tracking of non-entity tokens to complete on access instead of creation.
   - Changed the computation logic to not include root tokens in the client count aggregate.
   - Changed the local auth mount computation logic such that local auth mounts count towards clients but not as non-entity tokens. Prior to Vault 1.9, local auth mounts counted towards non-entity tokens. Refer to the [What is a Client?](docs/concepts/client-count) documentation to learn more.
   - Added ability to display clients per namespace (top 10, descending order) in the UI and export data for all namespaces. Prior to Vault 1.9, you could not view view the split of clients per namespace on the UI, nor could you export this data via the UI.
   - Added ability to display clients earlier than a month (within ten minutes of enabling the feature) in the UI. Prior to Vault 1.9, after enabling the counting of clients, you had to wait for a month to view the client aggregates in the UI.
+  - Changed functionality to disallow creating two aliases from the same auth mount under a single entity. For more information, refer to the question [Starting in Vault 1.9, Vault does not allow creating two aliases from the same auth mount under a single entity. What changed and how does this impact client counting?](#q-starting-in-vault-1-9-vault-does-not-allow-creating-two-aliases-from-the-same-auth-mount-under-a-single-entity-what-changed-and-how-does-this-impact-client-counting)
+ 
+- Vault 1.10:
+  - Display of clients per auth mount with a namespace in the UI.
+  - Display of clients month to month for a selected billing period via the API.
  
 **Auditor tool**:
  
@@ -90,7 +102,7 @@ Although client counts have been available via the usage metrics UI since Vault
  
 The latest GA version of the Vault binary contains the most updated version of the client count computation logic. However, it’s important to note that even if one upgrades to the latest version and the billing period falls on either side of the upgrade time, the compute logic may be different across the billing period. For more details, refer to the question [If I migrate from Vault 1.8 to 1.9, how will the changes to non-entity token logic and local auth mount made in Vault 1.9 affect the clients created prior to the migration?](#q-if-i-migrate-from-vault-1-8-to-1-9-how-will-the-changes-to-non-entity-token-logic-and-local-auth-mount-made-in-vault-1-9-affect-the-clients-created-prior-to-the-migration).
  
-### Q: For customers using older versions of Vault 1.6, what’s the best way to compute clients?
+### Q: For customers using versions of Vault older than 1.6, what’s the best way to compute clients?
  
 The Vault [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) was built to compute clients for Vault versions older than Vault 1.6. It has been tested for versions 1.3 to 1.5 but should work for earlier versions, such as Vault 1.0, although not officially tested. To use the Vault [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool), customers should have audit logs for the billing period for computed client counts. You can also set a specific date range in the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool).
  
@@ -106,7 +118,7 @@ Not all customers may be on a version greater than Vault version 1.6 that levera
  
 ### Q: How can I compute KMIP clients for Vault?
  
-As of Vault 1.9, KMIP clients are not available via the usage metrics UI or the client count API; they are provided via the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool). To learn more, refer to the [Vault Usage Metrics](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) documentation.
+As of Vault 1.10, KMIP clients are not available via the usage metrics UI or the client count API; they are provided via the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool). To learn more, refer to the [Vault Usage Metrics](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) documentation.
  
 ### Q: Why do the Vault auditor tool and the usage metrics UI show me different results for the total number of clients?
  
@@ -125,7 +137,7 @@ For newer versions of Vault 1.8, the API/UI for client counts was updated to ref
 The client counts will only be available after the upgrade occurs. For the complete billing period data, it’s preferable to refer to the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool). However, keep in mind that since Vault 1.8, we made improvements to the client count API/UI that may cause mismatched results from the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool). For more details, refer to the question [If I migrate from Vault 1.8 to 1.9, how will the changes to non-entity token logic and local auth mount made in Vault 1.9 affect the clients created prior to the migration?](/docs/concepts/client-count/faq#q-if-i-migrate-from-vault-1-8-to-1-9-how-will-the-changes-to-non-entity-token-logic-and-local-auth-mount-made-in-vault-1-9-affect-the-clients-created-prior-to-the-migration).
 A workaround is to leverage the results from the UI/API (if on a newer version greater than Vault 1.8) instead of the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool), and extrapolate the clients for the available period to the billing period.
  
-### Q: If I upgrade from Vault 1.8 to 1.9, how will the changes to non-entity token logic and local auth mount made in Vault 1.9 affect the clients created prior to the upgrade?
+### Q: If I upgrade from Vault 1.8 to 1.9+, how will the changes to non-entity token logic and local auth mount made in Vault 1.9 affect the clients created prior to the upgrade?
  
 If you have a non-entity token for a fragment pre-Vault 1.9 version and then use the same token post-Vault 1.9 version, it will be counted again. However, for post-upgrade, the token will have an ID associated with it. From there, the subsequent uses of the token will not be counted again, as the token is tracked with the unique clientID. Hence, only for the period post the upgrade, the new deduplication logic for non-entity tokens are accounted for.
  
@@ -145,7 +157,15 @@ In Vault 1.9, the client count dashboard provides two separate tabs: the **Curre
  
 ![Vault Client Count](/img/client-counts.jpg)
  
-### Q: In versions prior to Vault 1.9, how do I compute changes to clients month to month from the UI?
+### Q: What does the usage metrics look like for Vault 1.10?
+ 
+In Vault 1.10, the client count dashboard is broken down into tabs, similar to Vault 1.19- the current month and the monthly history. On top of the namespace attribution provided in Vault 1.9 (see [What does the usage metrics UI look like for Vault 1.9?](#q-what-does-the-usage-metrics-ui-look-like-for-vault-1-9) for further information), the UI also contains attribution of clients per auth mount.
+ 
+![Vault Client Count](/img/vault-usage-metrics-1-10.png)
+ 
+The Vault 1.10 UI does not include montly attribution of clients, although the API for Vault 1.10 supports the same.
+ 
+### Q: In versions prior to Vault 1.10, how do I compute changes to clients month to month from the UI?
  
 To perform this calculation, you must know the billing period. For the sake of this example, assume your billing period starts on January 1st and ends on December 31st:
  
@@ -189,9 +209,10 @@ Known issues for both tools include the following:
 **UI/API**:
  
 - Via the UI/API, the billing period cannot be computed for start and end dates that fall in the middle of a month. For example, if the billing period starts on March 15th and ends on March 14th within the subsequent year, the tool can only compute the billing period assuming March 1 is the start date or April 1 is the start date, but not using the March 15th start date
-- As of Vault 1.9, KMIP clients are not provided by the API/CLI. We have plans to add this to a future version
+- As of Vault 1.10, KMIP clients are not provided by the API/CLI. We have plans to add this to a future version
+- As of Vault 1.10, the data on the current month tab does not take the billing period into account. This means that it may include clients that have already been previously counted. However, the monthly history tab does take the billing period into account.
  
-### Q: Under what conditions can cause the loss of client data?
+### Q: What conditions can cause the loss of client data?
  
 The activity log (component within Vault responsible for computing clients) is tracked on standby nodes and periodically transmitted to the active node over gRPC. The transmission is triggered when the information on the standby node reaches a maximum size of 8KB or 10 minutes has elapsed.
  
@@ -218,4 +239,30 @@ However, creating a new token across a parent/child namespace boundary could res
 ### Q: How does the Nomad Vault integration affect client counts?
  
 The [Nomad Vault integration](https://www.nomadproject.io/docs/integrations/vault-integration#token-role-based-integration) uses [token roles](https://www.nomadproject.io/docs/integrations/vault-integration#vault-token-role-configuration). A single token role creates tokens for many Nomad jobs. If no [explicit identity aliases](/api-docs/auth/token#entity_alias) are provided (which is not currently supported in the integration), this would create a non-entity token for every running instance of a Nomad job.
-Prior to Vault 1.9, the Nomad Vault integration caused duplicate clients, resulting in an elevated client count. Post 1.9, with the introduction of the deduplication logic, the number of clients created by the integration is reduced. For more information on improvements made to client count in Vault 1.9, refer to the question [Which version of Vault reflects the most accurate count of clients with Vault?](#q-which-vault-version-reflects-the-most-accurate-client-counts).
+Prior to Vault 1.9, the Nomad Vault integration caused duplicate clients, resulting in an elevated client count. Post Vault 1.9, with the introduction of the deduplication logic, the number of clients created by the integration is reduced. For more information on improvements made to client count in Vault 1.9, refer to the question [Which version of Vault reflects the most accurate count of clients with Vault?](#q-which-vault-version-reflects-the-most-accurate-client-counts).
+ 
+### Q: Starting in Vault 1.9, Vault does not allow creating two aliases from the same auth mount under a single entity. What changed and how does this impact client counting?
+ 
+Prior to 1.9, customers could create more than one alias from the same auth mount under a single entity. However, we made a fix in Vault 1.9 to prevent this from occuring as a remediation for a security issue.
+ 
+This could potentially impact the number of clients generated for customers. For example, pre Vault 1.9, a customer (using K8s, with many namespaces and services accounts in the cluster) could perform entity management by mapping multiple service accounts under different namespaces under a single entity. By default, each service account will create a unique entity. Post Vault 1.9, they can only map a single K8s cluster to a single K8s auth mount.
+ 
+To provide further clarity, post Vault 1.9, if there was an auth mount per namespace, the customer could create an alias for a service account in namespace-1 and an alias for a service account in namespace-2 onto the same entity without issues. However, within namespace-1, which has a single auth mount, if they have a service account-1 and service account-2, both accounts cannot be aliased to a single client.
+ 
+### Q: How does mount migration impact the client count metric?
+ 
+In Vault 1.10, we made improvements to the [`sys/remount`](/api-docs/system/remount) API endpoint to simplify the complexities of moving data, such as secret engine and authentication method configuration from one mount to another, within a namespace or across namespaces. This can help with restructuring namespaces and mounts for various reasons, including [migrating mounts](/docs/concepts/mount-migration) from root to other namespaces when transitioning to using namespaces for the first time. To learn more, refer to the [Mount Move](https://learn.hashicorp.com/tutorials/vault/mount-move) tutorial.
+ 
+When migrating mounts, any aliases that refer to users on the auth mount could now point to an invalid mount when an auth mount is moved. Pointing to an invalid mount may not be the case for every instance; a remount within a namespace will end in the aliases pointing to a valid mount. Still, a remount across namespaces will always result in the aliases pointing to an invalid mount. In the latter case, the Vault operator should find and remove those aliases from the source namespace, and create equivalent aliases and entities for the new mount in the target namespace. If new entities and aliases aren’t created in the target namespace, Vault will dynamically generate them upon login operations.
+ 
+When migrating mounts within a namespace, client counts are not impacted.
+ 
+- For each existing alias on the source mount and its corresponding entity, if the new namespace has an entity corresponding to it, then you can assign a corresponding alias for the mount and the client count will not be impacted. For example, say I am a user `abc` on namespace `ns1/` and namespace `ns2/`, and I have an alias on the source mount in `ns1/`. After the move operation, I just need an alias added to the `abc` entity in `ns2/` for the target mount. This keeps the client counts the same.
+- For the example above, say I do not have an entity `abc` in `ns2/`. This will need to be created in order to make an alias associating it with the target mount. This increases the client count by 1.
+- Following the above example, let's say after the move operation, the entity `abc` in `ns1/` has no other aliases associated with it, i.e., the alias for the source mount was its only alias. At this point, we can clean up and remove the `abc` entity in `ns1/`. This will decrease the client count by 1, as the old entity may have already been used during the billing period.
+ 
+### Q: Vault 1.9 added support for providing custom user filters through the userfilter parameter. How does this affect client counts?
+ 
+Vault 1.9 added support for providing custom user filters through the [userfilter](/api-docs/auth/ldap#userfilter) parameter. This addition changed the way that entity alias gets mapped to an entity. Prior to Vault 1.9, alias names were always based on the [login username](/api-docs/auth/ldap#username-3) (which in turn is based on the value of the [userattr](/api-docs/auth/ldap#userattr)). In Vault 1.9, alias names no longer always map to the login username. Instead, the mapping depends on other config values as well, such as [updomain](/api-docs/auth/ldap#upndomain), [binddn](/api-docs/auth/ldap#binddn), [discoverydn](/api-docs/auth/ldap#discoverdn), and userattr.
+ 
+Vault 1.10 re-introduces the option to force the alias name to map to the login username with the optional parameter username_as_alias. Users that have the LDAP auth method enabled prior to Vault 1.9 may want to consider setting this to true to revert back to the old behavior. Otherwise, depending on the other aforementioned config values, logins may generate a new and different entity for an existing user that already had an entity associated in Vault. This in turn affects client counts since there may be more than one entity tied to this user. The username_as_alias flag will also be made available in subsequent Vault 1.8.1x and Vault 1.9.x releases to allow for this to be set prior to a Vault 1.10 upgrade.