Snowflake OAuth vs External OAuth: Setup, Network Policies and Private Connectivity

1.Two OAuth 2.0 options: Snowflake OAuth and External OAuth

Snowflake supports OAuth 2.0 in two forms, and each one is configured as a security integration. With Snowflake OAuth, Snowflake is both the authorization server and the resource server. The user signs in, agrees to let the client use a particular role, and the client swaps the resulting authorization code for an access token and, optionally, a refresh token. With External OAuth, your own authorization server, such as Okta, Entra ID or PingFederate, issues a JWT. Snowflake checks the token, looks up the user it belongs to, and opens a session with the role from the token's scope.

With External OAuth, two integration properties decide which Snowflake user a token belongs to. EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM names the claim in the token, and EXTERNAL_OAUTH_SNOWFLAKE_USER_MAPPING_ATTRIBUTE names the user property that claim is compared against. A token without a scope is rejected. The scope session:role-any uses the user's default role, but only when external_oauth_any_role_mode is configured on the integration. Both forms of OAuth block ACCOUNTADMIN, ORGADMIN, GLOBALORGADMIN and SECURITYADMIN by default. For either form, clients set authenticator=oauth and pass the token, and LOGIN_HISTORY records FIRST_AUTHENTICATION_FACTOR = OAUTH_ACCESS_TOKEN.

CREATE SECURITY INTEGRATION external_oauth_okta
  TYPE = EXTERNAL_OAUTH
  ENABLED = TRUE
  EXTERNAL_OAUTH_TYPE = OKTA
  EXTERNAL_OAUTH_ISSUER = '<OKTA_ISSUER>'
  EXTERNAL_OAUTH_JWS_KEYS_URL = '<OKTA_JWS_KEY_ENDPOINT>'
  EXTERNAL_OAUTH_AUDIENCE_LIST = ('https://<orgname>-<account_name>.snowflakecomputing.com')
  EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM = 'sub'
  EXTERNAL_OAUTH_SNOWFLAKE_USER_MAPPING_ATTRIBUTE = 'login_name';

Sources123

2.Configuring Snowflake OAuth for a custom client

Partner tools such as Tableau and Looker have their own OAUTH_CLIENT values. For an application your organization builds, use OAUTH_CLIENT = CUSTOM. A custom client also needs OAUTH_CLIENT_TYPE and OAUTH_REDIRECT_URI. Confidential clients are ones that can keep a secret, such as a service running in the cloud. Public clients are desktop or app-store applications. Clients call two endpoints: <snowflake_account_url>/oauth/authorize, which has to open in a browser, and /oauth/token-request.

CREATE SECURITY INTEGRATION oauth_kp_int
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'https://localhost.com'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 86400
  BLOCKED_ROLES_LIST = ('SYSADMIN')
  OAUTH_CLIENT_RSA_PUBLIC_KEY ='
  MIIBI
  ...
  ';

The integration has two client secrets, so you can rotate them with REFRESH OAUTH_CLIENT_SECRET or OAUTH_CLIENT_SECRET_2 without an outage. A key-pair client uses OAUTH_CLIENT_RSA_PUBLIC_KEY_2 for rotation in the same way. To withdraw a user's consent, and with it the user's access tokens, run ALTER USER ... REMOVE DELEGATED AUTHORIZATIONS FROM SECURITY INTEGRATION.

Sources456

3.How network policies, private connectivity and SSO affect Snowflake OAuth

Network policies. A NETWORK_POLICY set on a Snowflake OAuth integration controls two things: client requests for tokens, and the queries the client then runs against Snowflake as the resource server. The user's browser sign-in follows the user-level network policy, or the account-level policy if the user has none. The built-in SNOWFLAKE$LOCAL_APPLICATION integration is an exception: for its token requests, the user policy is checked first, then the integration policy, then the account policy. Among partner applications, only Looker supports network policies. An External OAuth integration can't have its own network policy. If you need a policy specific to OAuth, use Snowflake OAuth.

CREATE SECURITY INTEGRATION td_oauth_int2
  TYPE = oauth
  ENABLED = true
  OAUTH_CLIENT = tableau_desktop
  OAUTH_REFRESH_TOKEN_VALIDITY = 36000
  BLOCKED_ROLES_LIST = ('SYSADMIN')
  NETWORK_POLICY = 'allow_private_ip_only';

Private connectivity. External OAuth works over private connectivity. With Snowflake OAuth it depends on the client. Tableau Cloud connecting over private connectivity has to use OAUTH_CLIENT = CUSTOM. Looker can't use private connectivity at all, because Snowflake OAuth with Looker needs the public internet. Setting USE_PRIVATELINK_FOR_AUTHORIZATION_ENDPOINT = TRUE sends the user's sign-in step over private connectivity, but traffic between the client and Snowflake still goes over the public internet. Hosted SaaS clients therefore have to use the public account URL for token requests. To find the private-connectivity URL, call SYSTEM$GET_PRIVATELINK_CONFIG.

Federated authentication. When the Snowflake OAuth authorization screen appears, the user can sign in through SSO, so the IdP's authentication methods (including its MFA) apply. Under External OAuth, the authorization server enforces authentication. Users who only ever connect through External OAuth need no Snowflake password.

Sources37182

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.You can attach a NETWORK_POLICY directly to an External OAuth security integration.Why is that wrong?

   An External OAuth integration can't have a network policy of its own. Only account-wide policies apply. For an OAuth-specific policy, use Snowflake OAuth.

   Covered in How network policies, private connectivity and SSO affect Snowflake OAuth

2. 2.USE_PRIVATELINK_FOR_AUTHORIZATION_ENDPOINT = TRUE keeps the whole OAuth exchange off the public internet.Why is that wrong?

   Only the user's sign-in step goes over private connectivity. Traffic between Snowflake and the client, including the initial request to the authorization endpoint, still goes over the public internet.

   Covered in How network policies, private connectivity and SSO affect Snowflake OAuth

Practise it for real

Create a Snowflake OAuth custom-client integration and inspect and manage it

1. 1.As a role with CREATE INTEGRATION (or ACCOUNTADMIN), run the oauth_kp_int CREATE SECURITY INTEGRATION statement from this page, using your client's real public key.

   Why: Registers your custom client with Snowflake as the authorization server.

   You should see: The integration is created successfully.

2. 2.Run DESC SECURITY INTEGRATION oauth_kp_int.

   Why: Shows the endpoints and settings the client must use.

   You should see: OAUTH_ALLOWED_AUTHORIZATION_ENDPOINTS and OAUTH_ALLOWED_TOKEN_ENDPOINTS list your /oauth/authorize and /oauth/token-request URLs.

3. 3.After a user authorizes the client, run SHOW DELEGATED AUTHORIZATIONS TO SECURITY INTEGRATION oauth_kp_int.

   Why: Confirms which users have given consent and for which role.

   You should see: One row per consenting user, showing role_name and integration_status ENABLED.

4. 4.As SECURITYADMIN, run ALTER USER <username> REMOVE DELEGATED AUTHORIZATIONS FROM SECURITY INTEGRATION oauth_kp_int.

   Why: Withdrawing consent also revokes the access tokens tied to the integration.

   You should see: The user's row is gone from SHOW DELEGATED AUTHORIZATIONS, and the client has to go through authorization again.