複数ブランドを支える認証認可基盤における、パスキー認証実装の課題と解決策/Challenges and Solutions for Passkey Authentication Implementation in AuthN and AuthZ Infrastructure Supporting Multiple Brands

2 Copyright © 2025 Bitkey Inc. All right reserved. 自己紹介
2020.08 2022.12 2023.10 SELF株式会社に入社 AIチャットサービスの開発に従事。情報システム部門としてPマーク取得も担当。プラットフォーム開発部へ異動認証認可基盤bitkey platformの開発に携わっている。ビットキーに入社 workhub開発部でオフィス管理者向けSaaS プロダクトの開発に従事。 now • バックエンドの開発 (Goを使用) • CI/CDの改善 • インフラの保守・運用 • 社内LT会の運営上窪大暉 Uekubo Daiki

3 Copyright © 2025 Bitkey Inc. All right reserved. 認証認可基盤にパスキー認証機能を実装
はじめに

4 Copyright © 2025 Bitkey Inc. All right reserved. 技術検証のための試験的なリリース、かつニーズの再検討中
2025年2月現時点では本番運用はしていないはじめに

5 Copyright © 2025 Bitkey Inc. All right reserved. 「複数のブランドを支える認証認可基盤」ならではの課題と解決策について紹介
はじめに

6 Copyright © 2025 Bitkey Inc. All right reserved. 目次
1. ビットキーのサービス 2. 実装上の課題・解決策 ~RP IDの管理~ 3. 別解 ~Related Origin Requests~ 4. まとめ

8 Copyright © 2025 Bitkey Inc. All right reserved. •
パスキー認証実装中に遭遇した課題はサービス展開の仕方に起因 • 課題の背景について認識を合わせることが目的 1.ビットキーのサービスなぜサービス紹介が必要なのか

9 Copyright © 2025 Bitkey Inc. All right reserved. 1.ビットキーのサービス
homehub, workhub

homehub, workhubはブランドが分かれている • それぞれ異なるドメイン名を使用してデプロイされている • それぞれ独自にログインページを実装している ◦ “サービス共通のログインページ”があるわけではない 1.ビットキーのサービス homehub, workhub homehubのログインページ workhubのログインページ

bitkey platform

homehub, workhubへ、認証機能をAPIとして提供 • “bitkeyアカウント”としてユーザー情報を一元管理 ◦ ユーザーは、homehub, workhubへ同じID・パスワードでログインできる(*) *...ただし、2025年2月現在、これが必要なユースケースは存在しない 1.ビットキーのサービス bitkey platform

homehub, workhubはID・パスワードでの認証がメイン ◦ パスワードはフィッシングなどの被害を受けやすい • パスキーはUXを損ねずにパスワード以上の安全性を実現 • bitkey platformがパスキー認証を実装して、homehub, workhubへ機能提供 ◦ → お客様の安全で快適なサービス利用に貢献 1.ビットキーのサービスパスキー認証の実装の動機

ビットキーはhomehub, workhubという2つのサービスを展開 ◦ それぞれ異なるドメイン名を使用してデプロイされている ◦ それぞれ独自にログインページを実装している • 認証認可基盤bitkey platformがhomehub, workhubの認証を支えている ◦ bitkey platformにパスキー認証機能を追加 1.ビットキーのサービスこの章のまとめ

16 Copyright © 2025 Bitkey Inc. All right reserved. 実装上の課題・解決策
~RP IDの管理~

bitkey platformはGoで実装されている • 以下の観点でパスキー認証のためのライブラリを選定 ◦ Goのプログラムから使いやすいインターフェースであること ◦ メンテナンスが頻繁であること ◦ ドキュメントが充実していること ◦ 実装参考例が多いこと (hankoも使用している) ◦ 無料で使用できること → go-webauthn/webauthnに決定！　 ※実装当時の最新バージョンはv0.9.4 2. 実装上の課題・解決策 ~RP IDの管理~ 使用したライブラリ

go-webauthn/webauthnの仕様 ◦ webauthnインスタンスを初期化し、このインスタンスに実装されているパスキー登録/認証のメソッドを呼び出す ◦ webauthnインスタンスを初期化するとき、パスキー認証のRelying Partyとなるアプリケーションのドメインを引数`RPID`として指定しなければならない 2. 実装上の課題・解決策 ~RP IDの管理~ 使用したライブラリ

go-webauthn/webauthnのExampleを参考に以下のように実装 1. main関数でwebauthnインスタンスを初期化してグローバル変数に格納 ◦ RP IDはbitkey platformのドメインを設定 (example.comとします) 2. パスキー登録/認証のAPIハンドラ内で参照 2. 実装上の課題・解決策 ~RP IDの管理~ 初期実装

