diff --git a/site/sigmaguides/src/security_oauth_pkce_secure_integration/security_oauth_pkce_secure_integration.md b/site/sigmaguides/src/security_oauth_pkce_secure_integration/security_oauth_pkce_secure_integration.md index 85b1e639..213523d0 100644 --- a/site/sigmaguides/src/security_oauth_pkce_secure_integration/security_oauth_pkce_secure_integration.md +++ b/site/sigmaguides/src/security_oauth_pkce_secure_integration/security_oauth_pkce_secure_integration.md @@ -65,21 +65,25 @@ The person who owns the data and grants access to it. In Sigma deployments, this The application requesting access to protected resources on behalf of the user. When using Sigma Embedding, this is your custom application hosting embedded Sigma content (dashboards, workbooks, or visualizations). **Authorization Server:**
-The server that authenticates the user and issues access tokens after successful authorization. For Sigma integrations, this could be Databricks OAuth, Snowflake OAuth, or your corporate identity provider (Okta, Azure AD, etc.). +The server that authenticates the user and issues access tokens after successful authorization. For Sigma integrations, this is typically your cloud data warehouse's OAuth service (Snowflake, BigQuery, Redshift, etc.) or your corporate identity provider (Okta, Azure AD, etc.). **Resource Server:**
-The server hosting the protected resources (data). For Sigma users, this is your cloud data warehouse (Databricks, Snowflake, BigQuery, etc.) that Sigma queries on the user's behalf. +The server hosting the protected resources (data). For Sigma users, this is your cloud data warehouse (Snowflake, BigQuery, Redshift, Azure Synapse, etc.) that Sigma queries on the user's behalf. ### The Authorization Flow Here's how OAuth 2.0 works when a user accesses embedded Sigma content: 1. **User initiates action**: User clicks on embedded Sigma dashboard in your application -2. **Authorization request**: Your application redirects user to data platform's OAuth endpoint (e.g., Databricks login) -3. **User authentication**: User logs in with their data platform credentials +2. **Authorization request**: Your application redirects user to the authorization server (this could be your corporate SSO provider like Okta/Azure AD for federated identity, or directly to the data warehouse OAuth endpoint) +3. **User authentication**: User logs in with their credentials 4. **Authorization grant**: User approves Sigma's access request to query data on their behalf -5. **Token exchange**: Your application receives an access token from the authorization server -6. **Sigma queries data**: Sigma uses the token to query your data warehouse with the user's permissions +5. **Token exchange**: Your application receives an access token from the authorization server (if using federated identity, your application exchanges the SSO token for a data warehouse token) +6. **Sigma queries data**: Sigma uses the data warehouse token to query with the user's permissions + +