Kanshin Docs / Single Sign-On

Single Sign-On

Kanshin provides single sign-on (SSO) to your applications using OpenID Connect (OIDC), the widely-adopted identity layer built on OAuth 2.0. This page explains, at a working level, how sign-in happens and what your applications receive — useful background whether you are configuring an application or just want to understand what Kanshin does.

What single sign-on means

With SSO, your people sign in once to Kanshin’s authentication service and can then reach every application they are entitled to, without a separate password for each. The applications never see the password — they trust Kanshin to confirm who the user is.

The sign-in flow

For a person signing in to an application, the standard flow is:

  1. The application sends the user to Kanshin’s authorize endpoint.
  2. Kanshin signs the user in — checking their password, prompting for multi-factor authentication if required, and confirming they are allowed to use that application .
  3. Kanshin returns the user to the application’s registered redirect URI with a short-lived authorization code.
  4. The application exchanges that code at Kanshin’s token endpoint for tokens.

This is the authorization code flow, protected by PKCE. It keeps the password with Kanshin and hands the application only tokens.

Tokens

A successful sign-in produces up to three tokens:

  • An ID token — a signed statement of who the user is, for the application to read.
  • An access token — a signed token the application presents to APIs to act on the user’s behalf. Kanshin can check whether an access token is still valid.
  • A refresh token — an optional long-lived token (granted with the offline_access scope) that the application exchanges for fresh access tokens so the user stays signed in. Refresh tokens are single-use and rotated each time.

Access and ID tokens are digitally signed by Kanshin, so applications can verify they are genuine and unaltered.

Scopes and claims

Scopes are what an application asks for; claims are the pieces of information it receives:

ScopeWhat it grants
openidThe baseline — a stable identifier for the user (sub)
profileThe user’s name
emailThe user’s email address
offline_accessA refresh token, to stay signed in

An application only receives what its granted scopes allow, and only the scopes you registered for it (see Applications ).

The standard endpoints

Because Kanshin follows the OIDC standard, applications and libraries configure themselves automatically from its discovery document, published at the well-known OpenID configuration URL. That document points to the authorize, token, and userinfo endpoints, and to the JWKS endpoint — the public keys applications use to verify Kanshin’s signatures. Any standards-compliant OIDC library can connect to Kanshin using just the discovery URL.

← PreviousApplication Access