Auth0 SSO with MojoAuth

Connect Auth0 to MojoAuth using OpenID Connect (OIDC), with MojoAuth acting as an upstream identity provider that Auth0 federates to. MojoAuth is the OIDC provider; Auth0 is the client (downstream) — Auth0 redirects users to MojoAuth to authenticate, then continues its own login flow (rules, Actions, downstream apps) with the identity MojoAuth returns.

How it works

Auth0 sits in the middle: it is the Service Provider to your downstream apps and the OIDC client to MojoAuth. Any app already wired up to Auth0 gains MojoAuth as a login option without integrating with MojoAuth directly.

Federating an upstream OIDC provider (Enterprise or Custom Social connections) is available on paid Auth0 plans. Free tier limits the number of enabled enterprise/social connections — confirm your Auth0 plan supports adding another external OIDC connection before starting.

Prerequisites

A MojoAuth project (test or live) with access to Developers → Applications.
An Auth0 tenant with Admin access to the Auth0 Dashboard.
Your Auth0 tenant domain, e.g. https://your-tenant.us.auth0.com (or a configured custom domain).
Decide whether to expose MojoAuth as an Enterprise connection (recommended — for workforce/B2B login, scoped to specific Auth0 Applications) or a Custom Social connection (for consumer-style "continue with" buttons). This guide uses the Enterprise OIDC path; the fields are the same either way.

Step 1 — Create the MojoAuth OIDC application

Create a new OIDC application

In the MojoAuth dashboard, go to Developers → Applications → New Application → OIDC / OAuth 2.0. Give it a name (e.g. Auth0 — Acme Tenant) so it's identifiable later.

Set a placeholder callback URL

Auth0 won't show you its callback URL until after you create the connection in Step 2, so set a placeholder in Allowed Callback URLs for now (e.g. https://your-tenant.us.auth0.com/login/callback if you already know your tenant domain) — you'll confirm and lock this down in Step 3.

Copy the Client ID and Client Secret

Click Create (or Save). MojoAuth issues:

Client ID — {client_id}
Client Secret — {client_secret} (shown once — copy it now and store it securely; you'll paste both into Auth0 in Step 2)

For background on OIDC applications, see OIDC Applications.

Step 2 — Configure Auth0

Open the Enterprise OpenID Connect connection screen

In the Auth0 Dashboard, go to Authentication → Enterprise → OpenID Connect, then click Create Connection.

If you'd rather present MojoAuth as a "continue with" social button instead of an enterprise connection, use Authentication → Social → Create Custom and choose the OIDC connection type there instead. The configuration fields below are the same.

Enter the discovery / issuer details

Fill in the connection form:

Auth0 field	Value
Connection Name	e.g. `mojoauth`
Issuer URL / Discovery URL	`{BASE}/.well-known/openid-configuration`
Client ID	MojoAuth Client ID — `{client_id}`
Client Secret	MojoAuth Client Secret — `{client_secret}`
Type	Back Channel (authorization code — Auth0 exchanges the code server-side at the token endpoint)
Scopes	`openid profile email`

Auth0 fetches MojoAuth's discovery document from the Issuer/Discovery URL and auto-populates the authorization, token, userinfo, and JWKS endpoints from it — you don't need to enter /oauth/authorize, /oauth/token, /oauth/userinfo, or /.well-known/jwks.json individually.

⚠️

Use Back Channel (Authorization Code), not Front Channel (implicit) — Front Channel connections don't use a client secret and Auth0 treats them as lower-trust. MojoAuth's OIDC apps are designed for the standard authorization code flow.

Save the connection

Click Create (or Save). Auth0 now shows this connection's own Callback URL — copy it, you'll need it in Step 3.

Step 3 — Give Auth0's callback URL back to MojoAuth

Copy Auth0's callback URL

On the connection you just created, Auth0 shows a fixed callback URL of the form:

https://<your-tenant>.auth0.com/login/callback

(or https://<your-custom-domain>/login/callback if the tenant uses a custom domain).

Add it to MojoAuth's Allowed Callback URLs

Back in the MojoAuth dashboard, open the OIDC application from Step 1 and replace the placeholder in Allowed Callback URLs with the exact URL Auth0 showed you. Save.

MojoAuth matches callback URLs exactly. Copy the URL directly from the Auth0 connection screen rather than retyping your tenant name — a mismatched scheme, trailing slash, or subdomain will cause the redirect to be rejected.

Enable the connection for your Auth0 Applications

Enterprise and Custom Social connections aren't automatically available to every Auth0 Application. On the connection's Applications tab, toggle it on for each Auth0 Application (client) that should offer MojoAuth as a login option.

Step 4 — Claim mapping

MojoAuth returns standard OIDC claims in the ID token and from /oauth/userinfo based on the scopes Auth0 requested (openid profile email):

Claim	Description
`sub`	MojoAuth user identifier
`email`	User's email address
`email_verified`	Whether the email is verified
`name`, `given_name`, `family_name`	Profile claims (if populated on the MojoAuth user)

Auth0 maps these into its own normalized user profile automatically (sub → user_id suffixed with the connection name, email, name, etc.). If a downstream app needs a different shape — for example, promoting a MojoAuth custom claim into app_metadata, or renaming a claim — add an Auth0 Action (opens in a new tab) on the Login / Post Login trigger:

exports.onExecutePostLogin = async (event, api) => {
  if (event.connection.name === 'mojoauth') {
    const claims = event.authentication?.methods ?? [];
    // Example: copy a MojoAuth-issued claim into Auth0's ID token namespace
    if (event.user.email) {
      api.idToken.setCustomClaim('https://your-app.example.com/email', event.user.email);
    }
  }
};

Auth0 Actions run after Auth0 has already exchanged the code and fetched the MojoAuth profile — use them to reshape or enrich claims for downstream apps, not to change what MojoAuth itself returns.

Step 5 — Test

Test from Auth0

Use Auth0's Try button on the connection (or trigger Universal Login for an Application with the connection enabled). You should be redirected to MojoAuth's login page, authenticate, and land back in Auth0 signed in with the MojoAuth-sourced profile.

Test from MojoAuth (Test SSO)

From the MojoAuth OIDC application page, use Test SSO to run an authorization-code round trip against the redirect URL on file, confirming MojoAuth issues tokens correctly independent of Auth0.

Test end-to-end through a downstream app

Sign in to a real downstream application that authenticates via Auth0, choose the MojoAuth connection/button, and confirm the full round trip: app → Auth0 → MojoAuth → back to Auth0 → back to the app, signed in.

Troubleshooting

"Callback URL mismatch" / `Unauthorized` at the MojoAuth authorize step

The Auth0 callback URL saved in MojoAuth's Allowed Callback URLs doesn't exactly match the one Auth0 sends. Re-copy https://<your-tenant>.auth0.com/login/callback (or your custom domain's equivalent) from the Auth0 connection screen — a missing https://, wrong tenant region, or custom-domain vs. default-domain mismatch will fail here.

Auth0 can't fetch the discovery document

If Auth0 reports it can't reach or parse the issuer, confirm the Issuer URL / Discovery URL is exactly {BASE}/.well-known/openid-configuration (including the .well-known path) and that {BASE} is your project's real hosted-login origin, not a typo'd or non-public URL. Also confirm the connection Type is Back Channel — Front Channel connections skip some of this validation and behave differently.

`invalid_client` or token exchange fails

Usually the Client ID or Client Secret pasted into Auth0 doesn't match the MojoAuth OIDC application, or the secret was regenerated in MojoAuth after Auth0 was configured. Re-copy both values from the MojoAuth application page — remember the secret is only shown once, so if it was rotated you'll need to regenerate and re-paste it into Auth0.

Login succeeds at MojoAuth but Auth0 shows a scopes/claims error

Confirm the connection's Scopes field includes openid profile email — if openid is missing, Auth0 won't receive an ID token at all; if email is missing, downstream Actions or rules that expect event.user.email will see it as empty.

User signs in but the downstream app doesn't see expected profile fields

Check whether an Auth0 Action or rule on the Login flow is required to map or rename claims for that specific downstream app's expectations (see Step 4) — Auth0 does not automatically invent fields the app expects beyond the standard OIDC claims MojoAuth returns.

Works in "Try" from the dashboard but not in the real app

Auth0's Try button exercises the connection directly; it doesn't confirm the connection is enabled for the specific Application the real app uses. Re-check the connection's Applications tab and confirm the toggle is on for that Application's client ID.