Authentication and Network Policies

1. Authentication Methods and Network Policies

We've covered what users can do once they're inside Snowflake. But before any of that matters, there's a more fundamental question: how does Snowflake verify that someone is who they say they are, and how do you control which networks can reach your account at all? That's what we'll cover today.

2. What is Authentication?

Authentication is the process of verifying identity. Before Snowflake checks roles or privileges, it first confirms who you are. A username and password is the most familiar form, but it's not the only one. Snowflake supports several methods, and the right choice depends on who is connecting -- a human analyst logging into a browser has different requirements from an automated pipeline running at 3am.

3. Authentication Methods & Frameworks

Next we'll look at authentication methods and frameworks. SSO and SAML let enterprise organisations connect Snowflake to an existing identity provider like Okta or Microsoft Entra ID, so users log in with their company credentials. OAuth solves a different problem - it's how third-party tools like BI platforms and data integration tools connect to Snowflake on behalf of a user, without those tools ever handling the user's password. Next, we'll dive deeper into each in more detail.

4. Password and MFA

Password authentication is the baseline - every Snowflake user has a username and password. But passwords alone are vulnerable: if Claro's credentials were exposed, an attacker could log straight in. Multi-factor authentication adds a second layer. Snowflake supports two MFA methods: Passkey, which uses device-based authentication, and TOTP -- a time-based one-time password generated by an authenticator app. Even if the password is compromised, the account stays protected. Administrators can enforce MFA at the account level so it's not optional.

5. Key-Pair Authentication

Key-pair authentication works without a password. The service generates a cryptographic key pair - a private key that stays on the client and a public key registered in Snowflake against the user account. When a connection is made, Snowflake verifies that the client holds the matching private key. No password is transmitted. This is the right choice for Claro's automated pipelines where service accounts run on a schedule. The SQL here assigns a public key using the ALTER USER command.

6. SSO and OAuth

SSO uses SAML-based single sign-on: Claro's employees log into Snowflake with their existing company credentials. The identity provider handles the verification, and Snowflake trusts the result. Okta and Microsoft Entra ID both provide native Snowflake support for federated authentication. Snowflake also supports most SAML 2.0-compliant identity providers, so any SAML compliant IdP can be configured. OAuth is designed for third-party tools - when a BI platform needs to connect on behalf of a user, OAuth handles the authorization flow without exposing credentials to the tool.

7. What is a Network Policy?

By default, any IP address can attempt to connect to your Snowflake account. A network policy lets a security administrator restrict access based on request origin -- IP addresses, private endpoints, or host ports. Policies work through network rules: a network rule is a schema-level object that groups related identifiers, and those rules are then added to the policy's allowed or blocked lists. Connections that don't match the allowed list are rejected before authentication even begins. For Claro, even if credentials were stolen, a connection from an unknown IP is blocked outright.

8. Creating a Network Policy

The modern approach uses network rules to group IP addresses before referencing them in the policy. CREATE NETWORK RULE defines the allowed set, a CIDR range for Claro's corporate network and a specific remote office IP, and a separate rule for blocked addresses. CREATE NETWORK POLICY then references those rules by name.

9. Applying a Network Policy

Once created, the policy applies at the account level with ALTER ACCOUNT, or at the individual user level with ALTER USER for tighter restrictions on specific service accounts.

10. Private Connectivity

Network policies restrict which IPs can reach Snowflake over the public internet. Private connectivity goes further by routing traffic through a private network endpoint, so it never traverses the public internet at all. Snowflake supports this through AWS PrivateLink, Azure Private Link, and Google Cloud Private Service Connect depending on your cloud provider. This is typically used by organizations with strict data residency or compliance requirements.

11. Let's practice!

Now you understand how Snowflake verifies identity and controls network access. Let's put that knowledge into practice.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.