Intended Audience: Okta administrators and Gumloop organization administrators. This setup is performed once at the organization level and enables Okta authentication for all organization members.
What This Guide Covers
This documentation walks through two main configuration areas:- Okta Configuration - Register Gumloop as an OAuth application in your Okta Admin Console
- Gumloop Configuration - Add the Okta OAuth credentials to your organization at gumloop.com/settings/organization/oauth-configuration
Overview
Okta integration enables enterprise organizations to leverage their existing identity management infrastructure for Gumloop authentication. Instead of managing separate credentials for each service, users authenticate through Okta, which acts as the central authorization server.How it works: This integration connects Gumloop to your Okta environment, allowing Gumloop to use Okta as an authentication provider. For this to work, your external services (Snowflake, NetSuite, Databricks, etc.) must already be configured to accept Okta as an OAuth provider. Gumloop then uses your Okta credentials to authenticate with these Okta-enabled services.
Why Use Okta with Gumloop?
Centralized Authentication
Single sign-on experience across all Gumloop-connected services
Enhanced Security
Leverage your organizationâs existing security policies and MFA
Simplified Management
Manage access and permissions from one central location
Compliance Ready
Meet enterprise security and compliance requirements
How It Works
When Okta is configured for Gumloop, authentication follows this flow:Okta acts as the intermediary between Gumloop and external services. Instead of Gumloop directly authenticating with services like Snowflake, it uses the access token from Okta to verify the userâs identity and permissions.
Prerequisites
Before configuring Okta for Gumloop, ensure you have:1
Okta Admin Access
You must have administrator privileges in your Okta organization to create applications and authorization servers.
2
External Services Pre-Configured with Okta
Critical: Each service you want to use with Gumloop (e.g., Snowflake, NetSuite, Databricks) must already be configured to use Okta as an External OAuth provider. This is a separate configuration done within each serviceâs settings, not in Gumloop.Without this prerequisite, authentication will fail even if Gumloop and Okta are properly connected.
3
Gumloop Organization
Your organization must be on an Enterprise plan and you must be an organization admin so you can access the OAuth Configuration page.
Configuration Procedure
The setup process involves three main stages: creating the Gumloop OAuth client, configuring an authorization server, and collecting the necessary information.Step 1: Create an OAuth Client for Gumloop
First, youâll create an OAuth-compatible client application in Okta that represents Gumloop.1
Navigate to Applications
- Log in to the Okta Admin Console
- Click Applications in the left sidebar
- Click Create App Integration
2
Select Application Type
- For Sign-in method, select OIDC - OpenID Connect
- For Application type, select Web Application
- Click Next
3
Configure Application Settings
Enter the following details:
- App integration name:
Gumloop - App logo: (Optional) Upload the Gumloop logo using this link
- Sign-in redirect URIs:
https://api.gumloop.com/auth/callback - Sign-out redirect URIs: (Leave blank)
- Controlled access: Choose based on your organizationâs needs (typically âAllow everyone in your organization to accessâ)
Youâll configure the grant types in the next step after the application is created.
4
Configure Grant Types
After saving, scroll to the Grant type section and click Edit:
- Under Client acting on behalf of itself, check:
- Client Credentials
- Under Core grants, ensure the following are checked:
- Authorization Code
- Refresh Token
- Click Save
Client Credentials grant type enables the application to authenticate on its own behalf, which is required for Gumloopâs OAuth flow.
5
Save Client Credentials
After configuring grant types, scroll down to the Client Credentials section. Youâll see:
- Client ID - Save this value (youâll need it as
<OAUTH_CLIENT_ID>) - Client secret - Click Show secret to reveal, then save this value (youâll need it as
<OAUTH_CLIENT_SECRET>)
Step 2: Create an Authorization Server
Next, set up an authorization server that will handle authentication requests for Gumloop.1
Access Authorization Servers
- In the Okta Admin Console, navigate to Security > API
- Click the Authorization Servers tab
- Click Add Authorization Server
2
Configure Server Details
Enter the following information:
- Name:
Gumloop Authorization Server(or your preferred name) - Audience: Your service URL (e.g.,
https://abc12345.snowflakecomputing.comfor Snowflake) - Description: Optional description for documentation purposes
3
Save the Authorization Server ID
After creating the authorization server, youâll see an Issuer URL with a format like:The Authorization Server ID is the part after
/oauth2/ (in this example: aus8x7abc123def). Save this value as <AUTHORIZATION_SERVER_ID> - youâll need it for Gumloop configuration.Step 3: Configure Scopes
Scopes define what permissions and data the Gumloop application can access.1
Add Base Scopes
- In your authorization server, click the Scopes tab
- Click Add Scope for each of the following:
2
Add Service-Specific Scopes
In addition to the base scopes, you must add service-specific scopes for each external service you want to use with Gumloop. These scopes define what roles and permissions users can access within each service.
Common Service Scope Examples:
Snowflake:- Create scopes for each role users need access to
- Format:
session:role:ROLE_NAME(role names must be uppercase unless created with quotes in Snowflake) - Examples:
session:role:PUBLIC- Basic read accesssession:role:ANALYST- Analyst rolesession:role:DATA_ENGINEER- Data engineer rolesession:role-any- Allows switching between available roles (advanced)
- Add NetSuite-specific role scopes as required by your NetSuite configuration
- Consult your NetSuite OAuth documentation for required scope formats
- Refer to each serviceâs External OAuth documentation for required scope formats
- Most services use role-based scopes similar to Snowflake
When creating each scope in Okta:
- Click Add Scope
- Scope name: Enter the exact scope (e.g.,
session:role:ANALYST) - Display name: Enter a user-friendly name (e.g., âSnowflake Analyst Roleâ)
- Description: Add a description for documentation
- Optionally mark as Default scope if all users should have this role
Step 4: Create Access Policy and Rules
Access policies control who can obtain tokens and under what conditions.1
Create an Access Policy
- In your authorization server, click the Access Policies tab
- Click Add Policy
- Enter the following:
- Name:
Gumloop Access Policy - Description: description
- Assign to: Select the Gumloop client application you created earlier
- Name:
- Click Create Policy
2
Add a Rule to the Policy
- In the newly created policy, click Add Rule
- Configure the rule:
- Rule name:
Standard Access Rule - Grant type: Select the following:
- Authorization Code
- Resource Owner Password
- Client Credentials
- Refresh Token
- User is: Select based on your organizationâs needs (typically âAny user assigned the appâ)
- Scopes requested: Select âThe following scopes:â and choose:
openidprofileemailoffline_access- Any service-specific scopes you created
- Token lifetime: Configure according to your security policies (defaults are typically sufficient)
- Rule name:
- Click Create Rule
Step 5: Collect Required Information
Now gather all the information youâll need to configure Gumloop.1
Verify Your Collected Information
Ensure you have all of the following values before proceeding to configure Gumloop:
These four values are all you need to configure Okta authentication in Gumloop. Make sure you have them ready before proceeding to the next section.
Configuring Gumloop OAuth Configuration
After completing the Okta setup, youâll need to add these credentials to Gumloop so your organization members can use Okta authentication.1
Navigate to OAuth Configuration
2
Add Okta OAuth Configuration
- Click Add Credential
- Search Okta OAuth
- Choose Okta as the authentication type

3
Enter Okta Details
Fill in the form with the four values you collected:
- Okta Domain:
<OKTA_DOMAIN>(e.g.,company.okta.com) - Authorization Server ID:
<AUTHORIZATION_SERVER_ID>(e.g.,aus8x7abc123def) - Client ID:
<OAUTH_CLIENT_ID> - Client Secret:
<OAUTH_CLIENT_SECRET>

User Authentication Flow
Once Okta is configured, hereâs what the authentication experience looks like for your organization members:- For Organization Members
- What Users See
Standard Authentication Experience
When a user needs to authenticate with a service that uses Okta:- Navigate to their Connectors page
- Find the service (e.g., Snowflake)
- Click the Authenticate button
- Get redirected to your organizationâs Okta login page
- Enter their Okta credentials
- Approve the requested permissions (first time only)
- Get redirected back to Gumloop - authentication complete!


Testing Your Configuration
Before rolling out Okta authentication to your entire organization, verify the setup works correctly.1
Test User Authentication
- Have a test user navigate to their Connectors page
- Click the authentication button for a configured service
- Verify theyâre redirected to Okta
- Complete the authentication flow
- Confirm successful authentication in Gumloop
2
Test Workflow Execution
- Create a simple workflow using the Okta-authenticated service
- Run the workflow
- Verify it executes successfully using Okta credentials
- Check that data is retrieved correctly
Advanced Configuration
Using ANY Role with External OAuth
Some services (like Snowflake) support a specialsession:role-any scope that allows users to switch roles after authentication rather than being locked to a specific role.
1
Add ANY Role Scope
In your authorization server, create a scope named
session:role-any with:- Display name:
Any Role - Description:
Allows switching between available roles after authentication
2
Configure Policy
Update your access policy rule to include the
session:role-any scope in the list of allowed scopes.3
User Experience
Users who authenticate with this scope can switch between their assigned roles within workflows, providing flexibility for workflows that require different permission levels.
Multiple Authorization Servers
For complex organizations, you may want separate authorization servers for different environments or services:- By Environment
- By Service
Development vs ProductionCreate separate authorization servers:
Gumloop Development- For testing and development workflowsGumloop Production- For production workflows
- Separate token lifetimes and policies
- Isolated audit trails
- Different scopes for each environment
Related Documentation
Credentials
Learn about personal, team, and organization credentials
AI Model Governance
Configure organization-wide AI model access and routing
Custom Roles
Manage organizational roles and permissions
Need Help?
If you encounter issues during setup or have questions about Okta integration:- Email: support@gumloop.com
- Okta Support: For Okta-specific configuration questions, consult Oktaâs documentation
