Skip to main content
Docs navigation

Keycloak

Connect Keycloak to emisar: a confidential OIDC client with PKCE for sign-in. Keycloak has no outbound SCIM, and the directory-sync section says what that leaves you to do.

Before you start, you need:
  • Keycloak realm-admin access.
  • An emisar owner or admin.

The screenshots are from Keycloak 26.7; earlier versions arrange the same settings differently.

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 Keycloak. Leave the page open: the callback URL on it is what Keycloak asks for next, and Keycloak'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 Keycloak

    Start an OpenID Connect client.

    In the Keycloak Admin Console, choose your realm, then go to Clients → Create client. Leave Client type on OpenID Connect, set Client ID to emisar-portal, and click Next.

    Keycloak Admin Console · General settings
    Create an OpenID Connect client for the emisar web application.
  3. 3

    In Keycloak

    Enable only the flow emisar uses.

    Turn Client authentication and Require PKCE on. Keep Standard flow on and leave the PKCE method on S256. Leave Authorization, DPoP, Direct access grants, Implicit flow, Service accounts roles, and every device flow off. Then click Next.

    Keycloak Admin Console · Capability config
    A confidential client using the authorization-code flow with PKCE.
  4. 4

    In Keycloak

    Register the exact redirect URI.

    Copy the callback shown in emisar and paste it into Valid redirect URIs. It ends in /sign_in/sso/callback. Do not add a wildcard. The other URL fields can stay empty; click Save.

    Keycloak Admin Console · Login settings
    The screenshot uses a reserved example host; paste the callback from your emisar form verbatim.
  5. 5

    In Keycloak

    Copy the client secret.

    Open the saved client's Credentials tab. Copy its client secret into emisar's Client secret field. Treat the value like a password; do not put it in tickets, chat, or screenshots.

    Keycloak Admin Console · Credentials
    The client secret stays masked in this guide.
  6. 6

    In Keycloak

    Verify the identity scopes.

    On the Client scopes tab, confirm that email and profile are assigned as Default. emisar requests openid in the authorization request, so it does not appear as an assigned client-scope row.

    Keycloak Admin Console · Client scopes
    The default email and profile scopes give emisar the verified identity claims it needs.
  7. 7

    In emisar

    Connect and test the first sign-in.

    Back on the connection you opened in step 1, paste the client ID and secret, and build the issuer from your Keycloak host and realm:

    Issuer URL
    https://YOUR-KEYCLOAK-HOST/realms/YOUR-REALM

    Press Test connection — it fetches the realm's discovery document, so a wrong host or realm fails here rather than at someone's first sign-in. Then tick Enabled and save. In a private window, sign in as a Keycloak user who is not in emisar yet: with auto-provisioning they land at the default role, and with manual provisioning an admin gets a pending request instead.

    Your Keycloak has to be reachable from emisar

    Self-hosted means this is worth checking before you start. emisar fetches the realm's discovery document, its JWKS and the token endpoint from its own network, so the realm URL must resolve to a PUBLIC address and present a certificate from a public CA — a private or internal address is refused outright, because from where we stand it is indistinguishable from our own infrastructure. A Keycloak behind a VPN or on an internal-only hostname needs to be published, or reached through a gateway that is.

    emisar · Add provider
    Three values from Keycloak. The issuer is the realm URL, not the host on its own.
The rest of the connection form

This guide covers only what Keycloak 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#

Keycloak cannot drive directory sync. Its built-in SCIM support runs the other way — the SCIM Realm API added in 26.6 lets something else provision users into Keycloak — and an outbound client that pushes users to an application like emisar is on the roadmap, not in a release. So Keycloak gives you single sign-on (above) with members created on first sign-in when the connection auto-provisions (with manual provisioning an admin approves each first sign-in instead), and nothing else: no role mapping, and nobody removed from emisar when they leave Keycloak. Offboarding is therefore two steps, and the second is the one that ends access: disabling the Keycloak user stops them starting a NEW sign-in, but it does not touch the session they already hold or any API key they minted. Suspend or remove them in Team — that is what ends live sessions and revokes their keys.

The connection still offers directory sync, because emisar's endpoint is ordinary SCIM 2.0 with a bearer token and a third-party Keycloak provisioning plugin can drive it. If you run one, enable sync here and point it at the base URL and token above — directory sync is an Enterprise feature, a tier above the one single sign-on needs. Only available on Enterprise. That plugin is yours to choose, configure, and support — we don't ship or certify one.

Last reviewed July 31, 2026

Suggest a change