Skip to main content

Adding Snowflake User Permissions To Your OAuth App

Written by Openbridge Support

This guide explains how a Snowflake administrator can allow add a specific user, such as bob@<domain>.com, to complete an OAuth authorization flow for the Openbridge service.

The goal is to make sure the user signing into Snowflake has access to the correct Snowflake role — usually the role that owns or can access the database, schema, stages, and tables the Openbridge service needs.

Overview

Snowflake OAuth uses a security integration to let an external client redirect a user to Snowflake, obtain user consent, and generate access tokens for Snowflake access. Snowflake describes this as the mechanism that enables OAuth clients to redirect users to an authorization page and generate access tokens.

For the authorization to work correctly, the Snowflake user completing the OAuth flow must have the correct Snowflake role granted to them. Roles are granted to users, and privileges are granted to roles.


Step 1: Identify the Snowflake OAuth App / Security Integration

A Snowflake admin should first identify the OAuth security integration that represents the external application.

Run:

USE ROLE ACCOUNTADMIN;  
SHOW INTEGRATIONS;

Look for a security integration related to the external app or OAuth client.

Then inspect it:

DESCRIBE INTEGRATION <integration_name>;

Replace <integration_name> with the actual integration name.

Example:

DESCRIBE INTEGRATION OPENBRIDGE_OAUTH;

For Snowflake OAuth security integrations, DESCRIBE INTEGRATION can show OAuth-related values such as allowed authorization and token endpoints.

If the Openbridge service needs OAuth client details, the admin may also need to retrieve the OAuth client secrets:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('<integration_name>');

Example:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('OPENBRIDGE_OAUTH');

Snowflake notes that the integration name passed to SYSTEM$SHOW_OAUTH_CLIENT_SECRETS is case-sensitive, must be uppercase, and enclosed in single quotes.


Step 2: Identify the Role That Owns or Can Access the Objects

The user completing authorization needs a role that can access the relevant Snowflake objects.

The examples shown will need to use your own values. We only show the Openbridge ones for reference, not to be copy and pasted as is.

Start by finding the Openbridge-related objects:

USE ROLE ACCOUNTADMIN;  SHOW SCHEMAS LIKE '%OPENBRIDGE%' IN ACCOUNT;  SHOW STAGES LIKE '%OPENBRIDGE%' IN ACCOUNT;

Then inspect the tables in the relevant schema.

Template:

SHOW TABLES IN SCHEMA <database_name>.<schema_name>;

Example from this environment:

SHOW TABLES IN SCHEMA OPENBRIDGE3_DATABASE.OPENBRIDGE3_SCHEMA;

Look at the owner column in the results. That role is usually the role that needs to be granted to the user completing OAuth authorization.

In this example, the owning role is:

OPENBRIDGE3_ROLE

The relevant object is:

OPENBRIDGE3_DATABASE.OPENBRIDGE3_SCHEMA.OB_TEST_V3

You can also confirm ownership grants on the schema:

SHOW GRANTS ON SCHEMA OPENBRIDGE3_DATABASE.OPENBRIDGE3_SCHEMA;

Look for the row where the privilege is:

OWNERSHIP

The grantee_name is the owning role.


Step 3: Grant the Owning Role to the User

Once you know the correct role, grant it to the user who needs to complete authorization.

For Bob:

USE ROLE ACCOUNTADMIN;  GRANT ROLE OPENBRIDGE3_ROLE TO USER "bob@apple.com";

This gives Bob access to the Snowflake role required for the external service authorization.

Important: the role name should not use angle brackets. Use the actual role name.

Incorrect:

GRANT ROLE <owning_role> TO USER "bob@apple.com";

Correct:

GRANT ROLE OPENBRIDGE3_ROLE TO USER "bob@apple.com";

Step 4: Set the User’s Default Role

Set the user’s default role to the role they should use during authorization.

ALTER USER "bob@apple.com" 
SET DEFAULT_ROLE = OPENBRIDGE3_ROLE;

This makes Snowflake start Scott in the correct role when he logs in.

