OAuth 2.0 authentication

• 1: Configuring OAuth authentication
• 1.1: Configure Keycloak
• 1.2: Configure Okta
• 2: Just-in-time user provisioning
• 3: OAuth authentication parameters

1 - Configuring OAuth authentication

For a list of ODBC OAuth connection properties, see ODBC DSN connection properties.

The following procedure performs the following actions:

1. Configures an identity provider for OAuth integration with Vertica (either Okta or Keycloak).

2. Creates an OAuth authentication record.

3. Retrieves an access token with a POST request.

4. Uses a sample application to authenticate to Vertica, passing the access token as an argument and, optionally, parameters for token refresh.

Configure the identity provider

Vertica officially tests and supports OAuth integration with Keycloak and Okta. Other identity providers should also work as long as they implement the RFC 7662 Token Introspection standard. The following example configurations are provided for reference:

• Configure Keycloak
• Configure Okta

Create an authentication record

In Vertica, create an authentication record for OAuth. This uses the client ID, client secret, and either the discovery (Keycloak) or introspect (Okta) endpoint used by your identity provider.

The following authentication record v_oauth authenticates users from any IP address by contacting the identity provider to validate the OAuth token (rather than a username and password) and uses the following parameters:

• validate_type: The method used to validate the OAuth token. This should be set to IDP (default) to validate the OAuth token by contacting the identity provider.

• client_id: The client in the identity provider.

• client_secret: The client secret generated by the identity provider.

• discovery_url: Also known as the OpenID Provider Configuration Document, Vertica uses this endpoint to retrieve information about the identity provider's configuration and other endpoints (Keycloak only).

• introspect_url: Used by Vertica to introspect (validate) access tokens. You must specify the introspect_url if you do not specify the discovery_url and are not using JSON Web Token validation.

If discovery_url and introspect_url are both set, discovery_url takes precedence. The following example sets both for demonstration purposes; in general, you should prefer to set the discovery_url:

=> CREATE AUTHENTICATION v_oauth METHOD 'oauth' HOST '0.0.0.0/0';
=> ALTER AUTHENTICATION v_oauth SET validate_type = 'IDP';
=> ALTER AUTHENTICATION v_oauth SET client_id = 'vertica';
=> ALTER AUTHENTICATION v_oauth SET client_secret = 'client_secret';
=> ALTER AUTHENTICATION v_oauth SET discovery_url = 'https://203.0.113.1:8443/realms/myrealm/.well-known/openid-configuration';
=> ALTER AUTHENTICATION v_oauth SET introspect_url = 'https://203.0.113.1:8443/realms/myrealm/protocol/openid-connect/token/introspect';

Alternatively, if your identity provider supports the OpenID Connect protocol and your client is public, Vertica can use JWT validation, where Vertica validates OAuth tokens by verifying that it was signed by the identity provider's private key.

While Vertica does not contact the identity provider for JWT validation, the client does for token refresh if either the discovery or token endpoints are set in oauthjsonconfig.

JWT validation requires the following parameters:

• validate_type: The validation method, IDP by default. Setting this to JWT enables JWT validation.

• jwt_rsa_public_key: In PEM format, the public key used to sign the client's OAuth token. Vertica uses this to validate the OAuth token. If your identity provider does not natively provide PEM-formatted public keys, you must convert them to PEM format. For example, keys retrieved from an Okta endpoint are in JWK format and must be converted.

• jwt_issuer: The issuer of the OAuth token. This value is set by the identify provider.

• jwt_user_mapping: The name of the Vertica user.

You can also specify the following parameters to define a whitelist based on fields of the OAuth token:

• jwt_accepted_audience_list: Optional, a comma-delimited list of values to accept from the client JWT's aud field. If set, tokens must include in aud one of the accepted audiences to authenticate.

• jwt_accepted_scope_list: Optional, a comma-delimited list of values to accept from the client JWT's scope field. If set, tokens must include in scope at least one of the accepted scopes to authenticate.

The following authentication record v_oauth_jwt authenticates users from any IP address by verifying that the client's OAuth token was signed by the identity provider's private key. It also requires the user to provide the proper values in the token's aud and scope fields:

=> CREATE AUTHENTICATION v_oauth_jwt METHOD 'oauth' HOST '0.0.0.0/0';
=> ALTER AUTHENTICATION v_oauth_jwt SET validate_type = 'JWT';
=> ALTER AUTHENTICATION v_oauth_jwt SET jwt_rsa_public_key = 'MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkjXjd6F8PyKkQtY5q2cJ9jNT9y+PeIJS134UvuUnuD9bQFhkBPstTBulpZV1QQivYaQ5k5bYVE2Q7n/XscrWzbRkK/qEwmztjVUH7dQAHSSKEjYcbH1fREx5nR5oNEelrUH2RrGM98Y7ln+Ch4oCl8yCS6gjI6hfaDxwqo2oImmGE+Qi06SIjoWGBCr5EIAhvlNuWe2rWD5uEe4ivaL6KoAR9sADqhGBoaYs/wIVUcv5DHtSjU+yZIz/sVspJehvmb/979eDsct2IddCHLrjUet3DiKz4imIyh+cv9VTEI6MWbk5WIiKW2fFzZ6Oei/ddzmTqVoNdn+d18tWwlf7hQIDAQAB';
=> ALTER AUTHENTICATION v_oauth_jwt SET jwt_issuer = 'token_issuer';
=> ALTER AUTHENTICATION v_oauth_jwt SET jwt_user_mapping = 'oauth_user';
=> ALTER AUTHENTICATION v_oauth_jwt SET jwt_accepted_audience_list = 'vertica,local';
=> ALTER AUTHENTICATION v_oauth_jwt SET jwt_accepted_scope_list = 'email,profile,user';

To enable the authentication record:

=> ALTER AUTHENTICATION v_oauth ENABLE;

For a full list of OAuth authentication parameters, see OAuth authentication parameters.

Create a Vertica user

Vertica users map to the identity provider's users with the same username. You can either create the user manually or enable just-in-time (JIT) user provisioning in the authentication record to automatically create users with valid tokens.

To manually create the user:

1. To map to the user oauth_user in the identity provider, create a Vertica user with the same name. You do not need to specify a password because authentication is performed by the identity provider:

   => CREATE USER oauth_user;
   

2. Grant the OAuth authentication record to the user (or their role):

   => GRANT AUTHENTICATION v_oauth TO oauth_user;
   => GRANT ALL ON SCHEMA PUBLIC TO oauth_user;
   

To enable JIT user provisioning:

=> ALTER AUTHENTICATION v_oauth SET oauth2_jit_enabled = 'yes';

If the user already exists and JIT user provisioning is enabled and you use Keycloak as your identity provider, Vertica automatically assigns the roles associated with the user as specified by the identity provider if the roles also exist in Vertica. For details, see Just-in-time user provisioning.

Retrieve an access token

The simple way to get an OAuth access token and refresh token is to send a POST request to the token endpoint, providing the credentials of the user. You can then use the returned access token, refresh token, and scope with the oauthaccesstoken and oauthrefreshtoken connection properties for your client. For details, see JDBC connection properties and ODBC DSN connection properties.

For example, to get an access token for oauth_user from Keycloak:

$ curl --location --request POST 'http://203.0.113.1:8080/realms/master/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'username=oauth_user' \
--data-urlencode 'password=oauth_user_password' \
--data-urlencode 'client_id=vertica' \
--data-urlencode 'client_secret=client_secret' \
--data-urlencode 'grant_type=password'

Keycloak responds with a json string containing the access_token and refresh_token if you authenticated correctly.

{
   "access_token":"access_token",
   "expires_in":60,
   "refresh_expires_in":1800,
   "refresh_token":"refresh_token",
   "token_type":"Bearer",
   "not-before-policy":0,
   "session_state":"6745892a-aa74-452f-b6b9-c45637193859",
   "scope":"profile email"
}

Similarly, to retrieve an access token for oauth_user from Okta:

$ curl --insecure -d "client_id=0oa5cgdga1fb812rW697" -d "client_secret=aq22wRl3Z3mmtuoB13omRo6Ql03Ltafet4xYi77p" -d "username=oauth_user" -d "password=oauth_user_password" -d "grant_type=password" -d "scope=offline_access%20openid" https://example.okta.com/oauth2/default/v1/introspect

{"token_type":"Bearer","expires_in":3600,"access_token":"access_token","id_token":"id_token"}

Run the sample applications

