Snowflake External OAuth Security Integration: How Authentication Works Between Snowflake and External Identity Providers

When building secure applications with Snowflake, authentication and authorization are two important parts of the security layer. Authentication answers: “Who are you?” and Authorization answers:“What are you allowed to access?”

In many organizations, user identities are not managed directly inside Snowflake. Instead, companies already have identity providers such as AWS Cognito, Okta, or Microsoft Entra ID handling user authentication.

Snowflake Security Integration allows Snowflake to establish a trusted connection with these external identity providers. Through External OAuth, Snowflake can validate OAuth tokens generated by an external authentication system and use the information from those tokens to create a secure Snowflake session.

The basic flow looks like this:

User
 |
 |
 v
External Identity Provider
(AWS Cognito / Okta / Azure AD)
 |
 |
 | OAuth JWT Token
 |
 v
Snowflake External OAuth Security Integration
 |
 |
 | Validate Identity
 | Map Snowflake User
 | Apply Role Context (if configured)
 |
 v
Snowflake Session

The Security Integration works as a trust layer between Snowflake and the external identity provider. Snowflake does not manage the user’s password or authentication process. Instead, it verifies the token issued by the trusted external system.

For authentication, Snowflake validates details such as the token issuer, token signature, audience, and user identity mapping.

For authorization, OAuth claims or scopes can be used to provide role information when configured. The final access control on Snowflake objects is still managed through Snowflake Role-Based Access Control (RBAC).

In my practical experience, I used External OAuth Security Integration with AWS Cognito, where Cognito handled the user authentication flow and Snowflake validated the generated OAuth token before allowing access to Snowflake.

How External OAuth Security Integration Works

To understand External OAuth Security Integration, let’s first understand what happens behind the scenes when a user connects to Snowflake through an external identity provider.

The authentication process does not start in Snowflake. Instead, it starts with the external identity provider, such as AWS Cognito, Okta, or Microsoft Entra ID. After the user is successfully authenticated, the identity provider generates an OAuth JWT token and sends it to the application.

The application then uses this token when establishing a connection with Snowflake.

Snowflake does not simply trust every token it receives. It validates the token using the configuration defined in the Security Integration. During this validation process, Snowflake verifies several important details, such as:

• The token was issued by the trusted Identity Provider.
• The token signature is valid.
• The token was generated for the expected application (Audience).
• The token belongs to a valid Snowflake user by mapping a claim in the token to a Snowflake user.

If all these validations are successful, Snowflake creates a session for that user.

User
 |
 | Login
 |
 v
External Identity Provider
 |
 | Authenticate User
 | Generate OAuth JWT Token
 |
 v
Application / Middle Layer
 |
 | Send JWT Token
 |
 v
Snowflake External OAuth Security Integration
 |
 | Verify Issuer
 | Verify Signature
 | Verify Audience
 | Map User
 |
 v
Snowflake Session

At this stage, the Security Integration has completed the authentication process by verifying the user’s identity.

Depending on the application design, the OAuth token can also carry role or scope information. This allows Snowflake to participate in role selection during session creation. However, the actual permissions to access databases, schemas, tables, and other Snowflake objects are still controlled by Snowflake RBAC.

My Practical Implementation with AWS Cognito

To understand this better, let’s look at how I implemented External OAuth Security Integration in one of my projects.

In our environment, AWS Cognito is used as the external Identity Provider (IdP). The platform team manages Cognito, user authentication, and the application layer, while my responsibility as the Snowflake Data Engineer was to configure Snowflake so that it could trust and validate the tokens generated by Cognito.

The Security Integration I created was similar to the following:

CREATE OR REPLACE SECURITY INTEGRATION cognito_oauth
TYPE = EXTERNAL_OAUTH
ENABLED = TRUE
EXTERNAL_OAUTH_TYPE = CUSTOM
EXTERNAL_OAUTH_ISSUER = 'https://cognito-idp.ap-southeast-1.amazonaws.com/...'
EXTERNAL_OAUTH_AUDIENCE_LIST = ('xxxxxxxx')
EXTERNAL_OAUTH_JWS_KEYS_URL = 'https://cognito-idp.ap-southeast-1.amazonaws.com/.../.well-known/jwks.json'
EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM = 'cognito:username'
EXTERNAL_OAUTH_SNOWFLAKE_USER_MAPPING_ATTRIBUTE = 'LOGIN_NAME';

Although the SQL statement is short, every parameter has a specific responsibility.

TYPE = EXTERNAL_OAUTH tells Snowflake that authentication will be handled by an external OAuth 2.0 authorization server instead of Snowflake OAuth.

ENABLED = TRUE enables the Security Integration so Snowflake can use it to validate incoming OAuth tokens.

EXTERNAL_OAUTH_TYPE = CUSTOM specifies that the Identity Provider is a custom OAuth provider. In my case, this is AWS Cognito.

EXTERNAL_OAUTH_ISSUER identifies the trusted Identity Provider. Whenever Snowflake receives a JWT token, it verifies that the token was issued by this Cognito User Pool.

EXTERNAL_OAUTH_JWS_KEYS_URL points to the public keys published by Cognito. Snowflake uses these keys to validate the JWT signature and ensure the token has not been modified.

EXTERNAL_OAUTH_AUDIENCE_LIST validates that the token was created for the expected application.

EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM tells Snowflake which claim from the JWT should be used to identify the Snowflake user.

