Hanko、passkeyをopen-sourceとCloudの選択肢へ変える認証基盤

Felix MagedanzとLennart Fleischmannが関わるHankoは、認証を自前で抱える開発者に別の道を示そうとして始まった。

Hankoは公式サイトで自社を「Modern Authentication. On Your Terms.」と位置づけている 出典。

これは単なるログインUIではなく、open-source、Cloud、self-hostingを選べる認証基盤にするという方針だ。

創業のきっかけ

Hankoは2022年5月、open-source developmentの開始を発表した 出典。

認証をブラックボックスとして購入するのではなく、コードと運用の選択権を持ちたい開発者に向けた出発点だった。

転機・苦労

open-sourceだけでは、認証の可用性やメール送信、運用まで利用者が担う。

そこでHanko Cloudを2023年に展開し、self-hostingとmanaged serviceの間を埋めた 出典。

成長・成功の要因

次の転機はFlow APIとpasskeyへの拡張だ。

Hanko 1.0はloginとregistration flowをAPIとして整理し、現在はFIDO2-certified Passkey APIを前面に出している 出典。

標準の複雑さをSDKとAPIに閉じ込めることが、プロダクトの中心になった。

結び

Hankoの歩みから見えるのは、認証の差別化がログイン画面の見た目ではなく、標準技術を安全な導入体験へ変換する力にあるということだ。

HankoのPMFは、認証を自前実装する開発チームと、passkeyを追加したい既存サービスの交差点にある。

WebAuthn、user management、Cloudとself-hostingを一つの選択肢にまとめ、認証の細部を抱えたくないチームの負担を下げる 出典。

一方で、既存IdPからの移行コストは残る。

WebAuthnとpasskeyの実装知識、SDK、運用ノウハウが複合した技術的障壁。

ただし標準規格に基づくため、機能そのものより移行体験と信頼性が長期 moat になる。

ネットワーク効果は弱い。

利用企業が増えても認証APIの価値が直接増えるわけではない。

一方、open-sourceの利用・issue・contributionが改善速度と信頼形成を助ける間接効果はある 出典。

passkeyを導入したいSaaSの開発チーム、認証基盤をself-hostしたい企業、既存ログインにWebAuthnを追加するプロダクト。

完全なノーコード運用や大規模Enterpriseの購買プロセスだけを重視する組織には要確認。

第一に、passkeyという新しい標準をAPIとSDKで扱える形にした。

第二に、open-sourceとmanaged Cloudを併記し、導入前の検証と本番運用を分けられる 出典。

第三に、startup planで初期利用のコストを抑え、PLGの入口を広げている 出典。

認証は信頼性とセキュリティの要求が高く、導入後の移行・監査・サポートが購買障壁になる。

Hanko自身も、既存の大手IdPや自社実装との比較で選ばれ続ける必要がある。

公開ページだけでは顧客数や売上の検証材料が不足しており、成長規模は要確認。

open-source repositoryで開発者の検証導線を作り、Cloudとstartup planで本番の費用障壁を下げる二段構え。

Passkey API、Authenticator、Flow APIと用途を分け、認証の一機能からuser managementまで広げる 出典。

この戦略は開発者には強いが、Enterpriseの監査要件には営業・サポート投資が必要になる。

主要チャネル: openSource, developerCommunity, content, productLedGrowth

標準技術の普及期は、仕様の説明ではなく、SDK・UI・運用を一つの導入体験に落とすことが重要だ。

Hankoの例は、open-sourceを信頼形成の場にしつつCloudを収益化の導線にする設計を示す。

日本ではpasskey対応が進んでも、既存会員DB・本人確認・サポート運用との接続が導入の本丸になる。

Hanko型のAPIを使う場合も、金融・医療などではデータ保管場所と監査証跡を先に確認すべきだ。