The full command set is:

USE ROLE ACCOUNTADMIN;  
GRANT ROLE OPENBRIDGE3_ROLE TO USER "bob@apple.com";
ALTER USER "bob@apple.com" SET DEFAULT_ROLE = OPENBRIDGE3_ROLE;

Step 5: Verify the Grant

Confirm that the role was granted to the user:

SHOW GRANTS TO USER "bob@apple.com";

You should see:

OPENBRIDGE3_ROLE

in the results.


Step 6: Have the User Test Access

Ask Bob to log into Snowflake and run:

USE ROLE OPENBRIDGE3_ROLE;  
SHOW TABLES IN SCHEMA OPENBRIDGE3_DATABASE.OPENBRIDGE3_SCHEMA;

If he can see the expected tables, he should be able to complete the authorization flow using that role.


Step 7: Complete the External Service Authorization

Once the user has the correct role:

  1. The user opens the Openbridge service’s Snowflake connection or authorization page.

  2. The Openbridge service redirects the user to Snowflake’s OAuth authorization page.

  3. The user signs into Snowflake as themselves.

  4. The user selects or uses the granted role, for example:

OPENBRIDGE3_ROLE
  1. The user approves the authorization.

  2. The Openbridge service receives OAuth access to Snowflake under the authorized user and role.

For Openbridge OAuth configurations, Snowflake explains that the desired primary role can be passed either as the user’s default role or as a specific role granted to that user.


Troubleshooting

Error: unexpected '<'

This means Snowflake is seeing placeholder text.

Do not run:

GRANT ROLE <owning_role> TO USER "bob@apple.com";

Run the real role name instead:

GRANT ROLE OPENBRIDGE3_ROLE TO USER "bob@apple.com";

User cannot see the role

Have the admin check:

SHOW GRANTS TO USER "bob@apple.com";

If the role is missing, grant it again:

GRANT ROLE OPENBRIDGE3_ROLE TO USER "bob@apple.com";

User logs in but starts with the wrong role

Set the default role:

ALTER USER "bob@apple.com" SET DEFAULT_ROLE = OPENBRIDGE3_ROLE;

The user can also manually switch roles after login:

USE ROLE OPENBRIDGE3_ROLE;

OAuth succeeds but the external service cannot see data

Confirm that the authorized role can see the database, schema, stage, and tables needed by the service:

USE ROLE OPENBRIDGE3_ROLE;  
SHOW TABLES IN SCHEMA OPENBRIDGE3_DATABASE.OPENBRIDGE3_SCHEMA;
SHOW STAGES IN SCHEMA OPENBRIDGE3_DATABASE.OPENBRIDGE3_SCHEMA;

If the role cannot see the required objects, the admin may need to grant additional privileges or authorize with the actual owning/access role.


Example: Complete Script for This Case

USE ROLE ACCOUNTADMIN;

-- Confirm Openbridge-related schema
SHOW SCHEMAS LIKE '%OPENBRIDGE%' IN ACCOUNT;

-- Confirm Openbridge-related stages
SHOW STAGES LIKE '%OPENBRIDGE%' IN ACCOUNT;

-- Confirm tables and ownership
SHOW TABLES IN SCHEMA OPENBRIDGE3_DATABASE.OPENBRIDGE3_SCHEMA;

-- Confirm schema ownership grants
SHOW GRANTS ON SCHEMA OPENBRIDGE3_DATABASE.OPENBRIDGE3_SCHEMA;

-- Grant the owning/access role to the user who will authorize the external service
GRANT ROLE OPENBRIDGE3_ROLE TO USER "bob@apple.com";

-- Make that role the user's default role for login / OAuth authorization
ALTER USER "bob@apple.com" SET DEFAULT_ROLE = OPENBRIDGE3_ROLE;

-- Verify the user has the role
SHOW GRANTS TO USER "bob@apple.com";

After this, Bob should log into the external service authorization flow and authorize Snowflake using the OPENBRIDGE3_ROLE role.

Did this answer your question?