From d98193d1d43f73044f58b0b12d105b0fee7e049b Mon Sep 17 00:00:00 2001
From: pballai <46489780+pballai@users.noreply.github.com>
Date: Mon, 8 Dec 2025 16:36:26 -0500
Subject: [PATCH 1/2] AI Apps and security oauth revision
---
site/app/images/aiapps.svg | 580 ++++++++++++++++++++++++++++++++
site/app/styles/_overrides.scss | 4 +-
2 files changed, 582 insertions(+), 2 deletions(-)
create mode 100644 site/app/images/aiapps.svg
diff --git a/site/app/images/aiapps.svg b/site/app/images/aiapps.svg
new file mode 100644
index 00000000..f2fd950d
--- /dev/null
+++ b/site/app/images/aiapps.svg
@@ -0,0 +1,580 @@
+
\ No newline at end of file
diff --git a/site/app/styles/_overrides.scss b/site/app/styles/_overrides.scss
index 5b79d0c3..be5834ec 100644
--- a/site/app/styles/_overrides.scss
+++ b/site/app/styles/_overrides.scss
@@ -38,7 +38,7 @@ $color-partners: #7a5144;
$color-templates: #EC407A;
$icon-administration: 'administration.svg';
-$icon-aiapps: 'dataapps.svg';
+$icon-aiapps: 'aiapps.svg';
$icon-dataapps: 'dataapps.svg';
$icon-developers: 'developers.svg';
$icon-embedding: 'embedding.svg';
@@ -61,7 +61,7 @@ $icon-templates: 'workbook-template.svg';
@include codelab-card(['use-cases'], $color-use-cases, $icon-use-cases);
@include codelab-card(['functions'], $color-functions, $icon-functions);
@include codelab-card(['partners'], $color-partners, $icon-partners);
-@include codelab-card(['templates'], $color-templates, $icon-templates);
+@include codelab-card(['templates'], $color-templates, $icon-templates);
/** Categories in Use (so far):
Administration
From 20eb4e550fd8a143901288a2be2ab5945cdef9b1 Mon Sep 17 00:00:00 2001
From: pballai <46489780+pballai@users.noreply.github.com>
Date: Mon, 8 Dec 2025 16:36:36 -0500
Subject: [PATCH 2/2] AI Apps and security oauth revision
---
site/app/images/aiapps.svg | 733 ++++--------------
.../security_oauth_pkce_secure_integration.md | 61 +-
2 files changed, 203 insertions(+), 591 deletions(-)
diff --git a/site/app/images/aiapps.svg b/site/app/images/aiapps.svg
index f2fd950d..204be734 100644
--- a/site/app/images/aiapps.svg
+++ b/site/app/images/aiapps.svg
@@ -1,580 +1,159 @@
\ No newline at end of file
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 1a3fd826..85b1e639 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
@@ -85,6 +85,30 @@ Here's how OAuth 2.0 works when a user accesses embedded Sigma content:
KEY BENEFIT: OAuth 2.0 separates authentication from authorization, allowing fine-grained access control without sharing credentials.
+### Connection-Level vs Organization-Level OAuth
+
+When implementing OAuth with Sigma, you have two primary approaches for managing authentication:
+
+**Connection-Level OAuth:**
+- Each user authenticates individually with the data platform (Databricks, Snowflake, etc.)
+- Tokens are scoped to specific connections
+- **Supports PKCE for enhanced security** (this is the key advantage)
+- Ideal for embedded scenarios where user identity and individual permissions matter
+- Each query runs with the authenticated user's credentials
+- Provides the strongest audit trail and access control
+
+**Organization-Level OAuth:**
+- Uses a single service account or shared credentials for all users
+- All users query through the same organizational identity
+- Does not support PKCE
+- Simpler initial setup but less granular access control
+- Better for scenarios where all users have identical data permissions
+- Requires implementing Row-Level Security (RLS) separately if user-specific data access is needed
+
+
+
### Why OAuth 2.0 for Sigma Deployments?
**Security:**
@@ -186,12 +210,14 @@ Consider an enterprise scenario where you want to embed Sigma dashboards into yo
- Used for API requests
- Included in request headers
- Should never be logged or stored long-term
+- **Sigma Storage:** Access tokens are stored in buffer and encrypted using envelope encryption with AES256
**Refresh Tokens**
-- Longer-lived (days to months)
+- Longer-lived (up to 90 days)
- Used to obtain new access tokens
- Must be stored securely
- Can be revoked by authorization server
+- **Sigma Storage:** Refresh tokens are stored in MySQL, encrypted using unique keys per customer. Encryption keys are housed in a separate key store for enhanced security
**Token Expiration Flow in Sigma**
1. User views embedded Sigma dashboard, Sigma queries data with access token
@@ -256,29 +282,35 @@ OAuth 2.0 uses "scopes" to define what access a token grants. When Sigma integra
## Integration Architecture Patterns
Duration: 10
-### Pattern 1: Direct User Authentication
+### Pattern 1: Connection-Level OAuth with PKCE (Direct User Authentication)
-**Scenario:** Users authenticate directly with data platform before accessing Sigma
+**Scenario:** Users authenticate directly with data platform before accessing Sigma using connection-level OAuth with PKCE
**Flow:**
1. User accesses embedded Sigma dashboard in your application
-2. Application redirects to Databricks OAuth login page
-3. User logs in with their Databricks credentials
-4. Databricks issues access token to your application
-5. Application passes token to Sigma via embed API
-6. Sigma queries Databricks using user's individual token and permissions
+2. Application generates PKCE code challenge and redirects to data platform OAuth login (e.g., Databricks)
+3. User logs in with their data platform credentials
+4. Data platform issues access token to your application after validating PKCE verifier
+5. Application passes encrypted token to Sigma via embed API
+6. Sigma queries data platform using user's individual token and permissions
**Pros:**
+- **Supports PKCE for enhanced security** - protects against authorization code interception
- True user-level access control in Sigma - each user sees only their authorized data
- Complete audit trail showing exactly which user ran which Sigma queries
- No credential management in your application or Sigma connections
-- Leverages Databricks Unity Catalog row-level security automatically
+- Leverages platform-native security (e.g., Databricks Unity Catalog row-level security)
+- Strongest security posture for embedded analytics
**Cons:**
-- Requires all users to have individual Databricks accounts (licensing cost)
+- Requires all users to have individual data platform accounts (licensing cost)
- Additional login step interrupts embedded Sigma user experience
- More complex token management logic in your application
+
+
### Pattern 2: Service Account with Row-Level Security
**Scenario:** Sigma connects using shared service account, data filtered by user attributes
@@ -326,12 +358,13 @@ Duration: 10
### Choosing the Right Pattern for Sigma
-**Use Direct Authentication when:**
-- You need strongest security and auditability for Sigma usage
-- Users already have individual data platform accounts
+**Use Connection-Level OAuth with PKCE (Pattern 1) when:**
+- You need the strongest security posture with PKCE protection
- Regulatory compliance requires tracking which user ran which Sigma query
+- Users already have individual data platform accounts
- Data sensitivity is very high (healthcare, financial)
- You want to leverage platform-native permissions in Sigma dashboards
+- Enhanced security against authorization code interception is required
**Use Service Account with RLS when:**
- Embedding Sigma for external customers who don't have platform accounts
@@ -499,4 +532,4 @@ Be sure to check out all the latest developments at [Sigma's First Friday Featur
-
+
\ No newline at end of file