Skip to main content
emisar
Docs navigation

Get started

JumpCloud

Connect JumpCloud to emisar: one custom application carries OIDC sign-in and directory provisioning together.

Before you start, you need:
  • A JumpCloud administrator.
  • An emisar owner or admin.

Single sign-on#

Connecting an identity provider is a paid feature. Only available on Team & Enterprise.

  1. 1

    In emisar

    Start the connection.

    Open Team → Single sign-on → Add provider and choose JumpCloud. Leave the page open: the callback URL on it is what JumpCloud asks for next, and JumpCloud's values come back here at the end.

    emisar · Add provider
    Picking the provider here tailors the rest of the form to it.
  2. 2

    In JumpCloud

    Open SSO Applications.

    In the JumpCloud Admin Portal go to Access → SSO Applications and press Add New Application.

    JumpCloud · SSO Applications
    Every application JumpCloud signs people into is listed here. Provisioning shows against the ones that also push a directory.
  3. 3

    In JumpCloud

    Choose Custom Application.

    emisar is not in JumpCloud's catalog, so scroll past the featured tiles to Custom Application, press its Select, then Next.

    JumpCloud · Select Application
    The Custom Application tile sits last, after the catalog's featured integrations.
  4. 4

    In JumpCloud

    Enable SSO, and pick OIDC.

    Tick Manage Single Sign-On (SSO). That reveals a Select One pair beneath it — choose Configure SSO with OIDC. It defaults to SAML, and emisar's connection is OIDC, so this is the one click on the page that is easy to miss and hard to undo later.

    If you also want directory sync, tick Export users to this app (Provisioning) on this same step — JumpCloud carries both on one application. Leave Import users from this app off; that direction pulls into JumpCloud.

    JumpCloud · Select Options
    SSO with OIDC and Export users, together on one application. Import users stays off — it points the wrong way.
  5. 5

    In JumpCloud

    Name it.

    Display Label is what your people see in the JumpCloud User Portal — emisar is the obvious choice. Everything else on this step is cosmetic.

    JumpCloud · Enter General Info
    Only Display Label is required.
  6. 6

    In JumpCloud

    Check the summary, then configure.

    The review step lists what you just chose under Enabled Features. It should read SSO with OIDC — and User Export - Provisioning if you ticked it. If it says SAML, go Back and change the radio; emisar cannot use a SAML connector. Then press Configure Application.

    JumpCloud · Review
    Enabled Features is the check that the OIDC radio actually took.
  7. 7

    In JumpCloud

    Set the redirect URI, then activate.

    On the application's SSO tab, put emisar's callback in Redirect URIs:

    Redirect URI 
    https://emisar.dev/sign_in/sso/callback

    Leave Authorization Code as the grant type. Either Client Secret POST or Client Secret Basic works — emisar accepts both. Set Login URL to https://emisar.dev, then press Activate.

    JumpCloud · OIDC Single Sign-On Configuration
    Redirect URIs takes emisar's callback verbatim. Activate sits at the bottom right.
  8. 8

    In emisar

    Paste the two values it reveals.

    Activating shows the Client ID and Client Secret. They are the only two values you carry back. On the connection you opened in step 1, the issuer is already filled in and locked — it is the same for every JumpCloud org — so those two fields are all there is to fill. Tick Enabled, save, and sign in.

    emisar · Add provider
    Nothing to look up: JumpCloud's issuer is fixed, so emisar fills and locks it.
The rest of the connection form

This guide covers only what JumpCloud needs. The other settings on the connection — who gets provisioned and at what role, what runner access they start with, whether this provider satisfies your 2FA requirement — are the same for every provider and are explained in Single sign-on.

Directory sync#

If you ticked Export users to this app (Provisioning) on step 3, this same application pushes your directory — there is no second connector to create.

You need the connection's SCIM base URL and bearer token — enabling directory sync shows where both come from. Only available on Enterprise.

  1. 1

    In JumpCloud

    Point its Provisioning tab at emisar.

    Open the saved app's Provisioning tab (JumpCloud's own docs also call it Identity Management). The SCIM version is fixed at 2.0; set Authentication method to Bearer token, then fill Base URL with emisar's SCIM base URL and Token Key with the bearer. Test User Email must be an address that doesn't exist in emisar yet — JumpCloud provisions and then deletes it as a live check, so an existing member would fail activation.

    JumpCloud · Provisioning
    Test Connection is a live check: JumpCloud calls emisar before it will activate.
  2. 2

    In JumpCloud

    Test Connection, then Activate.

    Press Test Connection, then Activate. Activation is not a formality: it creates, renames and deletes a probe group, and provisions and removes the test user, against your live emisar. Do not press Save instead — JumpCloud discards the configuration and you start over.

    Then bind the people you want synced: the app's User Groups tab decides who is in scope. Members appear under Synced users on the emisar connection, and their JumpCloud groups become mappable to roles below.

When sign-in and the directory disagree#

emisar binds a synced member on the externalId the directory sends, falling back to userName when it sends none — and it binds a sign-in on the sub claim. When those two values differ, emisar cannot tell that the person signing in is the one the directory synced, so it holds their sign-in for an admin instead of guessing.

You do not have to make them match. A sign-in the directory has not claimed lands in Pending access requests on the Team page, with the identifier it presented. Approving it once binds that sign-in to the member the directory already synced — one person, one member, both identifiers on the same record — and every later sign-in and directory push finds them. That is one approval per person, the first time they sign in.

Watch the first one to be sure it is the same person: the request shows the email JumpCloud asserted, and Synced users on the connection shows who the directory sent. If those disagree, do not approve — that is a misconfigured connector, not a mismatched identifier.

Next: map directory groups to emisar roles so access follows your IdP — role mapping.

Last reviewed July 31, 2026

Suggest a change

← Previous

Microsoft Entra

Next →

Keycloak