Skip to content

JumpCloud: before the install

This page is for the administrator of a JumpCloud organisation that will run Winner AI. It makes one application in the JumpCloud Admin Portal, the one the installation's sign-in gate uses, and ends with a table of the values to give back to whoever runs the installation. Nothing on it needs the installation to exist yet.

<base URL> below is the address people will browse to, for example https://winner.example.com. Whoever runs the installation decides it; ask them for it before you start. It is always https.

Each step ends with a line in italics saying what it was checked against: the first run on a live organisation, on 2026-11-03, JumpCloud's own documentation on the date given, or both. A Not checked line names what that run did not try.

Followed once on a live organisation

An installation that signs in through JumpCloud leaves the Auth0 Management credentials blank, and the Managers group decides who is a Manager. This page was followed on a live JumpCloud organisation, in the United States region, on 2026-11-03; Connect your identity provider says what that run showed.

Confirm first

  • Your plan includes single sign-on with a custom OpenID Connect application. The sign-in gate is an OpenID Connect client; without one there is nothing to register. JumpCloud's pricing page does not say which plan includes it, so ask JumpCloud if Access, SSO Applications offers no custom OIDC application.

    Checked: the first run, 2026-11-03. JumpCloud's pricing page, read 2026-10-07, ties custom OIDC applications to no plan.

  • No access policy refuses the browser that approves a laptop. A developer approves their laptop in a browser. A policy on the application that requires a managed device or a network refuses a browser it does not recognise; JumpCloud's Device Trust certificates on Linux work only in Google Chrome. If a policy applies, say which, so developers know which browser to use.

    Not checked: the first run, 2026-11-03, did not try an access policy. JumpCloud's conditional access documentation, read 2026-10-07.

  • The installation's server can reach JumpCloud over https. The gate fetches JumpCloud's discovery document, tokens and keys from the server, not from a browser, so a server that cannot reach the issuer (step 10) over https cannot sign anyone in. Ask whoever runs the installation.

    Checked: the first run, 2026-11-03. Not from JumpCloud's documentation: it depends on the installation's network.

Before you start

Have <base URL>. Then, in Identity Management, User Groups, create two groups: one for the people who are Managers, for example winner-managers, and one for everyone else who may sign in, for example winner-members. The names are yours; write the Managers group's name down exactly as you typed it, and give it no comma: Winner AI splits the group attribute on commas, so a Managers group with a comma in its name never matches. In Identity Management, Users, put each person in the group they belong in; a Manager need not also be in the Members group.

Never use a broad group such as All Users as the Managers group: it is in everyone's claim, so everyone would be a Manager. Binding a broad group as the Members group admits everyone in it, which is a choice, not an error.

Checked: the first run, 2026-11-03, with a Managers and a Members group bound to the application. JumpCloud's single sign-on documentation, read 2026-10-07.