The OAuth sample applications, at a minimum, take an access token as an argument to authenticate to the database until the token expires. If you want the sample application to refresh the token after it expires, you must specify the following. The sample applications put these into a JSON string, OAuthJsonConfig or (ODBC) oauthjsonconfig (JDBC).

• Refresh token

• Client ID

• Client secret

• Token URL

ODBC

1. Follow the instructions in the README.

2. Run the sample application, passing the OAuth parameters as arguments:

   • To authenticate until the token expires:

     $ ./a.out --access-token OAuthAccessToken
     

   • To authenticate and silently refresh the access token when it expires:

     $ ./a.out --access-token OAuthAccessToken
         --refresh-token OAuthRefreshToken
         --client-id OAuthClientID
         --client-secret OAuthClientSecret
         --token-url OAuthTokenURL
     

For a list of all ODBC OAuth parameters, see ODBC DSN connection properties.

JDBC

1. Follow the instructions in the README.

2. Run the sample application, passing the OAuth parameters as arguments:

   • To authenticate until the token expires:

     $ mvn compile exec:java -Dexec.mainClass=OAuthSampleApp -Dexec.args="vertica_host database_name --access-token oauthaccesstoken"
     

   • To authenticate and silently refresh the access token when it expires:

     $ mvn compile exec:java -Dexec.mainClass=OAuthSampleApp -Dexec.args="vertica_host database_name --access-token oauthaccesstoken
         --refresh_token oauthrefreshtoken
         --client-id oauthclientid
         --client-secret oauthclientsecret
         --token-url oauthtokenurl"
     

For a list of all JDBC OAuth parameters, see JDBC connection properties.

Troubleshooting

To get debugging information for TLS, use the -Djavax.net.debug=ssl flag.

Custom CA certificates

A truststore is a container for trusted certificate authority (CA) certificates. These CA certificates are used to verify the identities of other systems when establishing a TLS connection. When your JDBC client connects to the identity provider through an HTTPS endpoint, the JDBC client verifies the identity provider's certificate by making sure that it was issued by a CA in the truststore.

If you configure your identity provider with TLS (that is, if you use HTTPS endpoints for your token or refresh URLs) and its certificate is not issued by a well-known CA, you must either specify a custom truststore or import the issuer's CA certificate into the system truststore with keytool.

To specify a custom truststore, set the JDBC connection properties oauthtruststorepath and oauthtruststorepassword:

connProps = new Properties(connProps);
connProps.setProperty("oauthtruststorepath", "/path/to/truststore/customoauth.truststore");
connProps.setProperty("oauthtruststorepassword", "password");

To add the certificate keycloak/cert.crt to the Java truststore:

$ keytool -trustcacerts -keystore /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.261-2.6.22.2.el7_8.x86_64/jre/lib/security/cacerts -storepass changeit -importcert -alias keycloak -file /keycloak/cert.crt

1.1 - Configure Keycloak

The following procedure configures a Keycloak 18.0.0 server on 203.0.113.1 for integration with Vertica. For details, see Configuring OAuth authentication.

The goals of this procedure are to configure Keycloak and obtain the following information:

• Client ID: The ID used to identify the Vertica database. This is configured by the user and set to vertica in the example procedure.
• Client secret: A Keycloak-generated string used to refresh the OAuth token when it expires.
• Discovery endpoint: The endpoint that serves information for all other endpoints as a JSON string. The endpoint for a Keycloak server on 203.0.113.1 is one of the following:
  • https://203.0.113.1:8443/realms/myrealm/.well-known/openid-configuration (if TLS is configured)
  • http://203.0.113.1:8443/realms/myrealm/.well-known/openid-configuration

Configure TLS (optional)

If you want to use TLS, you must obtain a certificate and key for Keycloak signed by a trusted CA. This example uses a self-signed CA for convenience. The following example creates a certificate and key in Vertica:

1. Generate the CA certificate:

   => CREATE KEY SSCA_key TYPE 'RSA' LENGTH 2048;
   CREATE KEY
   
   => CREATE CA CERTIFICATE SSCA_cert
   SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/C N=Vertica Root CA'
   VALID FOR 3650
   EXTENSIONS 'nsComment' = 'Self-signed root CA cert'
   KEY SSCA_key;
   CREATE CERTIFICATE
   

