ADA-C01 Question 91
Single answerConfigure and use OAuth protocolsA company is integrating a custom internal web application with Snowflake and wants users to sign in with the company identity provider instead of storing Snowflake passwords in the application. The security team also requires that access tokens be short-lived and that users can obtain new access tokens without re-entering credentials every few minutes. As the Snowflake administrator, which OAuth configuration best meets these requirements?
- A
Configure a Snowflake security integration for external OAuth with the corporate identity provider as the authorization server, and have the application request refresh tokens so it can obtain new short-lived access tokens.
- B
Configure key pair authentication for all users and store the users' private keys in the web application so the app can reconnect to Snowflake without prompting users.
- C
Configure a Snowflake OAuth security integration and issue one long-lived access token per user so the application does not need to request new tokens.
- D
Configure SAML single sign-on for Snowsight and Classic Console, then reuse the SAML assertion directly as the credential for SQL API calls from the application.
Show answer and explanation
Correct answer: A
Explanation
The scenario requires three things: federation to the enterprise identity provider, no embedded Snowflake passwords, and short-lived access tokens with a mechanism to renew them. The best fit is OAuth with an external authorization server, which in Snowflake is implemented through an External OAuth security integration. In this model, the identity provider issues access tokens that Snowflake validates based on the integration configuration. To avoid frequent user logins while maintaining security, the application should use short-lived access tokens and refresh tokens according to OAuth best practices.
Why not the other options? Key pair authentication is valid for service-to-service access but does not provide user-delegated OAuth sign-in through the IdP. Long-lived access tokens increase risk and do not align with recommended token lifecycle practices. SAML is for federated authentication, but SAML assertions are not interchangeable with OAuth access tokens for Snowflake API access.
This aligns with Snowflake documentation and best practices for External OAuth, OAuth token usage, and federated authentication patterns: use an External OAuth security integration when an external IdP such as Okta, Microsoft Entra ID, or PingFederate should issue tokens for Snowflake access, and prefer short-lived access tokens with refresh tokens when the client and authorization flow support them.
- A. Correct.
Correct. External OAuth is designed for cases where an external identity provider acts as the authorization server and issues OAuth tokens that Snowflake validates. This fits the requirement to use the company identity provider instead of storing Snowflake passwords in the application. Using short-lived access tokens with refresh tokens is a standard OAuth pattern that reduces risk while allowing the application to obtain new access tokens without forcing users to repeatedly authenticate.
- B. Incorrect.
Incorrect. Key pair authentication is useful for programmatic access, especially service accounts, but it does not satisfy the requirement for users to sign in through the company identity provider using OAuth. Storing user private keys in a web application is also a poor security practice and does not provide OAuth-style delegated authorization or token refresh behavior.
- C. Incorrect.
Incorrect. Snowflake OAuth can issue tokens, but using a long-lived access token conflicts with the stated security requirement for short-lived tokens. Best practice is to keep access tokens short-lived and use refresh tokens where appropriate. The main issue here is not whether Snowflake OAuth exists, but that the option explicitly chooses long-lived access tokens as the solution.
- D. Incorrect.
Incorrect. SAML SSO is used for interactive federation into Snowflake user interfaces and can also support some client authentication patterns, but a SAML assertion is not the same as an OAuth access token for Snowflake SQL API calls. This option reflects a common misconception that SSO assertions can simply be reused as OAuth bearer tokens.