20 Copyright © 2025 Bitkey Inc. All right reserved. 2.
実装上の課題・解決策 ~RP IDの管理~ 初期実装

ブラウザからでないと動作検証が難しそう ◦ ログインフォームと「パスキーを登録」ボタンを配置した検証用サイトを実装(*) ◦ Firebase Hostingでデプロイ • 検証用サイトからbitkey platformにリクエストを送信し、以下の動作検証を行う ◦ パスキーを登録する ◦ パスキーでログインする *...WebAuthn APIの呼び出しなどの実装は下記リポジトリを参考にした https://github.com/subkaitaku/webauthn-example/blob/main/templates/index.js 2. 実装上の課題・解決策 ~RP IDの管理~ 動作検証

実装上の課題・解決策 ~RP IDの管理~ 問題 • 検証用サイトでWebAuthn API (navigator.credentials.create()) を呼び出したときにエラーが発生「Relying Party IDは、現在のドメインの登録可能なドメイン接尾辞でもなければ、同じでもない。」

WebAuthnの仕様書に記載があった ◦ https://www.w3.org/TR/webauthn-2/#rp-id ◦ https://www.w3.org/TR/webauthn-2/#CreateCred-DetermineRpId ◦ https://www.w3.org/TR/webauthn-2/#GetAssn-DetermineRpId • RP IDは ◦ パスキーが使えるスコープを決定する ◦ ログインページを実装するwebサイトのオリジンと同じ、または、オリジンの登録可能なドメイン部分(*)と一致しなければならない *...public suﬃx(例えば、”.com”や”.co.jp”) + その直前のドメイン名で構成された文字列のこと (参考: https://developer.mozilla.org/ja/docs/Glossary/Site ) 2. 実装上の課題・解決策 ~RP IDの管理~ 問題

RP IDの設定例 ◦ ログインページのあるwebサイトのオリジン ▪ https://login.example.com ◦ RP ID ▪ login.example.com ▪ example.com 2. 実装上の課題・解決策 ~RP IDの管理~ 問題

今回のケースに当てはめると... ◦ 検証用サイトのオリジン ▪ https://test-example.firebaseapp.com (*) ◦ bitkey platformで設定したRP ID ▪ example.com → example.com は test-example.firebaseapp.com の登録可能なドメイン接尾辞でも同じでもないのでエラーが発生 *...Firebase Hostingのデフォルトドメインは `<PROJECT_ID>.firebaseapp.com` 2. 実装上の課題・解決策 ~RP IDの管理~ 問題

RP IDの設定について考え直して、気づく ◦ homehub, workhubは、それぞれ独自にログインページを実装している ▪ 「bitkey platformのドメインをRP IDにしていいのか…？」 ◦ homehub, workhubは、それぞれ異なるドメイン名を使用してデプロイされている ▪ 「どちらかのドメインをRP IDにしていいのか…？」 2. 実装上の課題・解決策 ~RP IDの管理~ 問題

実装上の課題・解決策 ~RP IDの管理~ • 状況を整理 ◦ RP IDは1つしか設定できない ◦ bitkey platformのドメインをRP IDにすると、homehub, workhubでパスキー認証が使えない ◦ homehubのドメインをRP IDにすると、workhubでパスキー認証が使えない ◦ workhubのドメインをRP IDにすると、homehubでパスキー認証が使えない問題

状況を整理 ◦ RP IDは1つしか設定できない ◦ bitkey platformのドメインをRP IDにすると、homehub, workhubでパスキー認証が使えない ◦ homehubのドメインをRP IDにすると、workhubでパスキー認証が使えない ◦ workhubのドメインをRP IDにすると、homehubでパスキー認証が使えない → go-webauthn/webauthnのExample通りのアプローチだと、 2つのサービスへ同時にパスキー認証機能を提供することができない！ 2. 実装上の課題・解決策 ~RP IDの管理~ 問題

実装上の課題・解決策 ~RP IDの管理~ • 選択肢は2つ A. RP IDの設定をサービスに応じて動的に変更し、homehub, workhubそれぞれでパスキーの設定を行ってもらう ◦ homehubからのリクエスト: homehubのドメインをRP IDにする ◦ workhubからのリクエスト: workhubのドメインをRP IDにする B. homehub, workhub共通のログイン用webサイトを構築し、新しいドメインでホストする。homehub, workhubはこのサイトを経由してパスキー認証を行うようにする対応方針