2. Generate a server key and certificate, signed by your CA, setting the subjectAltName of the certificate to the DNS server and/or IP address of your Keycloak server:

   => CREATE KEY keycloak_key TYPE 'RSA' LENGTH 2048;
   CREATE KEY
   
   => CREATE CERTIFICATE keycloak_cert
   SUBJECT '/C=US/ST=Massachussets/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Server'
   SIGNED BY SSCA_cert
   EXTENSIONS 'nsComment' = 'Keycloak CA', 'extendedKeyUsage' = 'serverAuth', 'subjectAltName' = 'DNS.1:dnsserver,IP:203.0.113.1'
   KEY keycloak_key;
   CREATE CERTIFICATE
   

3. Create the file keycloak_directory/conf/keyfile.pem with the content from the key column for the generated key:

   => SELECT key FROM cryptographic_keys WHERE name = 'keycloak_key';
   

4. Create the file keycloak_directory/conf/certfile.pem with the content from the certificate_text column for the generated certificate:

   => SELECT certificate_text FROM certificates WHERE name = 'keycloak_cert';
   

5. Append to your system's CA bundle the content from the certificate_text column for the generated CA certificate. The default CA bundle path and format varies between distributions; for details, see SystemCABundlePath:

   => SELECT certificate_text FROM certificates WHERE name = 'SSCA_cert';
   

6. Set the SystemCABundlePath configuration parameter:

   => ALTER DATABASE DEFAULT SET SystemCABundlePath = 'path/to/ca_bundle';
   

Start Keycloak

1. Enter the following commands for a minimal configuration to create the Keycloak admin and to start Keycloak in start-dev mode:

   $ KEYCLOAK_ADMIN=kcadmin
   $ export KEYCLOAK_ADMIN
   $ KEYCLOAK_ADMIN_PASSWORD=password
   $ export KEYCLOAK_ADMIN_PASSWORD
   $ cd keycloak_directory/bin/
   $ ./kc.sh start-dev --hostname 203.0.113.1 --https-certificate-file ../conf/certfile.pem --https-certificate-key-file=../conf/keyfile.pem
   

2. Open the Keycloak console with your browser (these examples use the default ports):

   • For HTTP: http://203.0.113.1:8080

   • For HTTPS: http://203.0.113.1:8443

3. Sign in as the admin.

4. (Optional) To make testing OAuth more convenient, go to Realm Settings > Tokens and increase Access Token Lifespan to a greater value (the default is 5 minutes).

Create the Vertica client

1. Go to Clients and select on Create. The Add Client page appears.

2. In Client ID, enter vertica.

3. Select Save. The client configuration page appears.

4. On the Settings tab, use the Access Type dropdown to select confidential.

5. On the Credentials tab, copy the Secret. This is the client secret used to refresh the token when it expires.

Create a Keycloak user

Keycloak users map to Vertica users with the same name. This example creates a the Keycloak user oauth_user.

1. On the Users tab, select Add user. The Add user page appears.

2. In Username, enter oauth_user.

3. On the Credentials tab, enter a password.

1.2 - Configure Okta

The following procedure configures Okta for integration with Vertica and requires administrator privileges. For details, see Configuring OAuth authentication.

The goals of this procedure are to configure Okta and obtain the following information:

• Client ID: The ID used to identify the Vertica database. This is generated by Okta.
• Client secret: An Okta-generated string used to refresh the OAuth token when it expires.
• Token endpoint: Used by the client to retrieve the OAuth token.
• Introspection endpoint: Used by Vertica to validate the OAuth token.

These values are used to create the oauth authentication record in Vertica and act as instructions for Vertica to communicate with Okta when a user attempts to authenticate.

Create an OIDC application

1. From the Okta dashboard, go to Applications > Applications and select Create App Integration. The Create a new app integration dialog box appears.
2. For the Sign-in method, select OIDC - OpenID Connect. The Application type section appears.
3. For the Application type, select Native Application.
4. Select Next. The New Native App Integration window opens.
5. In the App integration name, enter a name for your application. This example uses Demo_Vertica.
6. For the Grant Type, select Authorization Code, Refresh Token, and Resource Owner Password.
7. For Controlled access, select the option applicable to your organization. This example uses Allow everyone in your organization to access.
8. Select Save to save your application.

Retrieve the client ID and client secret

