Applications
An application in Kanshin is a piece of software your people sign in to through Kanshin — a web app, a mobile app, a service, or a command-line tool. Registering an application tells Kanshin’s authentication service that the app is trusted and how it will connect. In identity terms an application is an OpenID Connect / OAuth 2.0 client. You manage applications on the Clients page under Applications.
Registering an application
When you register an application you configure how it connects:
| Setting | What it is |
|---|---|
| Name | A label for the application |
| Redirect URIs | The exact web addresses Kanshin is allowed to return the user to after they sign in. At least one is required, and the match is exact — a redirect to any other address is refused |
| Grant types | Which sign-in flows the application uses (see below) |
| Scopes | What the application may ask for — openid, profile, email, and offline_access. New applications default to openid, profile, email |
| PKCE required | Whether the application must use PKCE, an extra proof step that protects the sign-in. On by default, and strongly recommended |
| Authentication method | How the application proves its own identity when exchanging codes for tokens — a client secret, or none for public apps that cannot keep a secret |
The client secret
Confidential applications (those that can keep a secret, like a server-side web app) authenticate with a client secret. When you register such an application, Kanshin shows you the secret once — copy it into your application’s configuration then, because it is stored only as a secure hash and cannot be shown again.
If a secret is lost or may have been exposed, use Rotate secret to generate a new one (shown once) and retire the old.
Grant types (sign-in flows)
Kanshin supports the standard flows, and you choose which an application uses:
- Authorization code (with PKCE) — the flow for apps a person signs in to. The default and the right choice for almost every user-facing application.
- Refresh token — lets an application stay signed in by exchanging a refresh token for fresh access, without the user signing in again. Requires the
offline_accessscope. - Client credentials — for machine-to-machine access with no user involved. See Machine-to-Machine Access .
Public and confidential applications
- A confidential application can safely keep a client secret (a backend service). It uses a secret to authenticate.
- A public application cannot keep a secret (a single-page web app or a mobile app). It sets its authentication method to none and relies on PKCE for protection.
Controlling who may use an application
Registering an application does not by itself decide who is allowed to sign in to it. That is controlled separately — see Application Access .
Related pages
- Application Access — deciding who may sign in to each app
- Single Sign-On — how the sign-in flow actually works
- Machine-to-Machine Access — applications that sign in as themselves