SnowPro Specialty: Gen AI Question 236
Single answerREST API authentication methodsA team is building a Snowflake-based GenAI application that calls an external REST API to enrich prompts with data from a third-party service. The security team requires that long-lived credentials not be embedded in code and that API access can be limited and revoked centrally if the integration is compromised. Which authentication method best meets these requirements for the external REST API integration?
- A
Use OAuth 2.0 with short-lived access tokens issued by an authorization server
- B
Use HTTP Basic authentication with a service account username and password stored in application code
- C
Use an API key hard-coded in the client request headers because it is simpler to rotate later
- D
Use no authentication and restrict access only by allowing requests from approved IP addresses
Show answer and explanation
Correct answer: A
Explanation
The best answer is OAuth 2.0 with short-lived access tokens. In REST API integrations, especially those used by GenAI applications that may call external services repeatedly and at scale, security teams typically prefer token-based authentication over static credentials such as passwords or API keys embedded in code. OAuth 2.0 supports centralized authorization, token expiration, scoped access, and revocation, which directly addresses the scenario requirements. By contrast, Basic authentication and hard-coded API keys depend on long-lived shared secrets and increase operational risk. IP allowlisting is a complementary control, not an authentication method. This aligns with widely accepted API security best practices from OAuth 2.0 guidance and enterprise API security recommendations.
- A. Correct.
Correct. OAuth 2.0 is commonly used for REST APIs when centralized control, revocation, and reduced exposure of long-lived secrets are required. Short-lived access tokens reduce risk compared with static credentials, and authorization servers provide a standard mechanism for token issuance and revocation. In real-world enterprise integrations, this aligns well with least-privilege and credential-management best practices.
- B. Incorrect.
Incorrect. HTTP Basic authentication relies on a static username and password, which are long-lived credentials unless additional controls are built around them. Storing these credentials in application code directly violates the requirement to avoid embedded secrets. While Basic auth is still supported by some APIs, it is generally less secure and less manageable than token-based approaches for modern integrations.
- C. Incorrect.
Incorrect. API keys are often used for REST APIs, but hard-coding them in client code conflicts with the requirement to avoid embedded long-lived credentials. Even if rotation is possible, the exposure risk remains high, and revocation is typically less granular than OAuth-based token control. This option reflects a common misconception that ease of implementation outweighs security requirements.
- D. Incorrect.
Incorrect. IP allowlisting can be a useful network control, but it is not a substitute for authentication. If an approved source is compromised, the API would still have no application-level identity or token to revoke. This does not meet the stated requirement for centrally limiting and revoking access.