1. From the Okta dashboard, go to Applications > Applications and select the name of your OIDC application.
2. In the General tab in the Client Credentials section, select Edit.
3. For Client authentication, select Client secret and select Save. This generates a new client secret.
4. Copy the client ID and client secret.

Set the authentication policy

1. From the Okta dashboard, go to Applications > Applications and select the name of your OIDC application.
2. In the Sign On tab in the User authentication section, select Edit.
3. Select Password only.
4. Select Save to save the new policy.

Retrieve Okta endpoints

1. From the Okta dashboard, go to Security > API.
2. In the Authorization Servers tab, select the name of your authorization server. By default, the name of this server is default.
3. Select the Metadata URI to get a list of all endpoints for your authorization server as a json string.
4. Copy the values for the token_endpoint and introspection_endpoint.

Test the configuration

1. Verify that you can retrieve an OAuth token from the token endpoint. If successful, Okta respond with an access_token and refresh_token:

   $ curl --insecure -d "client_id=client_id" -d "client_secret=client_secret" -d "username=okta_username" -d "password=okta_password" -d "grant_type=password" -d "scope=offline_access%20openid" token_endpoint
   

2. Verify that the tokens are valid with the introspection endpoint. If successful, Okta responds with a json string containing "active":true:

   To verify the access token:

   $ curl --insecure -d "client_id=client_id" -d "client_secret=client_secret" -d "token=access_token" introspection_endpoint
   

   Similarly, to verify the refresh token:

   $ curl --insecure -d "client_id=client_id" -d "client_secret=client_secret" -d "token=refresh_token" introspection_endpoint
   

   The access_token and refresh_token can then be used for the oauthaccesstoken and oauthrefreshtoken parameters. For details, see JDBC connection properties and ODBC DSN connection properties.

2 - Just-in-time user provisioning

Just-in-time (JIT) user provisioning is the act of automatically configuring an authenticated user and their roles based on information provided by the identity provider.

When a client uses an OAuth authentication record that enables JIT user provisioning, Vertica automatically performs the following actions:

1. Creates the user if they do not already exist in the database. The length of the username in the identity provider cannot be greater than 128 characters.

2. (Keycloak only) Grants to the user and sets as default the roles associated with the user (as specified by the identity provider), provided the roles already exist in Vertica.

3. Grants to the user the authentication record used to authenticate them if neither their user nor role has a grant on that record.

For example, if a client presents an OAuth token to authenticate as user Alice with role director, and Alice does not exist in Vertica, Vertica automatically creates the user Alice, grants to her the authentication record, and grants to her the director role as a default role.

To view users created by JIT user provisioning and which authentication record they use, query the USERS system table:

=> SELECT user_name, managed_by_oauth2_auth_id FROM users;
 user_name |  managed_by_oauth2_auth_id
-----------+-----------------------------
 dbadmin   |
 Bob       | 45035996273853300
 Margie    |
 Alice     | 45035996273866484
(4 rows)

For details on using JIT user provisioning with OAuth authentication, see Configuring OAuth authentication.

Enabling just-in-time user provisioning

JIT user provisioning is enabled at the authentication record level by setting the oauth2_jit_enabled parameter:

=> CREATE AUTHENTICATION v_oauth METHOD 'oauth' HOST '0.0.0.0/0';
=> ALTER AUTHENTICATION v_oauth SET oauth2_jit_enabled = 'yes';

=> SELECT auth_name, is_oauth2_jit_enabled FROM client_auth WHERE auth_name='v_oauth';
  auth_name  |  is_oauth_2_jit_enabled
-------------+--------------------------
 v_oauth     | True
(1 row)

Automatic role assignment

The roles automatically assigned to JIT-provisioned active users are based on the information provided by the identity provider (either from the endpoints introspect_url or userinfo_url) and are identified by the client/application specified by the OAuth2JITClient configuration parameter ( vertica by default):

=> ALTER DATABASE DEFAULT SET OAuth2JITClient = "vertica";

With OAuth2JITClient set to vertica, roles that both exist in Vertica and are listed in resource_access.vertica.roles are automatically granted to and set as default roles for JIT-provisioned users.

The identity provider shares user roles through the introspect_url or userinfo_url endpoints. Vertica first sends a request to the introspect_url. If no roles are found in the response, Vertica sends a request to userinfo_url.

