ADA-C01 Question 94
Single answerUse OAuth 2.0 in SnowflakeA company wants its internal analytics web application to connect to Snowflake without storing Snowflake usernames and passwords. The application already uses the company's external identity provider (IdP) to authenticate employees and can obtain OAuth access tokens for them. Security requires that Snowflake validate those external tokens directly and map users based on the identity asserted by the IdP. As the Snowflake administrator, which configuration should you implement to meet this requirement?
- A
Create a SECURITY INTEGRATION of type OAUTH for EXTERNAL_OAUTH, configured with the external IdP's issuer, allowed audiences, and user mapping attributes.
- B
Create a SECURITY INTEGRATION of type OAUTH for SNOWFLAKE_OAUTH, because Snowflake OAuth is the standard way to accept third-party IdP-issued access tokens.
- C
Configure key-pair authentication for the application user, because key-pair authentication allows Snowflake to validate external IdP tokens without passwords.
- D
Create a SAML2 SECURITY INTEGRATION and have the application exchange the SAML assertion for a Snowflake session token for SQL API access.
Show answer and explanation
Correct answer: A
Explanation
The correct solution is to use External OAuth in Snowflake. This allows Snowflake to trust an external OAuth 2.0 authorization server and validate bearer access tokens issued by that provider. In real-world deployments, administrators define an EXTERNAL_OAUTH security integration with parameters such as the external issuer, allowed token audiences, RSA public keys or JWKS endpoint details, and claims used for user mapping and optional role mapping. This is the standard design when an enterprise application already authenticates users through a corporate IdP and must access Snowflake without storing Snowflake passwords.
By contrast, Snowflake OAuth is used when Snowflake issues the OAuth tokens itself. Key-pair authentication is passwordless but unrelated to OAuth token validation. SAML federation supports SSO use cases, but it is not the right mechanism when the application presents OAuth 2.0 access tokens to Snowflake.
This aligns with Snowflake documentation and best practices for OAuth, especially the distinction between Snowflake OAuth and External OAuth, and the use of security integrations to configure trust, claims, and token validation behavior.
- A. Correct.
Correct. External OAuth is specifically designed for the case where Snowflake trusts and validates OAuth access tokens issued by an external authorization server/IdP such as Okta, Microsoft Entra ID, or PingFederate. In practice, the administrator creates an EXTERNAL_OAUTH security integration and configures items such as the token issuer, audience, JWKS or signing key details, and how Snowflake should map token claims to Snowflake users and roles. This matches the requirement to avoid storing passwords in the application and to let Snowflake validate externally issued access tokens directly.
- B. Incorrect.
Incorrect. SNOWFLAKE_OAUTH is used when Snowflake itself acts as the OAuth authorization server and issues tokens for Snowflake access. It is not the correct choice when the organization already has an external IdP issuing OAuth tokens that Snowflake must validate. A common misconception is that all OAuth into Snowflake uses SNOWFLAKE_OAUTH, but the deciding factor is who issues the token.
- C. Incorrect.
Incorrect. Key-pair authentication is a separate authentication mechanism in which a client proves possession of a private key associated with a Snowflake user. It does not allow Snowflake to validate third-party OAuth access tokens from an external IdP. Someone might choose this option because it also avoids passwords, but it does not satisfy the requirement to reuse existing IdP-issued OAuth tokens.
- D. Incorrect.
Incorrect. SAML integrations are primarily used for federated authentication to Snowflake clients and web-based sign-in patterns, not for Snowflake to validate OAuth 2.0 access tokens issued by an external IdP for API or application access. While SAML and OAuth are both federation-related technologies, they are not interchangeable in this scenario. The requirement explicitly centers on OAuth access tokens.