ARA-C01 Question 108
Single answerOAuthA company is building a custom internal web application that must query Snowflake on behalf of employees using their corporate identity provider (IdP). Security requirements state that: users must authenticate with the IdP, Snowflake must not store user passwords in the application, and access tokens should be short-lived and revocable without changing Snowflake user passwords. The architecture team also wants to avoid creating long-lived key pairs for each user. Which approach best meets these requirements?
- A
Configure Snowflake federated authentication with SAML only, and have the application submit the SAML assertion directly as the password to the Snowflake driver for all SQL sessions.
- B
Configure Snowflake with an external OAuth security integration tied to the corporate IdP, and have the application obtain OAuth access tokens from the IdP to authenticate to Snowflake.
- C
Store each user's Snowflake username and password in a secure vault, and let the application retrieve those credentials dynamically when opening Snowflake sessions.
- D
Create a Snowflake key pair for each user and have the application authenticate all users with key-pair authentication, rotating private keys through the IdP.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use External OAuth with a Snowflake security integration that trusts the corporate IdP as the OAuth authorization server. This pattern is appropriate when a custom application needs to connect to Snowflake on behalf of users without handling Snowflake passwords directly. OAuth access tokens are typically short-lived, can be centrally governed by the IdP, and align with modern delegated authorization practices. In contrast, storing Snowflake passwords violates the stated requirement, and key-pair authentication is generally better suited to service principals or non-interactive clients rather than per-user delegated access. SAML federation is important for SSO scenarios, but for application-driven API/driver access using bearer tokens, OAuth is the more suitable architecture. Relevant Snowflake documentation includes External OAuth and security integration guidance, which describes configuring Snowflake to validate access tokens issued by supported external identity providers.
- A. Incorrect.
Incorrect. SAML federation is commonly used for browser-based SSO into the Snowflake UI and can also support federated authentication flows, but it is not the best fit for this requirement. The scenario specifically requires the application to authenticate to Snowflake on behalf of users using short-lived, revocable tokens obtained from the corporate IdP. External OAuth is designed for this use case. Treating a SAML assertion as the general application credential for all SQL sessions is a misconception; for custom application-based delegated access to Snowflake APIs and drivers, OAuth access tokens are the intended mechanism.
- B. Correct.
Correct. External OAuth allows Snowflake to trust access tokens issued by a supported external authorization server/IdP. The application can redirect users to the IdP, obtain an OAuth access token after successful authentication, and then present that token to Snowflake. This satisfies the requirements to avoid storing passwords in the application, use short-lived bearer tokens, and revoke access through token expiration/revocation policies without resetting Snowflake passwords. It also avoids the operational burden of per-user key-pair management.
- C. Incorrect.
Incorrect. Although a secure vault is better than hardcoding credentials, this approach still relies on storing and retrieving Snowflake passwords for each user, which the requirements explicitly prohibit. It also weakens the goal of centralized identity and token lifecycle control at the IdP. Candidates may choose this because secret vaulting is a best practice in general, but it does not solve the requirement for IdP-based OAuth delegation.
- D. Incorrect.
Incorrect. Key-pair authentication is valid for service users and automated workloads, but it is not the best choice for end-user delegated access through a corporate IdP. This option also conflicts with the stated desire to avoid long-lived key pairs for each user. Rotating private keys through the IdP is also conceptually incorrect because OAuth token issuance and key-pair authentication are separate mechanisms.