Configuring OAuth 2.0 / OpenID Connect Profiles


In order to configure SSO, you must first create a SAML profile. Then, you must provision users to use the profile. The following article walks through the creation of an OAuth 2.0 / OpenID Connect profile. 

Vault allows you to create multiple profiles and associate each with a different authorization server (AS). This allows users to authenticate with any AS configured on the security policy to which they are assigned. Note that Vault supports OpenID Connect with PingFederate Authorization Servers only.

To create an OAuth 2.0 / OpenID Connect profile:

  1. Go to Admin > Settings > OAuth 2.0 / OpenID Connect Profiles.
  2. Click Create.
  3. Enter a Label and Name for the profile.
  4. Choose a Status for the profile. It’s best practice to leave the profile as Inactive until configuration is complete.
  5. Optional: Add a description of the profile.
  6. Under OAuth 2.0 / OpenID Connect Configuration, upload your AS Metadata with the Upload AS Metadata button. See details below.
  7. Select a User ID Type, either Vault User Name or Federated ID. See details below.
  8. Click Save.
Vault supports OpenID Connect with PingFederate Authorization Servers only. Vault can consume the access tokens to issue Vault Session IDs. It is further recommended that your client and AS supports and implements PKCE.

Upload Authentication Server Metadata

You can upload your Authentication Server metadata by either uploading an AS Metadata JSON file or specifying a URL where the data is available.

To upload AS metadata:

  1. Click Upload AS Metadata.
  2. To import AS metadata by uploading a JSON file, select Authorization Server Metadata and then choose a file.
  3. To import AS metadata by specifying a URL, select Provide Authorization Server Metadata URL and then enter the location of the file.
  4. Click Continue. Vault validates the contents of the AS Metadata JSON and returns an error message if the information is invalid.
  5. To complete the configuration, click Save.

The JSON file structure is defined in the AS Metadata specifications.

The following metadata is required:

Metadata Description
issuer The authorization server's issuer identifier, which is a URL that uses the "https" scheme and has no query or fragment components.
authorization_endpoint URL of the authorization server's authorization endpoint.
token_endpoint URL of the authorization server's token endpoint.
introspection_endpoint URL of the authorization server's OAuth 2.0 introspection endpoint.
response_types_supported JSON array containing a list of the OAuth 2.0 response_type values that this AS supports.
subject_types_supported JSON array containing a list of the Subject Identifier types that this OP supports. Valid types include pairwise and public.

id_token_signing_alg_

values_supported

JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for the ID Token to encode the Claims in a JWT. The algorithm RS256 must be included. The value none may be supported, but cannot be used unless the Response Type returns no ID Token from the Authorization Endpoint (for example, in the Authorization Code Flow).

You may include any other optional metadata. The following metadata is optional, but recommended:

Metadata Description
registration_endpoint URL of the authorization server's OAuth 2.0 Dynamic Client Registration endpoint.
scopes_supported JSON array containing a list of the OAuth 2.0 [RFC6749] "scope" values that this authorization server supports. Servers may choose not to advertise some supported scope values even when this parameter is used.
claims_supported JSON array containing a list of the Claim Names of the Claims that the OpenID Provider may be able to supply values for. Note that for privacy or other reasons, this might not be an exhaustive list.
userinfo_endpoint URL of the OpenID Provider's UserInfo Endpoint. This URL must use the “https” scheme and may contain port, path, and query parameter components.

About User ID Types

The two options for User ID Type are Vault User Name and Federated ID.

Vault User Name

Choose Vault User Name if you plan to store the Vault user names as an attribute in your IdP user directory, or if the Vault user names happen to exactly match your enterprise user names. Basically, this puts the burden on the IdP to map enterprise user names to vault user names.

Federated ID

Choose Federated ID if you plan to store enterprise user names in the Federated ID field on the Vault user profile. This puts the burden on Vault to map from enterprise user names to vault user names.