Authentication & permissions

Cookie sessions, not bearer tokens

Slicekit authenticates browsers with HTTP-only cookie sessions, which keeps tokens out of JavaScript and out of localStorage. Because cookies are sent automatically, every state-changing request is also protected against CSRF with a token the frontend echoes back.

The frontend never handles a raw credential; the typed API client attaches the cookie and the CSRF header for you. See the API client.

Authorization

Authorization is permission-based. Endpoints declare the permission they require, and a check runs before the handler:

app.MapPost("/api-keys", CreateApiKeyEndpoint.Handle)
   .RequirePermission(Allow.UserApiKeysCreate);

Permissions come from a single catalog (the Allow class). Role presets copy assignable grants onto users or invitations; permission checks read the resulting grants. Admins can explicitly apply a role edit to existing users. API keys carry their own scoped subset, limited to self-service permissions and any staff permissions explicitly marked delegable.

Passkeys and sensitive actions

WebAuthn passkeys provide passwordless sign-in. TOTP two-factor includes enrollment and recovery codes. Sensitive actions ask for fresh proof through step-up verification, using the user’s configured credentials. Sessions are listed and revocable per device.

Connected AI apps

The MCP server uses OAuth bearer tokens with a separate audience from browser sessions. Users approve scoped access and can edit or revoke it under Settings, MCP & Apps. Each tool request checks their current permissions and the connection’s grant.

Admin impersonation

Support staff sometimes need to see exactly what a user sees. Slicekit includes short-lived, audited impersonation: an admin with the right permission can start a session as another user. The session is time-boxed, clearly flagged, and every impersonated action is recorded in the audit trail.

Audit trail

Security-relevant actions (sign-in, permission changes, impersonation, sensitive mutations) emit audit events. These flow through the same Serilog → OTLP → Loki pipeline as the rest of the logs, so there is no audit table to maintain and retention lives in Loki rather than the database.

Behind a reverse proxy

In production the API runs behind a reverse proxy, so it is configured to trust forwarded headers for the scheme and client address. That keeps redirects, cookie Secure flags and audited IP addresses correct when TLS terminates at the proxy.

What you configure

• Roles and their permissions. Seed the set your product needs.
• Session lifetime and cookie options. Sensible secure defaults are provided.
• Which actions are audited. Emit an audit event from any handler that warrants one.