Skip to main content
Authentication establishes who is making a request; permissions then decide what they may do. Korint gives each tenant its own separate user directory, and every account belongs to exactly one tenant.

​
Signing in

Users sign in with an email and password, or through single sign-on. Social sign-on is available with Google and Apple, and enterprise identity providers can be connected over SAML 2.0 or OpenID Connect (OIDC). The sign-in methods offered depend on the tenant’s configuration. Because each tenant has its own directory, accounts are isolated per tenant and a user’s session is only valid within their own tenant.

​
Anonymous sessions

Some tenants offer public, self-service quoting funnels that a visitor can start without an account. Where a tenant enables this, Korint issues a temporary anonymous session that can quote and capture details; when the visitor later signs in or creates an account, their work is handed off to the new account. Anonymous access is opt-in per tenant—it exists only where the tenant defines an anonymous role.

​
How a request is checked

Every authenticated request passes two checks, in order:
  1. Scope check — a coarse gate confirming the caller is allowed to reach this area of the platform at all.
  2. Permission check — the fine-grained, role-based check described in Permissions, evaluated against the specific record being acted on.
Both must pass for the request to proceed.

​
Tenant isolation

Every request carries its tenant, and the caller’s session is verified against that tenant’s own user directory. Permissions and data access are then scoped to that tenant, so one tenant’s users can never see or act on another tenant’s data. A request that arrives without a tenant is rejected.