Ory Kratos

Ory Kratos is a headless, open-source identity management server that handles login, registration, account recovery, email verification, and settings flows via a REST API — agents integrate by driving self-service flows and reading identity objects, while the UI is fully custom.

Evaluated Mar 06, 2026 (0d ago) vv1.2.x
Homepage ↗ Repo ↗ Security auth identity self-hosted ory login registration headless oidc
⚙ Agent Friendliness
59
/ 100
Can an agent use this?
🔒 Security
90
/ 100
Is it safe for agents?
⚡ Reliability
77
/ 100
Does it work consistently?

Score Breakdown

⚙ Agent Friendliness

MCP Quality
--
Documentation
84
Error Messages
78
Auth Simplicity
68
Rate Limits
82

🔒 Security

TLS Enforcement
98
Auth Strength
92
Scope Granularity
82
Dep. Hygiene
88
Secret Handling
90

Kratos enforces CSRF protection on browser flows, argon2id for password hashing, and supports MFA via TOTP and WebAuthn. Secrets (OIDC client secrets, cookie secrets) must be managed externally (Vault, Kubernetes secrets).

⚡ Reliability

Uptime/SLA
72
Version Stability
80
Breaking Changes
75
Error Recovery
82
AF Security Reliability

Best When

You need a self-hosted, customizable identity server with full control over the UI and identity schema, without building login/registration/recovery flows from scratch.

Avoid When

You need a managed, no-code identity solution with a built-in hosted UI — use Logto or Auth0 instead; Kratos requires significant integration work for the frontend.

Use Cases

  • Implement a complete login and registration flow for a web app by calling Kratos self-service flow APIs and rendering the returned form fields in a custom UI
  • Retrieve and update user identity objects (traits: email, name, roles) via the admin REST API from an agent managing user lifecycle events
  • Trigger account recovery and email verification flows programmatically via admin API for bulk user onboarding or password-reset automation
  • Integrate social login (Google, GitHub, OIDC) by configuring Kratos OIDC providers and letting Kratos handle the OAuth callback and identity linking
  • Use Kratos session cookies or session tokens to authenticate downstream service requests — verify session validity via the /sessions/whoami endpoint

Not For

  • OAuth2 / OIDC authorization server functionality — Kratos manages identities only; pair it with Ory Hydra for issuing OAuth2 tokens to third parties
  • Fine-grained resource authorization — Kratos handles who the user is, not what they can access; use OpenFGA or Ory Keto for authorization policies
  • Embedded mobile-only authentication without a backend — Kratos requires a server-side component for flow management and cannot operate purely client-side

Interface

REST API
Yes
GraphQL
No
gRPC
No
MCP Server
No
SDK
Yes
Webhooks
Yes

Authentication

Methods: api_key session_cookie session_token
OAuth: No Scopes: No

Admin API endpoints require an API key or mutual TLS in self-hosted deployments. Self-service (public) endpoints use session tokens or cookies. Ory Network uses API keys for cloud deployments.

Pricing

Model: open_source
Free tier: Yes
Requires CC: No

Self-hosted is free and unlimited under Apache 2.0. Ory Network cloud tiers offer managed infrastructure; Developer tier is free with rate limits.

Agent Metadata

Pagination
cursor
Idempotent
Partial
Retry Guidance
Documented

Known Gotchas

  • Self-service flows (login, registration) are stateful and tied to a flow ID with a TTL (default 1h for browser, 15m for API); agents that cache flow IDs across requests will encounter 'flow expired' errors requiring flow re-initialization
  • Browser vs API flow type mismatch: flows initialized with the browser flow type expect a Cookie header; API flow types expect an X-Session-Token header — mixing these causes 400 errors that are hard to diagnose
  • The /sessions/whoami endpoint returns 401 with no body (not JSON) when the session is invalid — agents must check status code before attempting JSON decode to avoid parse errors
  • Identity schema changes (adding/removing traits) require a schema migration and may invalidate existing identity objects if required fields are added without defaults — always version schemas
  • Webhook delivery for post-login/post-registration hooks is at-least-once; agents consuming Kratos webhooks must implement idempotency on the receiving end using the identity ID and event type as a deduplication key

Alternatives

Full Evaluation Report

Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Ory Kratos.

$99

Scores are editorial opinions as of 2026-03-06.

5229
Packages Evaluated
26151
Need Evaluation
173
Need Re-evaluation
Community Powered