実装上の課題・解決策 ~RP IDの管理~ 対応方針メリットデメリット A案サービスに応じて動的に RP IDを設定する homehub, workhubの実装者が各々パスキー認証への導線を設計できるので、サービスに合った形でパスキー認証を導入できるお客様はhomehub, workhubそれぞれでパスキーの設定を行う必要がある B案サービス共通のログイン用サイトを作る • homehub, workhubでパスキーを共有でき、「homehubで登録したパスキーでworkhubにもログインできる」というシームレスな体験が実現できる • お客様からするとパスキーの設定が1回で済むサービスのログイン導線を実装し直すことになるので、bitkey platform, homehub, workhubそれぞれの開発者にとって実装コストが高い

私たちはA案を選択 ◦ 「RP IDの設定をサービスに応じて動的に変更し、homehub, workhubそれぞれでパスキーの設定を行ってもらう」 • 理由 1. お客様からするとhomehub, workhubはそもそも別のサービスなので、別々にパスキーの設定をすることになったとしてもUXを損なうことにはならない 2. むしろ、”homehubアカウント”で作ったパスキーが”workhubアカウント”でのログインに使えたりすると、お客様が戸惑う可能性がある 2. 実装上の課題・解決策 ~RP IDの管理~ 対応方針

「RP IDの設定をサービスに応じて動的に変更」するために、以下のように修正 > main関数でwebauthnインスタンスを初期化してグローバル変数に格納 • パスキー登録/認証のリクエストの度にwebauthnインスタンスの初期化 • RP IDはリクエストヘッダのオリジンから登録可能なドメイン接尾辞を抽出して設定 • (例) ◦ https://admin.example.net からのパスキー登録リクエスト → RP ID:"example.net"としてwebauthnインスタンスを初期化 ◦ https://login.example.org からのパスキー登録リクエスト → RP ID:"example.org"としてwebauthnインスタンスを初期化 2. 実装上の課題・解決策 ~RP IDの管理~ 修正

実装上の課題・解決策 ~RP IDの管理~ 修正 • RP IDとなりうるドメインのホワイトリストを環境変数で用意し、ホワイトリストにないドメインからのリクエストはエラーにする ◦ 知らないサービスのドメインがRP IDになってしまうことを防ぐ

実装上の課題・解決策 ~RP IDの管理~ 修正

実装上の課題・解決策 ~RP IDの管理~ 修正 • やったこと ◦ パスキー登録/認証のリクエストの度に、リクエスト元のドメインをRP IDとして webauthnインスタンスの初期化 ◦ RP IDとなりうるドメインのホワイトリストで管理 → 検証用サイトで動かしたところ、ホワイトリストに登録さえされていれば、複数の異なるドメインのサービスからパスキー登録~認証ができることを確認！