For example, if a client attempts to authenticate as the user bob and no user with the same name exists in the database, Vertica sends the following request to the identity provider's introspect_url to retrieve the roles given to bob by the identity provider (this example is truncated):

{
    ...
    "resource_access": {
        "vertica": {
            "roles": [
                "customer-facing",
                "order-management",
                "idp-exclusive-role"
            ]
        },
        "account": {
            "roles": [
                "manage-account",
                "manage-account-links",
                "view-profile"
            ]
        }
    },
    "scope": "email profile roles",
    "sid": "dcdd14b1-fe47-491e-b62b-10d1e05c6ffe",
    "client_id": "vertica",
    "username": "bob",
    "active": true
}

Because the active field is true and bob has no corresponding user in the Vertica server, Vertica automatically creates the user bob and grants to him the roles that exist in Vertica and are listed in resource_access.vertica.roles: customer-facing and order-management. The role idp-exclusive-role does not exist in Vertica, so it is ignored.

Automatic user pruning

You can enable automatic user pruning to periodically drop users created by JIT user provisioning if they do not log in after a certain period of time. This cleanup service is managed by the following database-level configuration parameters:

• EnableOAuthJITCleanup: Whether to enable cleanup (disabled by default).

  => ALTER DATABASE DEFAULT SET EnableOAuthJITCleanup = 1; --enables the pruning service
  => ALTER DATABASE DEFAULT SET EnableOAuthJITCleanup = 0; --disables the pruning service
  

• OAuth2UserExpiredInterval: The number of days a user must be inactive before it is dropped (14 by default). This is calculated based on the current date and the LAST_LOGIN_TIME in the USERS system table.

  Note

  The LAST_LOGIN_TIME as recorded by the USERS system table is not persistent; if the database is restarted, the LAST_LOGIN_TIME for users created by just-in-time user provisioning is set to the database start time (this appears as an empty value in LAST_LOGIN_TIME).

  You can view the database start time by querying the DATABASES system table:

  => SELECT database_name, start_time FROM databases;
   database_name |          start_time
  ---------------+-------------------------------
   VMart         | 2023-02-06 14:26:50.630054-05
  (1 row)
  

  => ALTER DATABASE DEFAULT SET OAuth2UserExpiredInterval = 20;
  

• GlobalHeirUsername: The user to reassign objects to if the owner is a JIT-provisioned (or LDAP) user that got dropped by the pruning service. If set to <auto>, objects are reassigned to the dbadmin.

  => ALTER DATABASE DEFAULT SET GlobalHeirUsername = <auto>
  

The cleanup service runs daily and there can be a delay of up to 24 hours for dropping an expired user.

3 - OAuth authentication parameters

Vertica OAuth authentication records use the following parameters to determine how to validate client OAuth tokens and how to contact the identity provider during the validation process. These parameters should be set with ALTER AUTHENTICATION.

Just-in-time provisioning parameters

The optional oauth2_jit_enabled parameter specifies whether to enable just-in-time user provisioning. If set to 'yes', when the user authenticates, Vertica automatically performs the following actions:

1. Creates the user if they do not already exist in the database. The length of the username in the identity provider cannot be greater than 128 characters.

2. (Keycloak only) Grants to the user and sets as default the roles associated with the user (as specified by the identity provider), provided the roles already exist in Vertica.

3. Grants to the user the authentication record used to authenticate them if neither their user nor role has a grant on that record.

If set to 'no' (default), users must be manually created and granted an oauth authentication record to authenticate to Vertica with OAuth tokens.

Validation modes

OAuth authentication records have two modes for validating OAuth tokens, each specified with the authentication parameter validate_type.

The validate_type parameter takes one of the following values:

• IDP (default): Validate OAuth tokens by contacting the identity provider. This validation type requires the client to specify their client secret. This should be used with confidential clients (set for each client by the identity provider).

• JWT: Validate OAuth tokens by verifying that it was signed by the identity provider's private key. While Vertica does not contact the identity provider for JWT validation, the client does for token refresh if either the discovery or token endpoints are set in oauthjsonconfig. This should be used for public clients (set for each client by the identity provider). Additionally, clients can connect if they leave oauthjsonconfig or OAuthJsonConfig empty.

Each validation mode uses a different set of parameters, which are detailed in the tables below.

IDP validation parameters

JWT validation parameters

The following table lists the parameters used to configure OAuth authentication records that use the JWT validation mode: