SSOJet SSO with MojoAuth

Connect SSOJet (opens in a new tab) to MojoAuth as an upstream OIDC identity source. SSOJet is an SSO/identity orchestration platform that federates end-customer logins to whatever identity provider each customer already uses — in this setup, SSOJet is the OIDC client (relying party) and MojoAuth is the OIDC provider.

SSOJet's admin console changes over time and can vary slightly by plan/version. The steps below describe the setup generically — "add an OIDC identity provider / connection" — because exact menu labels may differ from what's shown here. The MojoAuth-side values and steps are exact.

How it works

SSOJet acts as the OIDC Relying Party (client); MojoAuth is the OIDC Provider (OP).
The flow is standard Authorization Code: SSOJet redirects to MojoAuth's /oauth/authorize endpoint, MojoAuth authenticates the user, and SSOJet completes the exchange server-side using the Client ID/Secret you configure below.
SSOJet discovers MojoAuth's endpoints (authorization, token, userinfo, JWKS) from a single Discovery URL rather than requiring each endpoint to be entered manually.

Prerequisites

A MojoAuth project (test or live) with Developers access to create Applications.
An SSOJet account/workspace with admin access, and the ability to add a custom OIDC upstream identity provider / connection for the target organization or tenant. (Custom OIDC connections are typically gated to SSOJet's paid/business tiers — confirm this is enabled for your workspace before starting.)
Decide which SSOJet organization/tenant this connection applies to — SSOJet routes users to an identity provider per org, so the connection is normally scoped to one customer/tenant at a time.

Step 1 — Create the MojoAuth OIDC application

Create the application

In the MojoAuth dashboard: Developers → Applications → New Application → OIDC / OAuth 2.0. Give it a name (e.g. SSOJet) and save. See OIDC Applications for the full concept if you haven't created one before.

Note the Discovery URL and credentials

MojoAuth issues a Client ID and Client Secret (the secret is shown once — copy it somewhere safe). You'll also use the standard discovery URL:

Value	URL
Discovery / OpenID configuration	`{BASE}/.well-known/openid-configuration`
Issuer	`{BASE}`
Authorization endpoint	`{BASE}/oauth/authorize`
Token endpoint	`{BASE}/oauth/token`
UserInfo endpoint	`{BASE}/oauth/userinfo`
JWKS	`{BASE}/.well-known/jwks.json`
Logout	`{BASE}/oauth/logout`

Leave Allowed Callback URLs empty for now — you'll fill it in once SSOJet gives you its callback URL in Step 2.

Step 2 — Configure SSOJet

Add a new OIDC identity provider / connection

In the SSOJet admin console, go to the organization/tenant you're configuring and add a new OIDC identity provider (sometimes labeled "upstream connection", "custom OIDC provider", or similar depending on version). Choose OIDC as the protocol rather than SAML.

Enter the MojoAuth OIDC details

Fill in the connection form with the values from Step 1:

SSOJet field	Value
Issuer / Discovery URL	`{BASE}/.well-known/openid-configuration`
Client ID	`{client_id}`
Client Secret	`{client_secret}`
Scopes	`openid profile email`

If SSOJet asks for individual endpoints instead of a single discovery URL, use the Authorization, Token, UserInfo, and JWKS URLs from the table in Step 1.

Copy the Redirect / Callback URL

After saving, SSOJet generates a Redirect URL (also called Callback URL) for this connection — something like https://<your-ssojet-domain>/callback or a tenant-scoped variant. Copy it; you need it in Step 3.

⚠️

Don't enable/activate the connection yet if SSOJet lets you save a draft first. Confirm the callback URL is registered on the MojoAuth side (Step 3) before turning it on for real users, otherwise logins will fail with a redirect mismatch.

Step 3 — Give the redirect URL back to MojoAuth

Add the callback URL to the MojoAuth application

Back in the MojoAuth dashboard, open the OIDC application from Step 1 and add SSOJet's redirect URL to Allowed Callback URLs. This must be an exact match (scheme, host, path, and any trailing slash) — MojoAuth rejects the OIDC flow if the redirect_uri sent by SSOJet doesn't exactly match an allowed value.

Save

Save the application. The connection is now ready to be tested end-to-end.

Step 4 — Claim / attribute mapping

MojoAuth's id_token (and /oauth/userinfo response) returns standard OIDC claims when the openid profile email scopes are requested. Map these to SSOJet's user profile fields on the connection's attribute/claim mapping screen:

MojoAuth claim	Typical SSOJet profile field	Notes
`sub`	External/unique user ID	Stable identifier MojoAuth issues per user — use this to match returning users, not email alone.
`email`	Email	Primary matching key for most SSOJet tenants.
`email_verified`	—	Use to gate auto-provisioning if SSOJet supports conditional JIT rules.
`name`	Full name	Populated from the user's profile in MojoAuth.
`given_name` / `family_name`	First name / Last name	Only present if populated on the MojoAuth user profile.

If SSOJet's mapping UI expects raw claim names rather than a dropdown of standard fields, map email → email, name → display name, and sub → external ID. Add phone to the requested scopes only if you also need phone_number and have configured it on the MojoAuth user profile.

Enable the connection for the target org/tenant

Once mappings are set, enable/activate the OIDC connection for the organization or tenant it belongs to. If SSOJet supports per-tenant routing (e.g. by email domain or a login hint), confirm the target tenant is configured to route to this connection rather than falling back to password login.

Step 5 — Test

Start a login from SSOJet — either the tenant's hosted login page or by triggering "Sign in with SSO" for the org you configured.
You should be redirected to MojoAuth's hosted login ({BASE}/oauth/authorize?...), sign in, and be redirected back to SSOJet's callback URL with an authorization code.
SSOJet exchanges the code server-side and completes the login — you should land back in the target application, signed in, with the mapped email/name populated on the user's SSOJet profile.
Confirm claim mapping worked by checking the user's profile in SSOJet's admin console (email, name, and external ID should match the values from MojoAuth).

Test with a MojoAuth user that has a verified email and a populated name first, so you can confirm every mapped field arrives correctly before rolling this out to a full customer tenant.

Troubleshooting

"redirect_uri_mismatch" / MojoAuth rejects the callback The URL SSOJet actually sends as redirect_uri doesn't exactly match an entry in the MojoAuth application's Allowed Callback URLs. Copy the callback URL directly from the SSOJet connection (not typed by hand) and re-paste it into MojoAuth, watching for http vs https, trailing slashes, and tenant-specific path segments.

SSOJet can't fetch the discovery document Confirm {BASE}/.well-known/openid-configuration is reachable from SSOJet's network (no VPN/IP allowlist blocking it) and that you copied the full URL including .well-known/openid-configuration, not just the base origin. If SSOJet caches discovery documents, remove and re-add the connection after any MojoAuth-side endpoint change.

Login succeeds at MojoAuth but SSOJet shows an error before finishing Usually a scope or client secret problem: confirm openid is included in the requested scopes (it's required for OIDC), and that the Client Secret in SSOJet matches the current one in the MojoAuth application — secrets are shown only once at creation, so if it was lost you'll need to regenerate it in MojoAuth and update SSOJet.

Missing name/email on the SSOJet user profile after login The profile and/or email scopes weren't requested, or the mapping table wasn't saved. Confirm scopes are openid profile email and that the claim mapping in Step 4 points email/name at the correct SSOJet profile fields, then re-test.

User lands in the wrong organization/tenant, or SSO isn't triggered at all SSOJet routes users to an identity provider per org/tenant. Confirm the connection was enabled for the correct tenant in Step 4, and that whatever routing rule SSOJet uses (login hint, email domain, or explicit tenant selection) actually resolves to this connection for the test user.

Client secret rejected / "invalid_client" at the token endpoint The secret was regenerated in MojoAuth after SSOJet was configured, or was copied with extra whitespace. Regenerate the Client Secret on the MojoAuth application, copy it carefully, and update it in the SSOJet connection.

Next steps

OIDC Applications — application concepts, scopes, and claims.
Managing Applications — edit, disable, or delete this application.
Integration Guides overview — more provider guides.