SnowPro Advanced: Security Engineer Question 89
Single answerOAuthA security engineer is integrating a third-party analytics application with Snowflake. The application must let users sign in with the company's existing identity provider and obtain short-lived access to Snowflake without storing Snowflake passwords in the application. The security team also wants Snowflake to validate tokens issued by the external identity provider rather than having Snowflake issue its own OAuth tokens. Which configuration best meets these requirements?
- A
Configure External OAuth in Snowflake and map the external identity provider as the authorization server for Snowflake access tokens.
- B
Configure Snowflake OAuth so Snowflake acts as the authorization server and the analytics application exchanges user credentials for Snowflake-issued tokens.
- C
Create key-pair authentication for each end user and have the application request JWT-based sessions on behalf of users.
- D
Use SAML single sign-on for the application-to-Snowflake connection because SAML tokens can be presented directly to Snowflake drivers as OAuth bearer tokens.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to configure External OAuth. Snowflake supports both Snowflake OAuth and External OAuth, and the distinction matters in real implementations. When the organization wants its enterprise identity provider, such as Okta, Microsoft Entra ID, or another supported OAuth authorization server, to authenticate users and issue access tokens, External OAuth is the correct pattern. Snowflake then validates those externally issued tokens based on the configured security integration properties such as issuer, audience, and user mapping claims. This approach is commonly used for custom apps, BI tools, and API-driven workloads where centralized identity and short-lived delegated access are required.
By contrast, Snowflake OAuth is used when Snowflake itself acts as the authorization server and issues the tokens. That can be valid in some architectures, but it directly conflicts with the stated requirement. SAML SSO is also useful in Snowflake, especially for interactive web login, but it is not interchangeable with OAuth for driver or programmatic bearer-token authentication. Key-pair authentication is another secure alternative for service-style access, yet it is not a federated OAuth user sign-in solution.
Relevant Snowflake documentation topics include External OAuth, CREATE SECURITY INTEGRATION for EXTERNAL_OAUTH, token validation settings such as issuer and audience, and the distinction between Snowflake OAuth and External OAuth in Snowflake client authentication patterns.
- A. Correct.
Correct. External OAuth is designed for this scenario: an external authorization server, typically the enterprise identity provider, issues OAuth access tokens that Snowflake validates. This supports federated sign-in, avoids storing Snowflake passwords in the application, and aligns with the requirement that token issuance remain with the external identity provider. In practice, Snowflake is configured with an EXTERNAL_OAUTH security integration, including issuer, audience, token user mapping, and allowed roles as needed.
- B. Incorrect.
Incorrect. Snowflake OAuth is appropriate when Snowflake itself is the OAuth authorization server and issues the access tokens. That does not meet the requirement that the company's existing identity provider issue the tokens and that Snowflake validate externally issued tokens. It also suggests exchanging user credentials through the application flow, which the security team wants to avoid.
- C. Incorrect.
Incorrect. Key-pair authentication is a strong non-password authentication method, but it is not an OAuth-based federated user sign-in flow. It also creates significant operational overhead if implemented per end user and does not satisfy the requirement to use the existing identity provider to issue short-lived OAuth access tokens.
- D. Incorrect.
Incorrect. SAML is commonly used for browser-based SSO into Snowflake, but SAML assertions are not the same as OAuth bearer tokens for Snowflake client connectivity. Snowflake drivers and applications that use OAuth require an OAuth access token, not a SAML assertion presented as though it were an OAuth token.