Skip to main content
Hanko is built around one idea: passkeys should be the default, not the fallback. It’s a focused library with a Go backend, official TypeScript bindings, and an AGPL license. If passkeys are your entire auth surface and you have zero agent workloads, it’s worth a serious look. KavachOS includes passkey support as one method among many. The bigger difference is what happens after the human authenticates: KavachOS was designed for the agent layer that comes next. A migration guide from Hanko is coming soon.

​
Feature matrix

CapabilityKavachOSHanko
LicenseMITAGPL (backend), MIT (JS SDK)
Primary focusAgent-first auth SDKPasskey-first auth
TypeScript SDKYes, first-partyYes, first-party
Named OAuth providers24~3 (Google, Apple, GitHub)
Passkey supportYesYes, core focus
MCP OAuth 2.1 serverBuilt inNot shipped
Agent identityFirst-class AgentIdentity entityNot shipped
RBAC / permissionsUnified RBAC + ABAC + ReBACNot shipped
Ephemeral sessionsBuilt in with auto-expiry and audit groupingNot shipped
Edge runtimeWeb Crypto throughoutGo backend required
Self-hostableYesYes

​
Pick KavachOS if

  • You need more than passkeys: OAuth providers, agent identity, or a policy engine.
  • You’re building AI-powered products where agents need their own auth layer.
  • You want a permissive MIT license for the full stack, not just the client SDK.

​
Pick Hanko if

  • You want the smallest possible passkey-only library with a tight scope.
  • You have no agent story and passkey-first is exactly the feature you need.
  • You’re comfortable with AGPL for your backend auth service.
Hanko does one thing well. KavachOS does more, which is a tradeoff in either direction.
Last modified on April 18, 2026