ADA-C01 Question 92
Single answerConfigure and use OAuth protocolsA company wants a custom internal web application to connect to Snowflake without storing Snowflake usernames or passwords. The security team requires that users authenticate with the company IdP, and the application must obtain a Snowflake access token on behalf of the signed-in user so that queries run with that user's identity. As the Snowflake administrator, which OAuth configuration should you recommend?
- A
Configure Snowflake as an external OAuth resource server and have the application use tokens issued by the company IdP for Snowflake access.
- B
Configure a security integration for key-pair authentication so the application can exchange the user's public key for a Snowflake session token.
- C
Configure Snowflake OAuth and have the application use the client credentials grant so all users share the same Snowflake service identity.
- D
Configure programmatic access tokens (PATs) for each user and store the PATs in the application after the first login.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use External OAuth when an external identity provider issues OAuth access tokens that Snowflake accepts. This is the standard approach when users authenticate with a corporate IdP and an application needs to access Snowflake on behalf of those users without storing Snowflake passwords. The access token carries claims that Snowflake validates through an OAuth security integration, allowing Snowflake to map the external identity to a Snowflake user and enforce role/scoping rules. By contrast, client credentials is for app-to-app access and does not preserve end-user identity, key-pair authentication is not an OAuth delegation mechanism, and PATs are not the best fit for this delegated SSO scenario. Relevant Snowflake documentation includes External OAuth security integrations and Snowflake OAuth concepts, especially guidance on choosing the appropriate OAuth flow based on whether the client acts as a user or as itself.
- A. Correct.
Correct. This matches the requirement to authenticate users with the company's identity provider and let the application obtain an OAuth token representing the signed-in user. In Snowflake, this is typically implemented with External OAuth, where Snowflake trusts tokens issued by a supported external authorization server/IdP and maps the token claims to a Snowflake user. This avoids storing Snowflake passwords in the application and preserves per-user identity for query execution and auditing.
- B. Incorrect.
Incorrect. Key-pair authentication is used for programmatic authentication of a Snowflake user, typically for service accounts or automated clients, not for federated user sign-in through an enterprise IdP. There is no flow where an application exchanges a user's public key for a Snowflake session token on the user's behalf in the way described here. This option confuses OAuth-based delegated authorization with key-pair authentication.
- C. Incorrect.
Incorrect. The client credentials grant is intended for machine-to-machine access where the application acts as itself, not on behalf of an end user. Using this flow would cause queries to run under a shared service principal or service user context rather than each signed-in user's identity, which violates the requirement for per-user execution and auditing.
- D. Incorrect.
Incorrect. PATs are long-lived programmatic tokens associated with a user, but this scenario specifically requires IdP-based user authentication and delegated token acquisition on behalf of the current user. Storing PATs in the application for each user introduces token management and security concerns and does not align with the intended OAuth federation pattern for enterprise SSO.