In the JumpCloud Admin Portal

  1. Create the application. Access, SSO Applications, Add New Application, then Custom Application, Manage Single Sign-On, Configure SSO with OIDC (typing OIDC in the search box reaches the same place). Give it a Display Label such as Winner AI, then Configure Application and open the SSO tab. Make it in the console: JumpCloud's admin API stored no OpenID Connect settings when tried, and documents no way to. Only this one application is needed; the laptops need none of their own.

    Checked: the first run, 2026-11-03. Console path from JumpCloud's single sign-on with OIDC page, read 2026-10-07; the admin API tried by 2026-10-22.

  2. Set the redirect address. Redirect URIs: +Add URI, then <base URL>/oauth2/callback. Login URL: <base URL>. The gate builds its callback from the base URL, so the redirect URI must match it exactly, scheme and port included. Winner AI compares only the redirect URI; nothing checks the Login URL.

    Checked: the first run, 2026-11-03, with an https address.

  3. Choose the client authentication type. Client Authentication Type: Client Secret Basic. The console selects Client Secret POST by default, so change it; Basic is the one the gate was run with. Not Public (None PKCE): it issues no secret, and the gate needs one. The installation has no setting for the type.

    Checked: the first run, 2026-11-03, with Client Secret Basic. JumpCloud's discovery document, fetched 2026-10-22, lists both.

  4. Leave the subject claim at its default. Subject Claim: JumpCloud User ID. Winner AI keeps each person on this id, so remapping it to an attribute that can change, such as the e-mail or the username, breaks that person's record when the attribute changes.

    Checked: the first run, 2026-11-03. JumpCloud's OIDC page, read 2026-10-07.

  5. Grant types and scopes. Grant Types: Authorization Code is ticked and cannot be unticked; leave Refresh Token unticked, because the gate, as this release configures it, never refreshes a sign-in. Attribute Mapping: tick the Email and Profile standard scopes. Do not add a groups scope: JumpCloud lists none, and whether it ignores one or fails the sign-in is not yet known. Hand over: the scopes are openid profile email.

    Checked: the first run, 2026-11-03. Grant types from JumpCloud's OIDC page, read 2026-10-07; scopes from its discovery document, fetched 2026-10-22.

  6. Send the e-mail. The Email scope sends the person's email and email_verified. The console adds email_verified as a constant attribute with the value true, greyed out, so every user arrives verified whatever happened to their address. Leave it: it cannot be removed. A Manager is therefore named by the Managers group, never by a list of e-mail addresses.

    Checked: the first run, 2026-11-03. The two claims from JumpCloud's OIDC claims page, read 2026-10-22.

  7. Include the group attribute. Still in Attribute Mapping, tick include group attribute and name it, for example groups. JumpCloud refuses to activate the application while the name is blank. Whether JumpCloud sends the attribute as a list in the ID token, and how many groups it carries, is not yet known. Hand over: the name, exactly as typed.

    Checked: the first run, 2026-11-03: the named attribute arrived, and a bound Managers group made its member a Manager. How many groups it carries was not measured. JumpCloud's OIDC page and claims page, read 2026-10-07.

  8. Bind the Managers and Members groups. On the application's User Groups tab, tick both groups from Before you start. JumpCloud admits only people in a bound group, and puts only bound groups in the group attribute, so a Managers group that is not bound never reaches Winner AI and its people sign in as Members, or not at all. Hand over: the Managers group's name, exactly.

    Checked: the first run, 2026-11-03: the tab is labelled User Groups. JumpCloud's claims page, read 2026-10-07, and its page on authorising users, read 2026-11-04, which says to select the User Groups tab.

  9. Activate, and copy the client id and secret. Click Activate. The console then shows the Client ID and the Client Secret once: copy both before you click Got It. A lost secret is regenerated, not shown again. Hand over: both, the secret as What to hand back says.

    Checked: the first run, 2026-11-03. JumpCloud's OIDC page, read 2026-10-07.

  10. Find the issuer for your region. JumpCloud has one issuer per region, and the wrong one fails the sign-in with "The requested OAuth 2.0 Client does not exist". The issuer keeps its trailing slash.

    Region Issuer End-session address
    United States https://oauth.id.jumpcloud.com/ https://console.jumpcloud.com/userconsole/logout
    European Union https://oauth.id.eu.jumpcloud.com/ not known; see below
    India https://oauth.id.in.jumpcloud.com/ not known; see below

    The end-session address is the User Portal's logout, not the end_session_endpoint in the issuer's discovery document. The session that signs a person straight back in is the User Portal's, and only its logout ends it; in the United States run, the discovery document's address refused Winner AI's sign-out. Hand over: the issuer and the end-session address.

    In the European Union and India regions, contact Winner AI support before the install. Their User Portal logout addresses have never been tried, and nobody has checked that one signs a person out. The installation cannot start without an end-session address: its settings check refuses an https installation with none, and one whose host the gate may not send a browser to. Do not use the discovery document's address in its place.

    Checked: the first run, 2026-11-03, in the United States region. The United States discovery document fetched 2026-10-22, the European Union one 2026-10-07 and the India one 2026-11-04. No sign-in or sign-out was tried in the European Union or India region.

What to hand back

Give these to whoever runs your installation. They go in its settings; the identity provider guide shows where.

What you hand back From Setting it fills
The issuer, with its trailing slash step 10 OAUTH2_PROXY_OIDC_ISSUER_URL
The end-session address; in the European Union and India regions, ask Winner AI support first step 10 OIDC_END_SESSION_URL
The end-session address's host, for example console.jumpcloud.com step 10 OAUTH2_PROXY_WHITELIST_DOMAINS
The Client ID step 9 AUTH0_PROXY_CLIENT_ID
The Client Secret step 9 AUTH0_PROXY_CLIENT_SECRET
The scopes, openid profile email step 5 OAUTH2_PROXY_SCOPE
The group attribute's name step 7 OAUTH2_PROXY_OIDC_GROUPS_CLAIM
The Managers group's name, exactly step 8 FLEETVIEW_MANAGER_GROUP

The two client settings keep their Auth0 names but hold the client of whichever provider the issuer names. Send the answers to Confirm first with the table. Nothing else fills a setting: the Members group admits its people by being bound, the client authentication type and the subject claim are settled in JumpCloud alone, and step 6's email_verified is a constant, so there is nothing to hand back for it.

Send the Client Secret only to whoever runs your installation, through your password manager or the channel your organisation uses for secrets, never in a plain e-mail. Never send it to the makers of Winner AI: only your installation needs it.