Refresh Tokens are issued when the parameter 'oauth_issue_refresh_tokens' is set to TRUE in the security integration created for the client.

The Refresh Token is issued by the Snowflake OAuth server to allow the clients/applications to request more Access Tokens as required. It allows a client to request an Access Token without involving the user who provided the initial authorization.

The Access Tokens are short-lived and their validity is 600 seconds.

The Error Codes section provides a list of error codes associated with OAuth, as well as errors returned during the authorization flow, token request, exchange, or when creating a Snowflake session after completing the OAuth flow.

After the token is created, it is submitted in requests to the token endpoint in the Bearer authorization format as the authorization header instead of the basic authorization format.

Security administrators can pre-authorize consent for a client to initiate a session for a user using a specified role and integration. This consent is granted using ALTER USER with the ADD DELEGATED AUTHORIZATION keywords. The delegated authorization can also be revoked.

Generate a new private and public key set, assign the public key to the integration, update the code to connect to Snowflake with the new private key, and remove the old public key from the integration.

Generate an encrypted private key from the command line, create a public key referencing the private key, store these keys in a local directory, and assign the public key to the integration object using ALTER SECURITY INTEGRATION.

Snowflake supports using key pair authentication when calling the OAuth token endpoint. This method requires a 2048-bit (minimum) RSA key pair, generated using OpenSSL. The public key is assigned to the Snowflake user who uses the Snowflake client.

The client creates a secret, generates a code challenge, and holds onto the secret. When a user consents to the requested scopes, the authorization code is issued. The client submits the authorization code along with the code_verifier in the request to the token endpoint. Snowflake then verifies that the transformed code_verifier value matches the code_challenge value used when generating authorizations. If they match, access and refresh tokens are issued.

Snowflake supports Proof Key for Code Exchange (PKCE) for obtaining access tokens using the authorization_code grant type as described in RFC 7636.

The token endpoint returns access tokens or refresh tokens depending on the request parameters. The request parameters include grant type, code or refresh token, and redirect URI. The client ID and client secret must be included in the authorization header.

The scope query parameter in the initial authorization request optionally limits the operations and role permitted by the access token. The scope is validated immediately when making an authorization request with respect to semantics.

The client sends a GET request to the Snowflake's OAuth authorization endpoint with several query parameters. Once a user authorizes the client, a redirect is made to the redirect_uri that contains a short-lived authorization code in a GET request.

Snowflake supports network policies for OAuth, but no further details have been provided at the moment.

Snowflake supports using Client Redirect with Snowflake OAuth Custom Clients, including using Client Redirect and OAuth with supported Snowflake Clients.

The optional BLOCKED_ROLES_LIST parameter allows you to list Snowflake roles that a user cannot explicitly consent to using with the integration.

Only account administrators or a role with the global CREATE INTEGRATION privilege can execute the SQL command to create a Snowflake OAuth integration

On Snowflake, in-session role switching to secondary roles is not supported with Snowflake OAuth. If such behavior is necessary, use External OAuth instead

An integration in Snowflake provides an interface between Snowflake and third-party services, such as a client that supports OAuth.