Identity, Authentication, and Access Control
Users, roles, and how sessions get identity
A user is an identity; a role is a set of privileges; a session activates one role at a time (with secondary roles optionally enabled). Authentication methods include password (with MFA), key-pair authentication (RSA, used for service users and programmatic access), OAuth (including Snowflake OAuth and external OAuth via an identity provider), and SAML 2.0 federated authentication for SSO. Federated auth can be paired with SCIM for automated user and role provisioning.
Understand network policies as an authentication-adjacent control (allow/block lists by IP), and authentication policies that enforce MFA, set session timeouts, and restrict client types. Know that MFA enrollment can be required at the account or user level and that password policies govern complexity and reuse.
Access control mechanics
Snowflake uses discretionary access control (DAC) with role-based grants. Ownership is a privilege; the owning role can grant to others. Distinguish account roles from database roles (scoped to a database, useful for sharing and multi-tenant patterns). Secondary roles let a session use multiple roles without switching.
Traps
- Assuming a user can use a granted role without it being granted to them or activated.
- Confusing SAML SSO (authentication) with authorization - roles still come from Snowflake or SCIM.
- Thinking key-pair auth requires a password fallback; it does not.
- Mixing up account-level and user-level authentication policy precedence - the more specific policy generally applies.
Rule of thumb
Separate authentication (who you are) from authorization (what a role can do). For service accounts, use key-pair auth with a dedicated, minimally privileged role and no interactive login.