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

  1. Log in to your OneLogin administration portal and go to ApplicationsApplications.
  2. Click Add App and search for the OpenID Connect (OIDC) connector.
  3. Give the app a name (e.g. "Curiosity SSO") and save it.
  4. On the Configuration tab, set the Redirect URI: {domain}/api/oneloginsso/completed-login-attempt
  5. On the SSO tab, configure the app to use the Authorization Code grant, and note down the Client ID and Client Secret.
  6. 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

  1. In Curiosity, navigate to ManageAccessSingle Sign-On (#/manage/access/sso).
  2. Select OneLogin.
  3. Enter the Domain, the Client ID and the Client Secret.
  4. 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 email claim in its user info.
© 2026 Curiosity. All rights reserved.
Powered by Neko