EXTERNAL_OAUTH_SNOWFLAKE_USER_MAPPING_ATTRIBUTE = LOGIN_NAME tells Snowflake to compare that claim with the LOGIN_NAME of Snowflake users.

For example, if the JWT token contains:

{
    "cognito:username": "safnas"
}

Snowflake searches for a user whose LOGIN_NAME is SAFNAS. If a matching user is found and all token validations succeed, Snowflake creates a session for that user.

EXTERNAL_OAUTH_ANY_ROLE_MODE controls whether the OAuth client or user can switch to roles that are not explicitly defined in the OAuth token. In my current implementation this is set to ENABLE, which allows role switching when permitted by Snowflake.

Depending on your security requirements, other useful parameters can also be configured.

EXTERNAL_OAUTH_BLOCKED_ROLES_LIST prevents applications from creating sessions using sensitive roles such as ACCOUNTADMIN or SECURITYADMIN.

EXTERNAL_OAUTH_ALLOWED_ROLES_LIST can be used to explicitly restrict which Snowflake roles an application is allowed to use.

NETWORK_POLICY allows the Security Integration to be associated with a Snowflake Network Policy, adding another layer of security by controlling which client networks are allowed to connect.

At the moment, my implementation is primarily focused on authentication. The application sends the JWT token generated by AWS Cognito, and Snowflake validates the token before creating a session. No Snowflake username or password is sent from the application.

Authorization

At the moment, our implementation mainly uses External OAuth Security Integration for authentication. At this stage, I am not passing Snowflake roles from the OAuth token. However, Snowflake still applies its own security rules while creating the session. For example, if the user’s default role is ACCOUNTADMIN, Snowflake checks whether that role is allowed for External OAuth sessions. Since highly privileged roles such as ACCOUNTADMIN, ORGADMIN, and SECURITYADMIN are blocked by default for External OAuth, Snowflake prevents the session from being created with those roles.

Our organization already has multiple security layers managed by the platform team, so authorization is handled outside of Snowflake in several places. Because of that, implementing role-based authorization through External OAuth has not been a requirement yet.

However, the current architecture is already prepared for that enhancement.

When a new user is created, the platform team first creates the user in AWS Cognito. During that process, they assign the appropriate Snowflake role to the user. Instead of manually typing role names, the platform application can provide a dropdown containing the available Snowflake roles. Those roles can be maintained from the Snowflake side, ensuring that only valid Snowflake roles are assigned.

The flow would look like this:

Snowflake
    |
    | Available Roles
    |
    v
Platform User Management
    |
    | Select Role
    |
    v
Create Cognito User
    |
    | Username + Snowflake Role
    |
    v
Generate OAuth Access Token
    |
    | scope / scp contains requested role
    |
    v
Snowflake External OAuth Security Integration
    |
    | Map role during session creation
    |
    v
Snowflake Session

In this approach, the access token would contain the requested Snowflake role through the standard OAuth scope or scp claim. Snowflake External OAuth Security Integration can use EXTERNAL_OAUTH_SCOPE_MAPPING_ATTRIBUTE to read that claim and use it during session creation.

This allows authentication and role selection to remain centralized while still relying on Snowflake RBAC to enforce permissions on databases, schemas, tables, views, and other objects.

External OAuth vs Snowflake OAuth

While working with Snowflake Security Integrations, it is important to understand that Snowflake supports different types of OAuth integrations depending on the authentication architecture.

In my implementation, I used External OAuth, where an external Identity Provider such as AWS Cognito is responsible for authenticating users and issuing OAuth tokens. Snowflake does not manage the authentication flow. Instead, Snowflake trusts the external OAuth provider, validates the token, and creates a Snowflake session based on the configured Security Integration.

The flow is:

External Identity Provider
(AWS Cognito / Okta / Azure AD)
        |
        |
        | OAuth Token
        |
        v
Snowflake External OAuth Security Integration
        |
        |
        v
Snowflake Session

Snowflake also supports another type called Snowflake OAuth.

Snowflake OAuth works differently. In this approach, Snowflake acts as the OAuth authorization server. Clients that support OAuth can redirect users to Snowflake’s authorization page, and Snowflake generates access tokens (and optionally refresh tokens) that clients can use to access Snowflake.

The flow is:

Client Application
        |
        |
        v
Snowflake OAuth Authorization
        |
        |
        v
Access Token
        |
        |
        v
Snowflake

The main difference is where the identity management happens.

With External OAuth:

External Identity Provider
        |
        |
        v
Snowflake trusts and validates the token

With Snowflake OAuth:

Snowflake
        |
        |
        v
Handles OAuth authorization and token generation

The choice depends on the organization’s security architecture.

If an organization already has an identity provider managing users, applications, and authentication flows, External OAuth is a common approach because Snowflake can integrate with the existing security ecosystem.

If an application needs Snowflake itself to provide the OAuth authorization flow, Snowflake OAuth can be used.

In enterprise environments, both approaches can be useful depending on the application requirements and security model.

Snowflake External OAuth Security Integration provides a way to connect Snowflake with external identity providers and establish a trusted authentication flow. In my experience, I used AWS Cognito with Snowflake to validate user identities and create secure Snowflake sessions without managing separate Snowflake credentials. In the future, this same setup can be extended for authorization use cases by using OAuth scopes and Snowflake roles together with Snowflake RBAC.

Ref: https://docs.snowflake.com/en/sql-reference/sql/create-security-integration-oauth-external https://docs.snowflake.com/en/sql-reference/sql/create-security-integration-oauth-snowflake