Kanshin Docs / Sessions, Audit & Security

Sessions, Audit & Security

This page covers what happens after sign-in — sessions and their lifetimes — the audit log, and the security foundations Kanshin rests on.

Sessions

When a person signs in, Kanshin creates a session that keeps them signed in without re-entering their password on every request. A session has a lifetime and, if your session policy sets one, an idle timeout, after which the person signs in again.

Logging out ends the session immediately, so it can no longer be used. Sign-in sessions and the tokens issued from them each have their own lifetime; you set these lifetimes in your session policy .

The audit log

Kanshin can record an audit log of significant events — who did what, and when — which you view on the Logs / Auditing page under Settings. The audit log lets you review administrative activity and investigate anything unexpected.

The audit log is available when your deployment is configured with the logging backend that stores it. If you do not see it, ask whoever operates your Kanshin instance whether audit logging is enabled.

How Kanshin keeps your organization safe

Kanshin is built to enterprise security expectations. The foundations you can rely on:

  • Organization isolation. Every request is scoped to the organization of the signed-in user, and the boundary is enforced by the system. One organization can never see or touch another’s data — this is structural, not a matter of careful configuration.
  • Secrets are never stored in the clear. Application client secrets and provisioning tokens are stored only as secure hashes and shown once; multi-factor secrets and backup codes are stored encrypted; user passwords are held by the authentication service in encrypted storage, never in the directory.
  • Strong sign-in. Sign-in uses the authorization-code flow with PKCE, and access and ID tokens are digitally signed so applications can verify them.
  • Brute-force defense. Repeated failed sign-ins lock an account temporarily, then for longer; protections also apply per source address to blunt automated attacks across many accounts. The same applies to machine applications.
  • Multi-factor authentication. Authenticator-app codes with single-use backup codes add a second factor — see Multi-Factor Authentication .
  • Access is denied by default. No one can use an application until they are assigned to it, and management actions are gated by roles .

Together these mean the safe thing is the default: access is granted deliberately, secrets never leave in a readable form, and every organization stands entirely on its own.

← PreviousMachine-to-Machine Access