実装上の課題・解決策 ~RP IDの管理~ 修正(余談) • オリジンから登録可能なドメイン接尾辞を抽出する処理をGoで書くにあたって publicsuﬃx というパッケージが有用だった (https://pkg.go.dev/golang.org/x/net/publicsuﬃx) 実行結果

1つの認証認可基盤からドメインの異なる複数のサービスにパスキー認証機能を提供したい場合にRP IDをどう設定するかが課題となった • リクエストしてくるサービスに応じてRP IDの設定を動的に変更するアプローチで解決 ◦ ユーザー視点で、サービス間でアカウントの特性が異なるため、PR IDを統合しない 2. 実装上の課題・解決策 ~RP IDの管理~ この章のまとめ

40 Copyright © 2025 Bitkey Inc. All right reserved. 別解
~Related Origin Requests~

41 Copyright © 2025 Bitkey Inc. All right reserved. 「他のプロダクトではどうしてるんだろう？」
「もっといいやり方ってあったんだろうか？」 3. 別解 ~Related Origin Requests~ なんとか解決したが…

別解 ~Related Origin Requests~ 引用元: https://gihyo.jp/book/2025/978-4-297-14653-5

「パスキーのすべて ── 導入・UX設計・実装」という書籍を読んだところ、 ”Related Origin Requests”という仕組みの存在を知る 3. 別解 ~Related Origin Requests~

#とは ◦ Relying Partyが、限定された関連オリジン間でパスキーの作成と使用を可能にする • ユースケース ◦ 同じサービスだけど、グローバル展開するうえでccTLD(*)を変えたい ◦ サービスのブランドを分けつつ、アカウントは同じものを使わせたい ↑本来ならOIDCなどのフェデレーションで達成するのが想定される。それが使えない場合に、サービスを跨いでパスキーの登録と認証を利用可能にする。 *...国別コードトップレベルドメイン。例えば、日本だと”.jp”でドイツだと”.de” 3. 別解 ~Related Origin Requests~ Related Origin Requests

別解 ~Related Origin Requests~ • 要するに ◦ RP IDを1つに定めつつ ◦ ドメインの異なる複数のサービスへ同時にパスキー認証機能を提供できる ▪ = サイトを跨いでパスキーを共有できる Related Origin Requests

別解 ~Related Origin Requests~ • 要するに ◦ RP IDを1つに定めつつ ◦ ドメインの異なる複数のサービスへ同時にパスキー認証機能を提供できる ▪ = サイトを跨いでパスキーを共有できる Related Origin Requests 「1つの認証認可基盤からドメインの異なる複数のサービスにパスキー認証機能を提供したい」私たちの課題に対する回答にもなりそう！

別解 ~Related Origin Requests~ • 使い方 1. 以下のようなJSONを作成 a. origins にパスキーを共有したいオリジンを列挙 2. JSONを https://<RP_ID>/.well-known/webauthn でホスト Related Origin Requests

仕組み 1. クライアントとなるサイトでパスキーの作成(`navigator.credentials.create()`)、パスキーでの認証(`navigator.credentials.get()`)を実行する 2. RP IDと、サイトのオリジンが後方一致しない 3. ブラウザが https://<RP_ID>/.well-known/webauthn へGETリクエスト 4. “origins”にサイトのオリジンが含まれていれば処理を続行できる • 詳細はドキュメントへ ◦ https://passkeys.dev/docs/advanced/related-origins/ 3. 別解 ~Related Origin Requests~ Related Origin Requests

検証 ◦ RP IDをbitkey platformのドメインに固定 ◦ 「サービスに応じて動的にRP IDを設定する」実装を削除 ◦ .well-known/webauthn を以下の origins 設定でホスト ▪ bitkey platformのドメイン ▪ 検証用サイトのドメイン → 検証用サイトで、パスキー登録~認証ができることを確認！ 3. 別解 ~Related Origin Requests~ Related Origin Requests

別解 ~Related Origin Requests~ • 検証 ◦ RP IDをbitkey platformのドメインに固定 ◦ 「サービスに応じて動的にRP IDを設定する」実装を削除 ◦ .well-known/webauthn を以下の origins 設定でホスト ▪ bitkey platformのドメイン ▪ 検証用サイトのドメイン → 検証用サイトで、パスキー登録~認証ができることを確認！ Related Origin Requests ただ…

bitkey platformでは、使わない ◦ Related Origin Requestsはサービスを跨いでパスキーを共有するための仕組み ◦ homehub, workhubでパスキーは共有しない → RP ID管理の課題に対する解決策ではあるが、bitkey platformのユースケースに合わない 3. 別解 ~Related Origin Requests~ Related Origin Requests

Related Origin Requestsという機構がある ◦ RP IDを1つに定めつつ、ドメインが異なるサービスでパスキーの共有ができるようにする • 例外もあるが、「1つの認証認可基盤、(ドメインが異なる)複数のサービス」という状況に大抵マッチしそう 3. 別解 ~Related Origin Requests~ この章のまとめ

今回紹介したRP ID管理の課題は下記の条件下で発生する ◦ 認証認可基盤を自社で開発 ◦ 認証機能の提供先である自社サービスを複数、異なるドメインで運営(*) *...複数の自社サービスをサブドメインを割り当てて運営していれば発生しない 4. まとめ振り返り

まとめ • 似たような状況になったら、サービスのブランドやアカウントの特性を考慮して意思決定前提：「認証基盤は1つ」「異なるブランドで自社サービスを複数展開している」 1. サービス間でアカウントの特性が同じ場合 2. サービス間でアカウントの特性が異なる場合振り返り

まとめ bitkey platformにパスキー認証を実装するときの課題と解決策についてお伝えしました！この発表がこれからパスキー認証を実装する方の参考になれば幸いです 💪

複数ブランドを支える認証認可基盤における、 パスキー認証実装の課題と解決策/Challenge...

複数ブランドを支える認証認可基盤における、 パスキー認証実装の課題と解決策/Challenges and Solutions for Passkey Authentication Implementation in AuthN and AuthZ Infrastructure Supporting Multiple Brands

More Decks by 株式会社ビットキー / Bitkey Inc.

Featured

Transcript

複数ブランドを支える認証認可基盤における、パスキー認証実装の課題と解決策/Challenge...

複数ブランドを支える認証認可基盤における、パスキー認証実装の課題と解決策/Challenges and Solutions for Passkey Authentication Implementation in AuthN and AuthZ Infrastructure Supporting Multiple Brands