ADA-C01 Question 93
Single answerUse OAuth 2.0 in SnowflakeA company wants a custom internal web application to access Snowflake on behalf of signed-in employees without storing Snowflake passwords. The security team requires that user authentication occur in the corporate identity provider, and the app must obtain OAuth access tokens that Snowflake can validate before allowing SQL access. As the Snowflake administrator, which configuration should you implement to support this requirement?
- A
Configure Snowflake as an OAuth authorization server by creating a SECURITY INTEGRATION of type OAUTH for custom clients, and have the application request Snowflake-issued tokens directly from Snowflake.
- B
Configure an external OAuth security integration in Snowflake that trusts the corporate identity provider as the authorization server, and have the application present externally issued OAuth access tokens to Snowflake.
- C
Create a SAML2 security integration in Snowflake and use the SAML assertion returned by the identity provider as the bearer token for Snowflake SQL API requests.
- D
Enable key-pair authentication for each employee and store the private keys in the web application so the application can impersonate users without OAuth.
Show answer and explanation
Correct answer: B
Explanation
The key requirement is that the corporate identity provider, not Snowflake, authenticate users and issue the OAuth access token. In Snowflake, that use case is implemented with External OAuth by creating a security integration that establishes trust with the external authorization server and defines how Snowflake validates incoming tokens and interprets claims/scopes. By contrast, Snowflake OAuth is used when Snowflake itself acts as the OAuth authorization server. SAML federation and key-pair authentication are different authentication patterns and do not satisfy the requirement for OAuth 2.0 access tokens issued by the enterprise IdP. This aligns with Snowflake documentation and best practices for External OAuth integrations, where the IdP issues the token and Snowflake validates it through the configured security integration.
- A. Incorrect.
Incorrect. Snowflake can act as an OAuth authorization server using a Snowflake OAuth security integration for Snowflake-issued tokens, but that does not meet the stated requirement that authentication occur in the corporate identity provider and that the app use tokens issued by that provider. This option is a common confusion between Snowflake OAuth and External OAuth. When the IdP must issue the token, External OAuth is the appropriate pattern.
- B. Correct.
Correct. External OAuth is designed for this scenario: a third-party authorization server, such as a corporate identity provider, authenticates users and issues OAuth access tokens. Snowflake is configured with an EXTERNAL_OAUTH security integration to trust that issuer, validate the token, and map scopes/claims as needed before permitting access. This allows the application to avoid storing Snowflake passwords while keeping authentication centralized in the enterprise IdP.
- C. Incorrect.
Incorrect. SAML is used primarily for federated authentication flows such as browser-based SSO, not as a general bearer token mechanism for Snowflake SQL access in place of OAuth access tokens. A SAML assertion is not the same as an OAuth access token for Snowflake client/API authorization. This distractor targets the common misconception that SAML and OAuth tokens are interchangeable.
- D. Incorrect.
Incorrect. Key-pair authentication is a valid Snowflake authentication method for service or user access, but it does not satisfy the requirement to authenticate users in the corporate identity provider through OAuth 2.0, and storing user private keys in a shared web application is poor security practice. It also does not provide the delegated user-consent/token-based model described in the scenario.