Hanko

Passkeysだけに限定せず、現代的な認証方式を一つの基盤へまとめる

公式READMEでは、passwords、MFA、passkeys、social logins、SAML SSOに対応し、passkey-onlyやOAuth-onlyなどの構成も選べると説明されています。認証方式ごとに別サービスを組み合わせるのではなく、ユーザー・セッション管理やJWT発行まで含むAPI-firstの基盤として扱えるのが特徴です。

出典：[1]

Web ComponentsとSDKで、認証UIを既存フロントエンドへ組み込みやすい

Hanko Elementsはログイン・オンボーディング・ユーザープロフィール用のWeb Componentsを提供し、Hanko Frontend SDKはHanko APIとの通信を扱います。Elementsのnpm packageはMIT Licenseで公開され、READMEにはframework-agnosticな統合を狙う構成が示されています。

出典：[1][4]

Docker ComposeのQuickstartで、フロント・バックエンドをまとめてローカル確認できる

公式Quickstartではリポジトリをcloneし、deploy/docker-compose/quickstart.yamlを使ってDocker Composeで起動する手順が案内されています。起動後はlocalhost:8888でログイン画面を確認でき、メール確認用のMailSlurperもlocalhost:8080で立ち上がります。

出典：[2]

Auth0やClerkなどの代替を検討しつつ、認証データと運用の主導権を持ちたいチームに

Passkeysを導入したい場合だけでなく、パスワードから段階的に移行したいサービス、MFA・OAuth・SAMLまで同じ認証基盤で扱いたいB2B/B2Cアプリ、認証APIをセルフホストしてデータ配置や運用を自分で決めたいチームに向きます。既存UIへ最短で組み込む場合はHanko Elements、独自UIを作る場合はFrontend SDKとAPIを比較すると整理しやすいです。

リポジトリ全体は単一ライセンスではなく、backendとfrontendで条件が異なる

ルートLICENSEでは、frontend/elementsとfrontend/frontend-sdkを除くコードはAGPLv3、これら2ディレクトリはそれぞれのMIT Licenseに従うと定義されています。さらにREADMEはNon-Copyleft commercial licensingも案内しています。セルフホストや改変版をサービス提供する場合は、利用するコンポーネントごとのライセンス境界を確認してください。

Quickstartは評価には便利ですが、Docker起動時に複数サービスを構築します。本番導入ではQuickstart設定をそのまま採用せず、backend設定、メール送信、OAuth/SAML接続、セッション運用などを自環境の要件に合わせて設計する必要があります。

出典：[3][1][2]