OneLogin
Curiosity supports Single Sign-On using OneLogin, over the tenant's OpenID Connect v2 endpoints.
Prerequisites
You will need the following information from your OneLogin administration portal:
- Domain — the OneLogin tenant domain, e.g.
my-company.onelogin.com, or the custom domain configured for the tenant - Client ID
- Client Secret
The OneLogin app must return an email claim — the workspace identifies a user by their email
address and the login fails without one.
Configuration Steps
1. Create a OneLogin application
- Log in to your OneLogin administration portal and go to Applications → Applications.
- Click Add App and search for the OpenID Connect (OIDC) connector.
- Give the app a name (e.g. "Curiosity SSO") and save it.
- On the Configuration tab, set the Redirect URI:
{domain}/api/oneloginsso/completed-login-attempt - On the SSO tab, configure the app to use the Authorization Code grant, and note down the Client ID and Client Secret.
- Assign the app to the users and roles that should be able to sign in.
Either token-endpoint authentication method works: the workspace authenticates the code exchange
with an HTTP Basic header first and retries with the credentials in the request body for apps
registered with client_secret_post.
2. Enter Details in Curiosity
- In Curiosity, navigate to Manage → Access → Single Sign-On (
#/manage/access/sso). - Select OneLogin.
- Enter the Domain, the Client ID and the Client Secret.
- Click Save.
The Domain is stored as a bare host: a pasted https:// prefix and any trailing slash are
removed on save. Clearing the Domain and saving disables OneLogin login and removes the stored
domain, client ID and client secret.
The client secret is write-only: the settings screen only shows whether the server holds one, and leaving the field empty keeps the stored value.
The login itself requests the openid, profile and email scopes. OneLogin returns no picture
claim, so no profile image is imported — a user's display name comes from the name claim, falling
back to the given and family names and finally to the email address.
SSO is a licensed feature — like Okta, Auth0 and SAML, OneLogin needs the full SSO tier, and the card prompts for a license upgrade instead of opening the settings when the workspace's license does not include it.
These settings are not environment variables
The OneLogin domain, client ID and client secret are read from the workspace configuration stored in
the graph, not from the environment. Exporting MSK_ONELOGIN_LOGIN_DOMAIN,
MSK_ONELOGIN_LOGIN_CLIENT_ID or MSK_ONELOGIN_LOGIN_CLIENT_SECRET in the container's environment
does not enable OneLogin login — configure it on the Single Sign-On page, or ship it in a
configuration sync payload.
Troubleshooting
- Invalid Domain or Client ID: OneLogin displays an error immediately upon redirection.
- Invalid Client Secret: Login succeeds on OneLogin, but fails upon returning to Curiosity.
- Redirect URI Mismatch: Ensure the redirect URI registered on the OneLogin app matches your
workspace URL exactly. The workspace builds it from
MSK_PUBLIC_ADDRESS, falling back to the hostname of the incoming request when that is unset. - Login fails with a missing email: The OneLogin app is not returning an
emailclaim in its user info.
Related
- Single Sign-On overview — redirect URI shape shared by all providers.
- Configuration sync