> ## Documentation Index > Fetch the complete documentation index at: https://docs.getcollate.io/llms.txt > Use this file to discover all available pages before exploring further. # Azure SSO Configuration for Confidential Apps > Learn to configure Azure SSO for confidential clients with OIDC, secure token handling, and client secret setup for web and backend apps. # Azure AD SSO Authentication – Confidential Client Configuration * [Troubleshooting](#troubleshooting) ## Overview **Azure Active Directory (Azure AD) Single Sign-On (SSO)** allows users to log in securely using their **Microsoft 365 / Entra ID** accounts via **OAuth 2.0** and **OpenID Connect (OIDC)**. This guide covers the **Confidential Client** configuration, intended for **web applications and backend services** that can securely store secrets. Collate supports Single Sign-On (SSO) integration with various identity providers, enabling secure, centralized user authentication. * **Navigate to:** `Settings > SSO` SSO Authentication * Select the service provider. Supported Providers Click Configure to set up Single Sign-On (SSO). After completing the configuration, click Save to apply the changes. Azure AD SSO Configuration - Confidential Client ## Confidential Configuration Fields This section contains the form fields that must be completed when setting up Single Sign-On (SSO). ### Client Type * **Definition:** Defines whether the application is public (no client secret) or confidential (requires client secret). * **Options:** `Public` | `Confidential` * **Example:** `Confidential` * **Why it matters:** Determines security level and OAuth flow. * **Note:** * Use `Confidential` for secure applications and backend services. * Azure typically uses `Confidential` type. ### Authority * **Definition:** Azure AD endpoint that issues tokens for your tenant. * **Example:** `https://login.microsoftonline.com/your-tenant-id` * **Why it matters:** Tells Collate which Azure AD tenant to authenticate against. * **Note:** * Replace `your-tenant-id` with your Azure AD tenant ID. * Use `common` for multi-tenant applications. ### Public Key URLs * **Definition:** List of URLs where Azure AD publishes public keys for token verification. * **Example:** `["https://login.microsoftonline.com/common/discovery/v2.0/keys"]` * **Why it matters:** Verifies JWT token signatures. * **Note:** Usually auto-discovered via the discovery URI. ### Token Validation Algorithm * **Definition:** Algorithm used to validate JWT token signatures. * **Options:** `RS256`, `RS384`, `RS512` * **Default & Example:** `RS256` * **Why it matters:** Must match Azure AD’s signing algorithm. * **Note:** Azure AD typically uses `RS256`. ### Client Type (OIDC IDP Type) * **Definition:** Defines whether the application is public (no client secret) or confidential (requires client secret). * **Options:** `Public` | `Confidential` * **Example:** `Confidential` * **Why it matters:** Determines security level and OAuth flow. * **Note:** * Use `Confidential` for secure applications and backend services. * Azure typically uses `Confidential` type. ### OIDC Client ID * **Definition:** Application (client) ID for OIDC authentication with Azure AD. * **Example:** `12345678-1234-1234-1234-123456789012` * **Why it matters:** Identifies the application to Azure AD. * **Note:** Same as the Application (client) ID in Azure AD app registration. ### OIDC Client Secret * **Definition:** Secret key for confidential client authentication. * **Example:** `abc123def456ghi789jkl012mno345pqr678st` * **Why it matters:** Required to securely authenticate with Azure AD. * **Note:** * Create under **Certificates & secrets** in Azure AD. * Store securely and rotate periodically. ### OIDC Request Scopes * **Definition:** Permissions requested from Azure AD. * **Default:** `openid email profile` * **Example:** `openid email profile offline_access` * **Why it matters:** Defines what user information Collate can access and whether Azure AD returns a refresh token. * **Note:** For Azure authorization code flow with MCP OAuth, include `offline_access` so Azure AD can issue refresh tokens. Microsoft Entra ID returns refresh tokens only when the request includes the `offline_access` scope. ### OIDC Discovery URI * **Definition:** Azure AD’s OpenID Connect metadata endpoint. * **Example:**\ `https://login.microsoftonline.com/your-tenant-id/v2.0/.well-known/openid-configuration` * **Why it matters:** Auto-discovers OIDC endpoints. * **Note:** Replace `your-tenant-id` with your Azure AD tenant ID. ### OIDC Use Nonce * **Definition:** Prevents replay attacks. * **Default & Example:** `true` * **Why it matters:** Enhances OIDC request security. ### OIDC Preferred JWS Algorithm * **Default & Example:** `RS256` * **Why it matters:** Must match Azure AD’s token signing algorithm. * **Note:** Rarely needs to be changed. ### OIDC Response Type * **Definition:** OAuth response type expected. * **Options:** `id_token` | `code` * **Default & Example:** `id_token` * **Why it matters:** Determines the OAuth flow (`code` is more secure). ### OIDC Disable PKCE * **Definition:** Disables Proof Key for Code Exchange. * **Default & Example:** `false` * **Why it matters:** PKCE provides additional security. * **Note:** Should typically remain enabled (`false`). ### OIDC Max Clock Skew * **Definition:** Allowed time difference (in seconds) between systems. * **Example:** `0` * **Why it matters:** Prevents token rejection due to system clock differences. ### OIDC Client Authentication Method * **Definition:** How client authenticates with Azure AD. * **Options:** `client_secret_basic`, `client_secret_post`, `client_secret_jwt`, `private_key_jwt` * **Default & Example:** `client_secret_basic` * **Why it matters:** Must align with Azure AD app registration. ### OIDC Token Validity * **Definition:** Duration in seconds that tokens remain valid. * **Default:** `0` (use Azure AD default) * **Example:** `3600` * **Why it matters:** Balances token lifetime vs. security. ### OIDC Tenant * **Definition:** Azure AD tenant identifier. * **Example:** `your-tenant-id` or `company.onmicrosoft.com` * **Why it matters:** Defines which tenant to authenticate against. * **Note:** Use `common` for multi-tenant apps. ### OIDC Server URL * **Definition:** Base URL of Azure AD authentication server. * **Example:** `https://login.microsoftonline.com` * **Why it matters:** Defines the Azure AD issuer URL. ### Callback URL * **Definition:** Redirect URI where Azure AD sends auth responses. * **Example:** `https://yourapp.company.com/callback` * **Why it matters:** Must match Azure AD registered redirect URI. * **Note:** * Add to Azure AD → App registrations → Authentication. * Always use HTTPS. ### OIDC Max Age * **Definition:** Max authentication age before re-login is required. * **Example:** `3600` * **Why it matters:** Controls how often users must re-authenticate. ### OIDC Prompt * **Definition:** Controls login experience. * **Options:** `none`, `login`, `consent`, `select_account` * **Example:** `select_account` * **Why it matters:** Defines how login prompts behave. * **Note:** * `login`: Always prompt * `consent`: Prompt for permissions * `select_account`: Show account picker ### OIDC Session Expiry * **Definition:** How long user sessions remain valid (in seconds). * **Default & Example:** `604800` (7 days) * **Why it matters:** Controls session timeout for confidential clients. ### JWT Principal Claims * **Definition:** JWT fields used to identify users. * **Example:** `["preferred_username", "email", "sub"]` * **Why it matters:** Determines how users are mapped in Collate. * **Note:** Common claims: `email`, `preferred_username`, `upn`, `sub` ### JWT Principal Claims Mapping **Definition:** Maps JSON Web Token (JWT) claims to Collate user profile fields. **Supported keys:** Only `email` and `username` are valid mapping targets in `jwtPrincipalClaimsMapping`. **Example:** ```yaml theme={null} ["email:email", "username:preferred_username"] ``` **Why it matters:** Controls how SSO login data maps to user profiles in Collate. **Format:** `collate_field:jwt_claim` (for example, `"email:email"`). **Note:** The display name is derived automatically from standard OIDC/JWT claims — you don't need to configure it using `jwtPrincipalClaimsMapping`. If you need richer name handling, make sure Azure's app registration includes `given_name` and `family_name` as optional claims in the ID token — Collate will pick them up automatically. **Important:** Using any other key (for example, `name` or `firstName`) will cause the service to fail on startup with a validation error. ### Admin Principals * **Definition:** Users granted admin access in Collate. * **Example:** `["admin@company.com", "superuser@company.com"]` * **Why it matters:** Grants full admin privileges. * **Note:** Match these to your JWT claims. ### Bot Principals * **Definition:** Service/bot accounts used for background operations. * **Example:** `["metadata-bot@company.com"]` ### Principal Domain * **Definition:** Default domain for user principals. * **Example:** `company.com` * **Why it matters:** Helps construct full user identifiers. ### Enforce Principal Domain * **Definition:** Enforces user domain restriction. * **Default:** `false` * **Example:** `true` * **Why it matters:** Restricts logins to specified domains only. ### Enable Secure Socket Connection * **Definition:** Enables SSL/TLS for all SSO communication. * **Default:** `false` * **Example:** `true` * **Why it matters:** Ensures secure authentication flow. * **Note:** Recommended in production. ### Summary | Field | Example / Default | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Client Type | Confidential | | OIDC Client ID | 12345678-1234-1234-1234-123456789012 | | OIDC Client Secret | abc123def456... | | Callback URL | [https://yourapp.company.com/callback](https://yourapp.company.com/callback) | | Authority | [https://login.microsoftonline.com/your-tenant-id](https://login.microsoftonline.com/your-tenant-id) | | Discovery URI | [https://login.microsoftonline.com/\{tenant}/v2.0/.well-known/openid-configuration](https://login.microsoftonline.com/\{tenant}/v2.0/.well-known/openid-configuration) | | JWT Claims | `["preferred_username", "email", "sub"] ` | | JWT Mapping | `["email:email", "username:preferred_username"]` | | Token Validation Algorithm | RS256 | | Request Scopes | openid email profile offline\_access | | Session Expiry | 604800 | ### Troubleshooting If users are automatically logged out and unable to log in again due to a bad authentication configuration, you can reset the security setup using the following command: ``` ./bootstrap/openmetadata-ops.sh remove-security-config --force ``` After executing the command, **restart the server**. The authentication values from your YAML or Helm chart will then be reapplied on startup. The following tiles detail how to apply this configuration: Configure Auth0 SSO to access the UI and APIs. Configure Azure SSO to access the UI and APIs. Configure a custom OIDC SSO to access the UI and APIs. Configure Google SSO to access the UI and APIs. Configure Okta SSO to access the UI and APIs. Configure Amazon Cognito SSO to access the UI and APIs. Configure SAML SSO to access the UI and APIs. Configure LDAP SSO to access the UI and APIs.