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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 Copyright © 2025 Bitkey Inc. All right reserved. ● 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の管理~ 問題

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

27 Copyright © 2025 Bitkey Inc. All right reserved. 2. 実装上の課題・解決策 ~RP IDの管理~ ● 状況を整理 ○ RP IDは1つしか設定できない ○ bitkey platformのドメインをRP IDにすると、homehub, workhubでパスキー認証が使えない ○ homehubのドメインをRP IDにすると、workhubでパスキー認証が使えない ○ workhubのドメインをRP IDにすると、homehubでパスキー認証が使えない問題

Slide 28

Slide 28 text

28 Copyright © 2025 Bitkey Inc. All right reserved. ● 状況を整理 ○ 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の管理~ 問題

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

34 Copyright © 2025 Bitkey Inc. All right reserved. ● 「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の管理~ 修正

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

47 Copyright © 2025 Bitkey Inc. All right reserved. 3. 別解 ~Related Origin Requests~ ● 使い方 1. 以下のようなJSONを作成 a. origins にパスキーを共有したいオリジンを列挙 2. JSONを https:///.well-known/webauthn でホスト Related Origin Requests

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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