The "invalid grant" error in Snowflake typically indicates that a role grant was revoked, changed, or became stale. This error can appear suddenly even when no deliberate permissions changes were made — often as a side effect of administrative scripts, infrastructure-as-code updates, or routine account maintenance.
Snowflake OAuth: Reauthorizing Your Connection
Symptoms
When connecting to Snowflake, the client connection may encounter one of the following errors:
invalid_grant
unauthorized
OAuth access token expired
These errors indicate that your Snowflake OAuth session is no longer valid and needs to be reauthorized.
Cause
Snowflake OAuth refresh tokens have a maximum lifetime of 90 days. After 90 days of inactivity or from the time the token was issued, the refresh token expires and can no longer be used to obtain new access tokens. This is a Snowflake platform limitation and cannot be extended beyond 90 days.
This means that even if your connection was working previously, it will stop functioning once the refresh token reaches its expiration window.
For more details, see the Snowflake documentation on OAuth refresh token validity.
Resolution
To restore your connection, you need to reauthorize your Snowflake identity:
Go to Openbridge Identities.
Locate your Snowflake remote identity.
Click Reauthorize to initiate a new OAuth flow.
Complete the Snowflake authentication prompts.
Once reauthorized, your connection will receive a new refresh token and resume normal operation.
Prevention
To avoid unexpected disruptions, we recommend reauthorizing your Snowflake identity proactively before the 90-day window expires. If you have pipelines that depend on this connection, consider setting a reminder to reauthorize periodically.
Other Common Causes For Authorization Failures
Role Dropped and Recreated
When a role is dropped and recreated with the same name, Snowflake assigns it a new internal identifier. Any existing grants referencing the old internal ID become invalid. This is the most common cause of unexpected "invalid grant" errors.
This frequently happens when teams manage roles through scripts or automation that run DROP ROLE followed by CREATE ROLE instead of using ALTER ROLE or incremental grant changes.
Permission Revocation
A warehouse, database, or schema permission was revoked — sometimes intentionally by an admin running a permissions cleanup script, or unintentionally as a side effect of a broader permissions restructuring.
Cached Session Grants
Your active session may be referencing a grant that no longer exists. Snowflake sessions can cache role and grant information, and if the underlying grants change during a session, the cached state becomes stale.
Key-Pair Authentication Reset
If you are using key-pair authentication, the key association on the user object may have been reset or rotated without updating the connecting application.
Service Account Default Drift
Service accounts and integrations (ETL tools, MCP connections, BI platforms) rely on the default role and default warehouse configured on the user object. These defaults can be changed by another administrator without any notification, causing connections to silently fail.
When a service account connects to Snowflake, it typically relies on a default role and default warehouse set on the user object itself — because there's no human in the loop to manually pick a role or warehouse at login. The connection just assumes those defaults are there and valid.
The problem is that another admin can modify that user object — change the default role, swap the default warehouse, or even remove them — and nothing alerts you. The user object still exists, the credentials still work, but when the integration connects it either gets assigned a role that doesn't have the right grants, or it tries to use a warehouse that no longer exists or that the role can't access.
Note: This is especially common in environments where someone runs periodic permissions cleanup scripts or provisions infrastructure through Terraform — the user object can get modified as a side effect without anyone realizing the downstream impact.
Diagnostic Steps
Work through these steps in order to identify the root cause.
Step 1: Check Current Grants on Your User
Verify which roles are currently granted to your user:
SHOW GRANTS TO USER <your_username>;
Review the output to confirm the roles you expect are still present. If a role you depend on is missing, it was either revoked or the role was dropped and recreated.
Step 2: Check Grants on the Role
Confirm the role still has the object-level permissions you expect:
SHOW GRANTS TO ROLE <your_role>;
Look for the specific database, schema, warehouse, and table grants your workload requires. Missing grants here confirm a permission revocation.
Step 3: Inspect User Object Defaults
For service accounts and integrations, check the default settings on the user object:
DESCRIBE USER <username>;
Look at DEFAULT_ROLE and DEFAULT_WAREHOUSE. Verify that the role listed still exists, is still granted to the user, and still has the necessary permissions. Verify that the warehouse still exists and that the role has USAGE privileges on it.
Step 4: Try an Explicit Role Switch
If everything looks correct but the error persists, force a fresh session state:
USE ROLE <role_name>;
If this fails, the role is definitely not granted to your user. If it succeeds, the issue was likely a stale session cache — disconnect and reconnect to confirm.
Resolution Procedures
Re-Grant a Dropped and Recreated Role
If the role was dropped and recreated, re-grant it to the user and then re-grant all object-level permissions to the role:
GRANT ROLE <role_name> TO USER <your_username>;
Then re-apply the object grants the role needs:
GRANT USAGE ON WAREHOUSE <warehouse_name> TO ROLE <role_name>;
GRANT USAGE ON DATABASE <database_name> TO ROLE <role_name>;
GRANT USAGE ON SCHEMA <database_name>.<schema_name> TO ROLE <role_name>;
GRANT SELECT ON ALL TABLES IN SCHEMA <database_name>.<schema_name> TO ROLE <role_name>;
Fix Service Account Defaults
If the default role or warehouse has drifted on a service account, reset them:
ALTER USER <service_account_name> SET DEFAULT_ROLE = '<correct_role>';
ALTER USER <service_account_name> SET DEFAULT_WAREHOUSE = '<correct_warehouse>';
Then verify the role is still granted to the user and that the role has USAGE on the warehouse:
SHOW GRANTS TO USER <service_account_name>;
SHOW GRANTS TO ROLE <correct_role>;
Clear a Stale Session
If diagnostics show grants are correct but the error persists, disconnect and reconnect to force a fresh session. In the Snowflake UI (Snowsight), close the worksheet tab and open a new one. For programmatic connections, close and re-establish the connection.
You can also explicitly set the role and warehouse in your session to override any stale cached state:
USE ROLE <role_name>;
USE WAREHOUSE <warehouse_name>;
Re-Associate Key-Pair Authentication
If the key association was reset, re-assign the public key to the user:
ALTER USER <username> SET RSA_USER_PUBLIC_KEY = '<public_key_value>';
Prevention
Use ALTER Instead of DROP/CREATE
When modifying roles, prefer ALTER ROLE and incremental GRANT/REVOKE statements over dropping and recreating. This preserves the internal role ID and avoids breaking existing grants.
Audit Before Running Permissions Scripts
Before running any script that modifies roles, users, or grants at scale, run SHOW GRANTS TO USER and SHOW GRANTS TO ROLE for affected accounts and capture the output. This gives you a baseline to restore from if something breaks.
Pin Defaults on Service Accounts
Document the expected DEFAULT_ROLE and DEFAULT_WAREHOUSE for every service account. Include checks in your automation or CI/CD pipeline that verify these haven't drifted.
Monitor with Access History
Use Snowflake's ACCESS_HISTORY and LOGIN_HISTORY views in the ACCOUNT_USAGE schema to detect unexpected authentication failures:
SELECT *
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE IS_SUCCESS = 'NO'
AND EVENT_TIMESTAMP > DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY EVENT_TIMESTAMP DESC;
Quick Reference
Symptom | Likely Cause | First Command to Run |
Sudden "invalid grant" after no changes | Role dropped and recreated | SHOW GRANTS TO USER <user>; |
Integration fails, UI works | Service account defaults drifted | DESCRIBE USER <service_account>; |
Error after admin ran permissions script | Permission revocation | SHOW GRANTS TO ROLE <role>; |
Intermittent failures in same session | Stale session cache | USE ROLE <role>; or reconnect |
Error after key rotation | Key-pair association reset | DESCRIBE USER <user>; check RSA key |