Microsoft Entra ID (formerly Azure AD)

Curiosity signs users in with Microsoft Entra ID over OAuth 2.0 / OIDC, and reads Microsoft 365 content (SharePoint, OneDrive, Teams, Outlook) through Microsoft Graph. Both use an app registration in a Microsoft tenant — and in a workspace running in your own cloud, that registration is yours to create.

The same registration can serve both purposes: the connectors fall back to the SSO credentials when they have none of their own.

Which registration applies to your deployment

For the Curiosity-hosted connector apps (Curiosity for SharePoint, Curiosity for OneDrive, Curiosity for Teams, Curiosity for Outlook, Curiosity for Outlook Calendar) and the tenant consent settings they need, see Configuring Curiosity for an Office 365 tenant.

1. Register the application

1. Sign in to the Azure Portal and open App registrations.

2. Select + New registration, name it (e.g. Curiosity Workspace), and choose Accounts in this organizational directory only unless users from other tenants have to sign in.

3. Under Redirect URI, choose Web and add the callbacks the workspace uses:

   Purpose	Redirect URI
   SSO login	{public-workspace-url}/api/microsoftsso/completed-login-attempt
   Microsoft 365 connector authorization	{public-workspace-url}/api/oauth/microsoft/authorize

   Add the second URI only if this registration is also used by the connectors.

4. Select Register, then note the Application (client) ID and Directory (tenant) ID.

2. Create a client secret

1. In the registration, open Certificates & secrets → + New client secret.
2. Set a description and expiry, select Add, and copy the Value immediately — it is not shown again.

Note the expiry date. When the secret expires, both SSO logins and connector token refreshes fail at the same time; see Rotating the client secret.

3. Add the API permissions

Under API permissions, add these delegated Microsoft Graph permissions and then select Grant admin consent for <tenant>:

Curiosity reads the signed-in user's email from the ID token's email claim, and falls back to Microsoft Graph /me (mail, then userPrincipalName) when that claim is absent. Adding email as an optional ID-token claim under Token configuration saves that extra call.

4. Enter the details in the workspace

Go to Manage → Access → Single Sign-On (#/manage/access/sso), select Microsoft, and fill in:

Clearing Tenant ID and saving disables Microsoft login and removes the stored tenant, client ID, client secret, SharePoint option, tenant name, and scope selection.

The values live in the workspace's own configuration, stored in the graph under the keys MSK_AZURE_LOGIN_TENANT_ID, MSK_AZURE_LOGIN_CLIENT_ID, MSK_AZURE_LOGIN_CLIENT_SECRET, MSK_AZURE_LOGIN_CREATE_SHAREPOINT, MSK_AZURE_CUSTOM_TENANT_NAME, and MSK_AZURE_CUSTOM_SCOPES. They travel with the graph and with configuration sync.

SSO is a licensed feature — the settings screen prompts for a license upgrade if the workspace's license does not include it.

Connecting SharePoint at login

With Connect Sharepoint on Login enabled, a successful Microsoft SSO login does double duty: the tokens it received are also stored as SharePoint connector credentials for that user, so the user never sees a second consent screen.

What happens on the first such login:

1. A SharePoint connector is created for the account's tenant, keyed by domain — its source is SharePoint (<domain>), or SharePoint (<upn> Personal) for an account with no mailbox domain. Tenant Name, when set, replaces the domain in that label.
2. The connector runs once immediately, then on its normal cadence (every 59 minutes).
3. Every later user from the same domain is added to that same connector as they log in.

Two consequences worth knowing:

• One Microsoft account per domain per user. If a user logs in with a second account on a domain that is already connected, the login fails with "Domain is already connected."
• A login is never failed for missing SharePoint. An account without SharePoint access still logs in; the connector simply finds nothing for that user.

Adding SharePoint access to this registration

Each Microsoft connector (SharePoint, OneDrive, Teams, Outlook) resolves its Entra credentials in this order:

1. Tenant ID + Client ID + Client Secret set on the connector itself — use this to point a connector at a different app registration or a different tenant.
2. The SSO credentials configured above — the fallback when the connector carries none. One registration, one secret to rotate.

If neither is available, the connector run fails with "missing Azure Application Credentials".

The connector's own consent request asks for openid profile email offline_access. The Graph permissions the resulting token actually carries are the delegated permissions granted on the app registration, which is why Sites.Read.All has to be configured and consented there rather than selected per connector.

Reusing the SSO registration for a SharePoint connector

To skip the per-user consent step entirely, enable Connect Sharepoint on Login instead — the connector is created and enrolled from the login tokens, using the same registration and the same Sites.Read.All grant.

The OneDrive, Teams, and Outlook connectors work the same way, through the same /api/oauth/microsoft/authorize callback and the same credential fallback. None of them pins a scope list of its own, so what they can read is decided entirely by the delegated permissions granted and consented on the registration — drive, chat, or mail permissions respectively, per Microsoft's Graph permissions reference.

Limiting which sites are synced

SitesAllowListWebUrls, on the SharePoint connector's settings, is a JSON array of site URLs. Empty (the default) means every site the connecting user can read; non-empty means only the listed sites:

[
  "https://contoso.sharepoint.com",
  "https://contoso.sharepoint.com/sites/Marketing",
  "https://contoso.sharepoint.com/sites/Marketing/Campaigns",
  "https://contoso.sharepoint.com/teams/Engineering"
]

Entries are compared to each site's Graph webUrl with an exact string match — no prefix matching, because the tenant root is itself a site and a prefix rule would pull in the whole tenant. In practice:

• List the root site (https://contoso.sharepoint.com) explicitly if you want it.
• List every subsite separately; allowing a parent does not include its children.
• No trailing slash, and match the casing Microsoft Graph returns.
• The filter applies to both document libraries and site pages — anything not on the list is never enumerated.

Two things the allowlist does not do: it cannot widen access (each user still only sees what their own Microsoft account can read), and removing a site from the list does not delete content already ingested from it — the site simply stops being refreshed. To remove the content, reset the connector or the user.

See Microsoft SharePoint for the connector's remaining settings, what it ingests, and how it maps access.

Tokens, expiry, and reconnects

• Each user's refresh token is stored with the connector in the graph and used to mint access tokens; a token is refreshed about six minutes before it expires.
• When a refresh fails, the user is marked as authentication-expired: their sync is skipped and the workspace prompts them to reconnect. Other users on the same connector keep syncing.
• Users who have not logged in for more than seven days are skipped by connector runs until they return.

Rotating the client secret

A secret in use by both SSO and the connectors takes both down when it expires. To rotate without a gap: add a second secret in the portal, paste it into Manage → Access → Single Sign-On → Microsoft (and into any connector carrying its own credentials), confirm a login and a connector run succeed, then delete the old secret.

Troubleshooting

Related

• Single Sign-On overview — redirect URI shape shared by all providers.
• Microsoft SharePoint connector
• Microsoft OneDrive connector
• Microsoft Teams connector
• Configuring Curiosity for an Office 365 tenant — tenant consent settings for the Curiosity-hosted apps.