ARA-C01 Question 109
Single answerOAuthA company is integrating a custom internal web application with Snowflake. Employees authenticate to the company IdP, and the application must access Snowflake on behalf of the signed-in user without storing Snowflake passwords. The security team also requires centralized user lifecycle management in the IdP and wants Snowflake to validate access tokens issued by that IdP. Which configuration should the architect recommend?
- A
Configure Snowflake external OAuth with the corporate IdP as the authorization server, and have the application present IdP-issued OAuth access tokens to Snowflake.
- B
Configure Snowflake OAuth using Snowflake as the authorization server, and have the application exchange the user’s SAML assertion directly for a Snowflake session.
- C
Configure key pair authentication for the application service account, because OAuth in Snowflake does not support user-context access with external identity providers.
- D
Configure programmatic access tokens generated manually in Snowflake for each employee, and rotate them through the application when users sign in.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake External OAuth when the enterprise wants an external identity provider or authorization server, such as Okta, Microsoft Entra ID, or another supported OAuth provider, to issue access tokens that Snowflake can validate. This pattern is appropriate when applications need to connect to Snowflake on behalf of users authenticated through the enterprise IdP and when the organization wants centralized identity governance outside Snowflake. In contrast, Snowflake OAuth is used when Snowflake itself acts as the authorization server. Architects should distinguish between these two models based on who issues the token. This scenario explicitly requires IdP-issued access tokens and centralized lifecycle management in the IdP, which maps directly to External OAuth. Relevant Snowflake documentation includes the sections on External OAuth and Snowflake OAuth, which explain the authorization-server distinction, token validation model, and application integration patterns.
- A. Correct.
Correct. External OAuth is designed for this pattern: an external IdP or authorization server issues OAuth access tokens, and Snowflake validates those tokens based on the configured external OAuth integration. This supports access on behalf of the authenticated user, avoids storing Snowflake passwords in the application, and aligns with centralized identity and lifecycle management in the corporate IdP.
- B. Incorrect.
Incorrect. Snowflake OAuth uses Snowflake as the authorization server and can be appropriate in some application scenarios, but it does not satisfy the stated requirement that the corporate IdP issue the tokens and that Snowflake validate IdP-issued access tokens. Also, a SAML assertion is not directly exchanged for a Snowflake session in the way described here for this OAuth-based requirement.
- C. Incorrect.
Incorrect. Key pair authentication is commonly used for service-to-service authentication and automation, but it authenticates a principal such as a user or service account directly to Snowflake rather than using OAuth tokens issued by an external IdP on behalf of the end user. This would not meet the requirement for user-context access based on IdP-issued OAuth tokens.
- D. Incorrect.
Incorrect. Manually generating and rotating tokens per employee is not a standard Snowflake OAuth architecture and would create operational and security issues. It would also fail the requirement for centralized token issuance and lifecycle management by the corporate IdP.