ADA-C01 Question 98
Select 2Configure Snowflake OAuth for custom clientsA company is building an internal web application that must connect to Snowflake on behalf of signed-in users. The security team requires that user authentication happen through the company IdP, and the application team wants to use a custom OAuth client instead of a Snowflake-provided client. As the Snowflake administrator, you need to configure Snowflake so the custom client can request Snowflake access tokens and users can consent through the external IdP. Which configuration steps are required in Snowflake? (Select TWO.)
- A
Create a SECURITY INTEGRATION of type EXTERNAL_OAUTH and configure the external issuer, token user mapping, and allowed audiences for the IdP-issued tokens.
- B
Create a SECURITY INTEGRATION of type OAUTH with OAUTH_CLIENT = CUSTOM and define properties such as redirect URI and PKCE requirements for the custom client.
- C
Set OAUTH_USE_SECONDARY_ROLES = IMPLICIT in the custom OAuth security integration so the IdP can include Snowflake secondary roles in the access token.
- D
Alter each Snowflake user to set RSA_PUBLIC_KEY so the custom client can exchange the authorization code for a Snowflake access token.
- E
Grant the client application role to SYSADMIN so the custom OAuth client can impersonate end users during token issuance.
Show answer and explanation
Correct answers: A, B
Explanation
To configure Snowflake OAuth for a custom client, administrators typically create a SECURITY INTEGRATION of type OAUTH with OAUTH_CLIENT set to CUSTOM so Snowflake recognizes the client-specific OAuth settings, such as redirect URIs and related client behavior. If the organization wants users authenticated by an external identity provider and Snowflake to accept externally issued OAuth tokens, an EXTERNAL_OAUTH security integration is also required so Snowflake can validate issuer, audience, and user mapping claims. These are distinct use cases but commonly appear together in enterprise deployments where a custom app uses an external IdP.
The incorrect options mix in unrelated features: RSA public keys are for key-pair authentication, not OAuth; secondary role settings affect session authorization behavior after login, not client registration; and administrative role grants do not establish OAuth trust. Snowflake documentation on CREATE SECURITY INTEGRATION covers both OAUTH integrations for custom clients and EXTERNAL_OAUTH integrations for trusting third-party IdPs, including required properties such as issuer, audience, and user-claim mapping.
- A. Correct.
Correct. For a custom client that relies on an external identity provider to authenticate users and present tokens to Snowflake, Snowflake must trust that IdP through an EXTERNAL_OAUTH security integration. In practice, this includes defining the external issuer, token audience values Snowflake should accept, and how Snowflake maps the incoming token claim to a Snowflake user. Without this trust configuration, Snowflake cannot validate IdP-issued access tokens for Snowflake access.
- B. Correct.
Correct. When configuring Snowflake OAuth for custom clients, Snowflake uses a security integration of type OAUTH with OAUTH_CLIENT = CUSTOM. This is where administrators define client-related settings such as redirect URIs and, where applicable, whether PKCE is required. This enables the custom application to participate in the OAuth flow against Snowflake rather than relying on a Snowflake partner/client configuration.
- C. Incorrect.
Incorrect. OAUTH_USE_SECONDARY_ROLES controls how secondary roles are activated for a session established through Snowflake OAuth. It is not a prerequisite for configuring a custom client, nor does it cause the external IdP to embed Snowflake secondary roles in the token. A candidate might choose this option because it sounds OAuth-related, but it addresses session role behavior, not the core client setup.
- D. Incorrect.
Incorrect. RSA public keys on Snowflake users are used for key-pair authentication, not for OAuth authorization code exchange. OAuth clients authenticate using client credentials, PKCE, or the external IdP/Snowflake configuration depending on the flow. Setting RSA_PUBLIC_KEY on users does not enable a custom OAuth client.
- E. Incorrect.
Incorrect. There is no requirement to grant a special client application role to SYSADMIN for OAuth token issuance, and SYSADMIN should not be used to let an application impersonate users. OAuth access is governed by the security integration, user consent/authorization, and role grants relevant to the authenticated user. This option reflects a common misconception that administrative roles are involved in client trust establishment.