COF-C03 Question 155
Single answerOAuthA company is integrating a custom web application with Snowflake and wants users to authenticate with the company's external identity provider instead of storing Snowflake passwords in the application. The security team also requires that access tokens be validated against the identity provider's metadata and that only tokens issued for Snowflake be accepted. Which configuration should the Snowflake administrator implement?
- A
Configure Snowflake external OAuth with the identity provider's issuer, JWS keys URL, and audience values so Snowflake can validate incoming OAuth access tokens
- B
Create a key pair for each application user and configure key-pair authentication, because OAuth in Snowflake still requires Snowflake passwords for token exchange
- C
Enable federated authentication only, because federated authentication automatically allows applications to pass identity provider access tokens directly to Snowflake
- D
Configure a Snowflake OAuth security integration and have the external identity provider validate Snowflake-issued tokens before sending them to the application
Show answer and explanation
Correct answer: A
Explanation
The best answer is to configure External OAuth in Snowflake. External OAuth is designed for cases where an external authorization server or identity provider, such as Okta, Microsoft Entra ID, or PingFederate, issues OAuth access tokens that clients then present to Snowflake. Snowflake validates those tokens using the configured issuer and token signing key information, and it can restrict acceptance based on audience so that only tokens intended for Snowflake are allowed. This is the appropriate approach when an organization wants centralized identity management and does not want applications storing Snowflake credentials. A common misconception is to confuse federated authentication with External OAuth: federated authentication is for SSO user login flows, while External OAuth is for token-based access issued by an external provider. Another common mistake is to confuse Snowflake OAuth with External OAuth; in Snowflake OAuth, Snowflake issues the tokens itself. See Snowflake documentation on External OAuth security integrations, including parameters such as EXTERNAL_OAUTH_ISSUER, EXTERNAL_OAUTH_JWS_KEYS_URL, and audience-related settings.
- A. Correct.
Correct. For this scenario, Snowflake should be configured for External OAuth using a security integration. In this model, an external IdP issues the access token, and Snowflake validates it using settings such as the issuer, token signing key/JWS keys endpoint, and allowed audience. This meets the requirement to avoid storing Snowflake passwords in the application and ensures that only tokens intended for Snowflake are accepted.
- B. Incorrect.
Incorrect. Key-pair authentication is a valid Snowflake authentication method for programmatic access, but it does not use OAuth access tokens from an external identity provider. It also does not satisfy the requirement to have users authenticate through the company's IdP using OAuth tokens.
- C. Incorrect.
Incorrect. Federated authentication and External OAuth are related but different. Federated authentication supports SSO for interactive user login to Snowflake, while External OAuth allows applications to present external OAuth access tokens to Snowflake. Enabling federated authentication alone does not mean Snowflake will accept IdP-issued API access tokens for SQL access.
- D. Incorrect.
Incorrect. A Snowflake OAuth security integration is used when Snowflake itself acts as the authorization server and issues OAuth tokens. That is the opposite of this requirement, which states that the company's external identity provider should issue the tokens and Snowflake should validate them.