Skip to main content
Curator can sign users in through any provider that supports OpenID Connect (OIDC). The provider handles the password and multi-factor prompts. Curator receives an ID token, reads the username from one of its claims, and creates the Curator user on the first sign-in. Select the OAuth / OpenID Connect tile. Curator shows a three step guide: Register Curator with your provider, Enter the provider details, and Test and turn on. Each step tells you which values to copy and in which direction.

​
Step 1: Register Curator with your provider

Create a web application in your provider’s admin console. The guide lists the three values the provider asks for, each with a copy button:
  • Redirect URI: the Curator URL with /user/oauth appended. Enter only this URI.
  • Post logout redirect URI: the Curator URL.
  • Scopes: openid profile email.
Copy each value into the matching field in the provider. Curator marks the step done after the first copy.

​
Step 2: Enter the provider details

The provider shows three values once the application exists. Enter them under OAuth / OpenID Connect below the guide:
  • Issuer URL: the provider’s issuer, for example https://login.microsoftonline.com/<tenant>/v2.0 for Entra ID or https://<subdomain>.okta.com for Okta. Curator derives the discovery URL from it and shows the result under the field.
  • Client ID: the application’s client ID.
  • Client secret: the application’s client secret. Curator stores it as a hidden value.
Click Check provider. Curator fetches the discovery document over HTTPS and reports the endpoints it will use, the scopes the provider supports, and whether the issuer in the document matches the one you entered. A mismatch usually means a missing or extra path segment in the Issuer URL, and sign-in fails until the two match.

​
Step 3: Test and turn on

Click Test sign-in. Curator opens the provider in a new window and signs you in with the details you saved, but records nothing for other users. When the provider answers, the card lists the claims in the ID token and marks the one Curator will use as the username. Pick a different claim if your Tableau usernames do not match the marked one. Curator writes your choice to the Username claim field under Compatibility overrides. Save the settings to make OAuth the active sign-in method. If the test fails, the card shows the provider’s error text. The most common causes are a redirect URI that does not match step 1 exactly, a wrong client secret, and an issuer URL that fails the check in step 2.

​
Users

Curator creates a user record the first time each person signs in. If Curator is connected to an analytics platform, it copies the display name and email from that platform during the same sign-in. No SCIM feed is needed. To stop Curator from creating accounts on sign-in, turn on Disable Just-in-time Provisioning of Curator Users under Access rules.

​
Compatibility overrides

The Compatibility overrides section holds the switches for providers that do not follow the defaults:
  • Username claim: the claim Curator reads as the username. Leave it blank to use the provider’s preferred_username, then name, email, emails, and sub in that order. Google accounts use email.
  • Use the hybrid flow (code + id_token): turn this on for providers that return the ID token with the authorization code.
  • Omit the logout redirect URI: turn this on when the provider rejects a post-logout redirect, so Curator ends its own session and sends the user to the provider’s sign-out page without a return address.
Provider guides: