Sign in with Kubit and OIDC clients

“Sign in with Kubit” lets organization members use their Kubit identity to access your application. Kubit verifies the user and returns a trusted identity result, so your service does not need to store their passwords.

This is not a way to sign in to Kubit itself. LDAP and SAML bring users into Kubit; an OIDC client takes Kubit users into a customer service.

OpenID Connect (OIDC) is a standard identity layer built on OAuth 2.0. OAuth 2.0 primarily grants access; OIDC also carries authenticated identity information.

After successful sign-in, your service receives an ID Token, normally a signed JWT. Validate its signature, issuer, audience, and expiration.

The flow has three parties:

• User: An organization member signing in to the service.
• Client: The customer application requesting sign-in.
• Kubit: The identity provider that authenticates the user and issues tokens.

In the common Authorization Code flow, your service redirects the browser to Kubit. Kubit authenticates the user and checks organization membership and any configured group restriction.

If consent is required, Kubit asks the user before continuing. It then returns the browser to a registered redirect URI with a short-lived, single-use code.

Your backend exchanges the code for tokens and creates its own application session after validating the ID Token. Use the client secret only from a protected backend; never send it to a browser or public client.

Determine the exact callback URI expected by your application's OIDC library. If only certain members may sign in, create the required groups and manage their membership first; see Add or remove group members.

You also need the relevant OIDC permissions. If the OIDC settings item is missing, you may not have permission to view clients.

Activate the organization, open Settings and OIDC, then select New Client.

Use a name that clearly identifies the service and environment, such as “Reporting” or “Reporting Staging.” Kubit uses it in the panel and on consent screens.

Enter each allowed URI separately. A sign-in request must use an exact registered value. Use HTTPS in production, keep development and production callbacks separate, and remove obsolete values.

When Manage Access with Groups is off, the client does not impose a group restriction. When enabled, only members of selected groups may sign in. Add at least one group; an empty allow-list permits no group.

Group membership changes immediately affect sign-in eligibility. Before deleting a group, check whether an OIDC client depends on it.

Enable Require User Consent to show the client name and request approval before access is granted. Enable Reuse Consent to remember that decision for later sign-ins to the same client. Reuse applies only when consent itself is enabled.

After creation, the details page provides:

• Configuration URL: The OIDC discovery document for endpoints and public keys.
• Client ID: The identifier sent by your service.
• Client secret: A secret shared by Kubit and your backend.
• Redirect URIs: The callbacks to which Kubit may return the browser.

Configure your library with the configuration URL. Most libraries discover the remaining endpoints and keys automatically.

Receiving a token is not enough. Use a trusted OIDC library to verify the ID Token signature, issuer, client audience, and expiration. Validate state; keep nonce and PKCE enabled when the library supports them.

Link the stable standard user identifier to an internal account. Do not use display name or email as the only permanent key because they may change.

Test in a non-production environment first. Sign in with an allowed-group member and verify redirect handling, token validation, and session creation. Then test a user outside the allowed groups; access should stop before the service is opened.

Ensure application logs never record tokens or the client secret.

Compare scheme, host, port, path, and trailing slash with the registered value. Configure the identical URI in Kubit and the application.

When group access is enabled, verify membership in an allowed group. The organization membership must also be active and the correct organization selected.

Check the client ID, secret, redirect URI, and token endpoint. Authorization codes are short-lived and single-use; delayed or repeated exchange is rejected.

Check the discovery URL, issuer, audience, system clock, and public keys. Prefer a maintained OIDC library over manual token validation.

The details page lets you change the name, allowed groups, consent, and redirect URIs. Changes can interrupt sign-in, so keep production and test clients separate.

Deleting a client stops new sign-ins. Confirm that no service uses its ID. If the client secret is exposed, stop using it and replace the connection credentials.