Skip to main content
Findable uses up to four Azure identity surfaces. Each has its own app registration and permission set. Only the Client and Server registrations are required — SharePoint and Azure Search ACL are optional depending on which features you enable.
Tip: The Admin → Health page ([#/admin/about], setting key health.label) shows real-time status for every permission listed below.

1. Client App Registration (clientId)

This is the frontend SPA that users sign into. Configured in the setup wizard (Step 1) and stored as clientId in settings. Azure Portal → App Registrations → Client App Delegated Permissions (Microsoft Graph): Scope acquisition order (client falls back automatically):
  1. User.Read + Group.Read.All + User.Read.All (full)
  2. User.Read + Group.Read.All (groups only — fallback)
  3. User.Read + Directory.Read.All (last resort)
  4. User.Read only (guest users)

2. Server App Registration (graphClientId)

This is the backend server identity used for server-side Graph API calls. Configured in the setup wizard (Step 2) and stored as graphClientId / graphClientSecret in settings. Azure Portal → App Registrations → Server App Application Permissions (Microsoft Graph) — server-to-server, no user context: The server uses these least-privilege application permissions. Grant only what the features you’ve enabled actually need. Required — every authenticated request: Conditional — only when the named feature is in use: Broad-fallback (over-privileged, not recommended):
Grant admin consent for all application permissions after adding them. The runtime check at Admin → Health passes if Directory.Read.All is present OR one of {User.ReadBasic.All, User.Read.All} AND one of {GroupMember.Read.All, Group.Read.All} are both present.
Delegated Permissions (Microsoft Graph) — OBO flow, user context: These permissions are used by the On-Behalf-Of (OBO) flow when Exchange Online or OneDrive tools execute as the authenticated user. Each must be individually enabled in Admin → Delegated Permissions ([#/admin/delegated], setting key adminNav.delegatedPermissions) after granting consent. OBO setup steps:
  1. Add the delegated permissions above to the server app (not the client app)
  2. Click “Grant admin consent for [tenant]”
  3. Enable each scope in Admin → Delegated Permissions ([#/admin/delegated])
  4. Ensure graphClientId and graphClientSecret are configured (OBO does not work with managed identity)
Security note: All OBO Graph calls use /me/ endpoints — users can only access their own mailbox, calendar, and OneDrive. Cross-user access is not possible regardless of input parameters. Authentication modes:

3. SharePoint App Registration (sharePointClientId) — Optional

A separate app registration used for SharePoint document library indexing. Only needed if you use the SharePoint integration. Azure Portal → App Registrations → SharePoint App Application Permissions (Microsoft Graph):
If using Sites.Selected, you must grant the app access to each site individually using the SharePoint Entitlement page in Admin or the Grant-PnPAzureADAppSitePermission PowerShell command.
SharePoint Entitlement Administration: The admin UI uses a separate sharePointAdminClientId + API key to grant Sites.Selected permissions to sites. This admin identity needs: Authentication modes:

4. Azure Search ACL (Document-Level Security) — Optional

When enabled, Azure AI Search queries pass the user’s identity token so that search results are filtered based on document-level access control lists (ACLs). This is used with SharePoint-indexed content where documents inherit SharePoint permissions. Client App Registration → API Permissions: Setup steps:
  1. In the client app registration, add API permission: Azure Searchuser_impersonation (Delegated)
  2. Grant admin consent
  3. Enable in Admin → Delegated Permissions ([#/admin/delegated]) → Enable Document-Level ACL
When ACL is enabled, the client acquires an additional token scoped to https://search.azure.com/user_impersonation and sends it alongside search requests.

Quick Reference: Settings ↔ App Registration Mapping

Environment Variable Overrides

The settings above are normally configured through the Setup Wizard or Admin UI and stored in Cosmos DB. However, they can also be set as Azure App Service Application Settings (or environment variables for local development). Environment variables take precedence over Cosmos DB values when present.
Reminder: In production, set these in Azure App Service → Configuration → Application Settings. Do not use a .env file in production deployments.