Set up OIDC SSO with Auth0

This guide walks you through configuring Auth0 as the OIDC identity provider for Gluesync CoreHub. It covers the Auth0 dashboard configuration, the Action that injects role claims into the tokens, and the corresponding CoreHub configuration.

For the underlying OIDC concepts (claim path syntax, role mapping rules, login flow), see OIDC (OpenID Connect) Authentication.

Before you begin

You need:

  • An Auth0 tenant. The free Auth0 by Okta plan is sufficient.

  • Administrative access to your Gluesync CoreHub.

  • The HTTPS URL of your Gluesync instance (referred to below as https://gluesync.example.com).

  • The Authorization Core feature enabled in Auth0. This is on by default for all tenants.

High-level flow

  1. Register a Regular Web Application in Auth0.

  2. Create the Auth0 roles you want to map to Gluesync roles (manager, viewer, etc.).

  3. Assign the roles to your users.

  4. Create a Post-Login Action that adds the assigned roles to the ID and access tokens as a namespaced custom claim.

  5. Deploy the Action and attach it to the Login flow.

  6. Configure OIDC in Gluesync CoreHub, pointing roleClaimPath at the same namespace used in the Action.

Step 1 — Register the application in Auth0

  1. Log in to the Auth0 Dashboard and select your tenant.

  2. Go to Applications → Applications → Create Application.

  3. Name it (for example Gluesync CoreHub), select Regular Web Applications, and click Create.

  4. On the application page, open the Settings tab and fill in:

    Field Value

    Allowed Callback URLs

    https://gluesync.example.com/oidc/callback

    Allowed Logout URLs

    https://gluesync.example.com/ui/v2/login

    Allowed Web Origins

    https://gluesync.example.com

  5. Scroll down and click Save Changes.

  6. At the top of Settings, note the Domain, Client ID, and Client Secret — you will paste them into Gluesync in Step 5.

The Auth0 Domain is the base of the OIDC issuerUrl, with \https:// in front. For example, the domain your-tenant.eu.auth0.com becomes issuerUrl = "https://your-tenant.eu.auth0.com".

Allowed Logout URLs must include the exact URI https://gluesync.example.com/ui/v2/login. CoreHub always sends that path as post_logout_redirect_uri after Logout. Origin-only values such as https://gluesync.example.com are not sufficient.

Gluesync does not take a custom Signout URL in Settings → OIDC Authentication. It uses Auth0’s discovery end_session_endpoint automatically. Without the exact URI on the Auth0 allowlist, Auth0 shows an error page after logout even though CoreHub has already ended the local session.

Step 2 — Create roles in Auth0

  1. In the dashboard, go to User Management → Roles.

  2. Click Create Role, name it (for example manager), give it a short description, and save. Repeat for each role you want to expose to Gluesync (a typical setup is manager and viewer).

  3. Optionally add permissions to the roles. Gluesync only needs the role name, so permissions inside Auth0 are not required for the integration to work.

Step 3 — Assign roles to a test user

  1. Go to User Management → Users and pick (or create) a test user, for example peppe.scarpa@example.com.

  2. Open the user, switch to the Roles tab, click Assign Roles, select the role created in Step 2, and confirm.

Step 4 — Inject roles into the tokens with a Post-Login Action

By default, Auth0 does not include role names in the ID token or in the /userinfo response. You need to inject them via a Post-Login Action using a namespaced custom claim.

Create the Action

  1. Go to Actions → Library → Build Custom.

  2. Click Create Action, give it a name (for example Gluesync — inject roles), choose the Login / Post Login trigger, leave the runtime at the default Node.js version, and click Create.

  3. Replace the code with the following:

    exports.onExecutePostLogin = async (event, api) => {
  const namespace = 'https://gluesync.com';

  if (event.authorization && event.authorization.roles) {
    api.idToken.setCustomClaim(`${namespace}/roles`, event.authorization.roles);
    api.accessToken.setCustomClaim(`${namespace}/roles`, event.authorization.roles);
  }
};

    The namespace value is arbitrary, but it must be a URI (Auth0 enforces this) and it must match the roleClaimPath you configure in Gluesync. The convention used throughout the Gluesync documentation is https://gluesync.com, which produces the claim name https://gluesync.com/roles.

    You can use any domain you control. Auth0 strips any claim whose key starts with reserved namespaces such as auth0.com, webtask.io, or webtask.run.

  4. Click Deploy.

Attach the Action to the Login flow

Deploying alone is not enough — you must also attach the Action to the Login flow.

  1. Go to Actions → Flows → Login.

  2. Drag the new Action from the Custom tab onto the flow, between Start and Complete.

  3. Click Apply.

You can verify the Action runs by opening it from Actions → Library and pressing Test. The result should show your custom claim in the returned id_token payload preview.

Step 5 — Configure OIDC in Gluesync CoreHub

  1. Log in to CoreHub as the local admin user.

  2. Go to Settings → OIDC Authentication.

  3. Fill in the configuration:

    Field Value

    Enable OIDC

    toggle on

    Provider Name

    Auth0

    Issuer URL

    https://your-tenant.auth0.com (or .eu.auth0.com, .us.auth0.com depending on your tenant region)

    Client ID

    from Step 1

    Client Secret

    from Step 1

    Redirect URI

    https://gluesync.example.com/oidc/callback (the UI auto-fills this; it must exactly match what you configured in Auth0)

    Scopes

    openid, profile, email

    Role Claim Path

    https://gluesync.com/roles — must match the namespace + "/roles" from your Action

    Default Role

    VIEWER

    Auto-provision Users

    on

    Role Mappings

    		 
    {
  "manager": "MANAGER",
  "viewer": "VIEWER"
}

  4. Click Save.

Equivalent REST API payload:

{
  "enabled": true,
  "providerName": "Auth0",
  "issuerUrl": "https://your-tenant.auth0.com",
  "clientId": "your-auth0-client-id",
  "clientSecret": "your-auth0-client-secret",
  "redirectUri": "https://gluesync.example.com/oidc/callback",
  "scopes": ["openid", "profile", "email"],
  "roleClaimPath": "https://gluesync.com/roles",
  "defaultRole": "VIEWER",
  "autoProvisionUsers": true,
  "roleMappings": {
    "manager": "MANAGER",
    "viewer": "VIEWER"
  }
}

Step 6 — Verify

  1. Log out of Gluesync (or open a new private browser window).

  2. On the login page, click Login with Auth0.

  3. Authenticate with the test user (peppe.scarpa@example.com).

  4. After redirect, you should be logged into CoreHub.

To confirm the role was mapped correctly:

  1. Decode the MOLO17 session token at https://jwt.io (the token is available in the browser dev tools as a cookie or visible in the response of the /oidc/callback?code=…​ request).

  2. The payload must show the role you expect, for example:

    {
  "iss": "MOLO17",
  "sub": "peppe.scarpa@example.com",
  "plan": "trial",
  "role": "MANAGER"
}

  3. Also confirm the user appears in Settings → User Management with an OIDC badge and the resolved role.

Troubleshooting

The MOLO17 token still shows "role": "VIEWER"

This is the classic Auth0 misconfiguration. Walk through the checks in order:

  1. Is the Post-Login Action attached to the Login flow? Open Actions → Flows → Login and confirm the Action is on the canvas between Start and Complete. Deploying the Action in the library is not enough — it must be dragged onto the flow.

  2. Does roleClaimPath exactly match namespace + "/roles"? With the default Action snippet, that string is https://gluesync.com/roles. Any difference — including a trailing slash on the namespace — breaks the lookup.

  3. Is the role assigned to the user? In User Management → Users → the user → Roles tab, confirm the expected role is listed.

  4. Does the role name match a roleMappings key? Auth0 role names are case-insensitively matched, but the entire string must match. manager will not match a mapping key of auth0-manager.

  5. Does the access token contain the claim? Use Actions → Library → your Action → Test. The output preview should include https://gluesync.com/roles in the id_token (and access token if requested). If it does not, the Action’s event.authorization.roles is empty — usually because the user has no roles assigned.

Auth0 only emits namespaced custom claims inside the ID token (and access token when explicitly requested by the Action), not on the /userinfo endpoint. CoreHub 2.2.7 and later automatically reads these claims from the ID token when they are missing from /userinfo, so no extra configuration is needed.

Failed to exchange authorization code

  • Check the Client Secret in CoreHub matches the Client Secret in Auth0 Settings.

  • Confirm the Allowed Callback URLs in Auth0 contains the exact redirect URI shown in CoreHub (including scheme, host, port, and /oidc/callback).

Invalid or expired OIDC state

  • Clear the browser’s cookies for the Gluesync domain and retry. States expire after 10 minutes.

  • Do not open multiple login tabs simultaneously.

Stuck on an Auth0 error page after Logout

  • Cause: Allowed Logout URLs does not include the exact URI CoreHub sends as post_logout_redirect_uri.

  • Solution: Add https://gluesync.example.com/ui/v2/login to Allowed Logout URLs and save the application. Origin-only (https://gluesync.example.com) is not sufficient. Gluesync does not take a custom Signout URL.

For more general troubleshooting, see the troubleshooting section of the main OIDC page.