Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
複数ブランドを支える認証認可基盤における、 パスキー認証実装の課題と解決策/Challenge...
Search
株式会社ビットキー / Bitkey Inc.
February 14, 2025
2
1.1k
複数ブランドを支える認証認可基盤における、 パスキー認証実装の課題と解決策/Challenges and Solutions for Passkey Authentication Implementation in AuthN and AuthZ Infrastructure Supporting Multiple Brands
登壇者名:上窪 大暉
登壇したイベントタイトル:パスキー開発者の集い
登壇したイベントのURL:
https://nulab.connpass.com/event/341051/
株式会社ビットキー / Bitkey Inc.
February 14, 2025
Tweet
Share
More Decks by 株式会社ビットキー / Bitkey Inc.
See All by 株式会社ビットキー / Bitkey Inc.
整頓のジレンマとの戦い〜Tidy First?で振り返る事業とキャリアの歩み〜/Fighting the tidiness dilemma〜Business and Career Milestones Reflected on in Tidy First?〜
bitkey
2
16k
遠隔で同時に4人教育!? 〜リモート新人の「孤立」を防ぐオンボーディング事例〜/Educating 4 people at the same time remotely!〜Onboarding Case Studies to Prevent “Isolation” of Remote Newcomers〜
bitkey
0
47
ファームウェアは土管になるべきか 翻訳機になるべきか/Should firmware be a clay pipe or a translator?
bitkey
0
53
テストは合意形成をすべし!/Testing should be consensus building!
bitkey
0
63
Agentic Coding と 山登り と TypeScript〜体系的に考えてみよう!〜/Agentic Coding, Mountain Climbing and TypeScript~Let's think systematically!~
bitkey
0
250
"発信文化"をどうやって計測する?技術広報のKPI探索記/How do we measure communication culture?
bitkey
4
630
MCP でモノが動くとおもしろい/It is interesting when things move with MCP
bitkey
3
760
カオスに立ち向かう小規模チームの装備の選択〜フルスタックTSという装備の強み _ 弱み〜/Choosing equipment for a small team facing chaos ~ Strengths and weaknesses of full-stack TS~
bitkey
1
210
型化からはじめる時間づくり/Creating Time Starting with Modeling
bitkey
1
120
Featured
See All Featured
The Invisible Side of Design
smashingmag
301
51k
Building an army of robots
kneath
306
45k
What's in a price? How to price your products and services
michaelherold
246
12k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Agile that works and the tools we love
rasmusluckow
329
21k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Into the Great Unknown - MozCon
thekraken
40
1.9k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
Transcript
© 2025 Bitkey Inc. 複数ブランドを支える認証認可基盤における、 パスキー認証実装の課題と解決策 2025/2/13 株式会社ビットキー 上窪大暉
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. まとめ
7 Copyright © 2025 Bitkey Inc. All right reserved. ビットキーのサービス
8 Copyright © 2025 Bitkey Inc. All right reserved. •
パスキー認証実装中に遭遇した課題はサービス展開の仕方に起因 • 課題の背景について認識を合わせることが目的 1.ビットキーのサービス なぜサービス紹介が必要なのか
9 Copyright © 2025 Bitkey Inc. All right reserved. 1.ビットキーのサービス
homehub, workhub
10 Copyright © 2025 Bitkey Inc. All right reserved. •
homehub, workhubはブランドが分かれている • それぞれ異なるドメイン名を使用してデプロイされている • それぞれ独自にログインページを実装している ◦ “サービス共通のログインページ”があるわけではない 1.ビットキーのサービス homehub, workhub homehubのログインページ workhubのログインページ
11 Copyright © 2025 Bitkey Inc. All right reserved. 1.ビットキーのサービス
bitkey platform
12 Copyright © 2025 Bitkey Inc. All right reserved. 1.ビットキーのサービス
bitkey platform
13 Copyright © 2025 Bitkey Inc. All right reserved. •
homehub, workhubへ、認証機能をAPIとして提供 • “bitkeyアカウント”としてユーザー情報を一元管理 ◦ ユーザーは、homehub, workhubへ同じID・パスワードでログインできる(*) *...ただし、2025年2月現在、これが必要なユースケースは存在しない 1.ビットキーのサービス bitkey platform
14 Copyright © 2025 Bitkey Inc. All right reserved. •
homehub, workhubはID・パスワードでの認証がメイン ◦ パスワードはフィッシングなどの被害を受けやすい • パスキーはUXを損ねずにパスワード以上の安全性を実現 • bitkey platformがパスキー認証を実装して、homehub, workhubへ機能提供 ◦ → お客様の安全で快適なサービス利用に貢献 1.ビットキーのサービス パスキー認証の実装の動機
15 Copyright © 2025 Bitkey Inc. All right reserved. •
ビットキーはhomehub, workhubという2つのサービスを展開 ◦ それぞれ異なるドメイン名を使用してデプロイされている ◦ それぞれ独自にログインページを実装している • 認証認可基盤bitkey platformがhomehub, workhubの認証を支えている ◦ bitkey platformにパスキー認証機能を追加 1.ビットキーのサービス この章のまとめ
16 Copyright © 2025 Bitkey Inc. All right reserved. 実装上の課題・解決策
~RP IDの管理~
17 Copyright © 2025 Bitkey Inc. All right reserved. •
bitkey platformはGoで実装されている • 以下の観点でパスキー認証のためのライブラリを選定 ◦ Goのプログラムから使いやすいインターフェースであること ◦ メンテナンスが頻繁であること ◦ ドキュメントが充実していること ◦ 実装参考例が多いこと (hankoも使用している) ◦ 無料で使用できること → go-webauthn/webauthnに決定! ※実装当時の最新バージョンはv0.9.4 2. 実装上の課題・解決策 ~RP IDの管理~ 使用したライブラリ
18 Copyright © 2025 Bitkey Inc. All right reserved. •
go-webauthn/webauthnの仕様 ◦ webauthnインスタンスを初期化し、このインスタンスに実装されているパスキー登 録/認証のメソッドを呼び出す ◦ webauthnインスタンスを初期化するとき、パスキー認証のRelying Partyとなるア プリケーションのドメインを引数`RPID`として指定しなければならない 2. 実装上の課題・解決策 ~RP IDの管理~ 使用したライブラリ
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の管理~ 初期実装
20 Copyright © 2025 Bitkey Inc. All right reserved. 2.
実装上の課題・解決策 ~RP IDの管理~ 初期実装
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の管理~ 動作検証
22 Copyright © 2025 Bitkey Inc. All right reserved. 2.
実装上の課題・解決策 ~RP IDの管理~ 問題 • 検証用サイトでWebAuthn API (navigator.credentials.create()) を呼び出したときに エラーが発生 「Relying Party IDは、現在のドメインの登録可能なドメイン接尾辞でもな ければ、同じでもない。」
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 suffix(例えば、”.com”や”.co.jp”) + その直前のドメイン名で構成された文字列のこ と (参考: https://developer.mozilla.org/ja/docs/Glossary/Site ) 2. 実装上の課題・解決策 ~RP IDの管理~ 問題
24 Copyright © 2025 Bitkey Inc. All right reserved. •
RP IDの設定例 ◦ ログインページのあるwebサイトのオリジン ▪ https://login.example.com ◦ RP ID ▪ login.example.com ▪ example.com 2. 実装上の課題・解決策 ~RP IDの管理~ 問題
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のデフォルトドメインは `<PROJECT_ID>.firebaseapp.com` 2. 実装上の課題・解決策 ~RP IDの管理~ 問題
26 Copyright © 2025 Bitkey Inc. All right reserved. •
RP IDの設定について考え直して、気づく ◦ homehub, workhubは、それぞれ独自にログインページを実装している ▪ 「bitkey platformのドメインをRP IDにしていいのか…?」 ◦ homehub, workhubは、それぞれ異なるドメイン名を使用してデプロイされている ▪ 「どちらかのドメインをRP IDにしていいのか…?」 2. 実装上の課題・解決策 ~RP IDの管理~ 問題
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でパスキー認証が使えない 問題
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の管理~ 問題
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はこのサイトを経由してパスキー認証を行うようにする 対応方針
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それぞれの開発者 にとって実装コストが高い
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それぞれの開発者 にとって実装コストが高い
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それぞれの開発者 にとって実装コストが高い
33 Copyright © 2025 Bitkey Inc. All right reserved. •
私たちはA案を選択 ◦ 「RP IDの設定をサービスに応じて動的に変更し、homehub, workhubそれぞれでパ スキーの設定を行ってもらう」 • 理由 1. お客様からするとhomehub, workhubはそもそも別のサービスなので、別々にパス キーの設定をすることになったとしてもUXを損なうことにはならない 2. むしろ、”homehubアカウント”で作ったパスキーが”workhubアカウント”でのログ インに使えたりすると、お客様が戸惑う可能性がある 2. 実装上の課題・解決策 ~RP IDの管理~ 対応方針
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の管理~ 修正
35 Copyright © 2025 Bitkey Inc. All right reserved. 2.
実装上の課題・解決策 ~RP IDの管理~ 修正 • RP IDとなりうるドメインのホワイトリストを環境変数で用意し、ホワイトリストにない ドメインからのリクエストはエラーにする ◦ 知らないサービスのドメインがRP IDになってしまうことを防ぐ
36 Copyright © 2025 Bitkey Inc. All right reserved. 2.
実装上の課題・解決策 ~RP IDの管理~ 修正
37 Copyright © 2025 Bitkey Inc. All right reserved. 2.
実装上の課題・解決策 ~RP IDの管理~ 修正 • やったこと ◦ パスキー登録/認証のリクエストの度に、リクエスト元のドメインをRP IDとして webauthnインスタンスの初期化 ◦ RP IDとなりうるドメインのホワイトリストで管理 → 検証用サイトで動かしたところ、ホワイトリストに登録さえされていれば、複数の異なるド メインのサービスからパスキー登録~認証ができることを確認!
38 Copyright © 2025 Bitkey Inc. All right reserved. 2.
実装上の課題・解決策 ~RP IDの管理~ 修正(余談) • オリジンから登録可能なドメイン接尾辞を抽出する処理をGoで書くにあたって publicsuffix というパッケージが有用だった (https://pkg.go.dev/golang.org/x/net/publicsuffix) 実行結果
39 Copyright © 2025 Bitkey Inc. All right reserved. •
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~ なんとか解決したが…
42 Copyright © 2025 Bitkey Inc. All right reserved. 3.
別解 ~Related Origin Requests~ 引用元: https://gihyo.jp/book/2025/978-4-297-14653-5
43 Copyright © 2025 Bitkey Inc. All right reserved. •
「パスキーのすべて ── 導入・UX設計・実装」という書籍を読んだところ、 ”Related Origin Requests”という仕組みの存在を知る 3. 別解 ~Related Origin Requests~
44 Copyright © 2025 Bitkey Inc. All right reserved. •
#とは ◦ Relying Partyが、限定された関連オリジン間でパスキーの作成と使用を可能にする • ユースケース ◦ 同じサービスだけど、グローバル展開するうえでccTLD(*)を変えたい ◦ サービスのブランドを分けつつ、アカウントは同じものを使わせたい ↑本来ならOIDCなどのフェデレーションで達成するのが想定される。 それが使えない場合に、サービスを跨いでパスキーの登録と認証を利用可能にする。 *...国別コードトップレベルドメイン。例えば、日本だと”.jp”でドイツだと”.de” 3. 別解 ~Related Origin Requests~ Related Origin Requests
45 Copyright © 2025 Bitkey Inc. All right reserved. 3.
別解 ~Related Origin Requests~ • 要するに ◦ RP IDを1つに定めつつ ◦ ドメインの異なる複数のサービスへ同時にパスキー認証機能を提供できる ▪ = サイトを跨いでパスキーを共有できる Related Origin Requests
46 Copyright © 2025 Bitkey Inc. All right reserved. 3.
別解 ~Related Origin Requests~ • 要するに ◦ RP IDを1つに定めつつ ◦ ドメインの異なる複数のサービスへ同時にパスキー認証機能を提供できる ▪ = サイトを跨いでパスキーを共有できる Related Origin Requests 「1つの認証認可基盤からドメインの異なる複数のサービスにパスキー認証機能を提供したい」 私たちの課題に対する回答にもなりそう!
47 Copyright © 2025 Bitkey Inc. All right reserved. 3.
別解 ~Related Origin Requests~ • 使い方 1. 以下のようなJSONを作成 a. origins にパスキーを共有したいオリジンを列挙 2. JSONを https://<RP_ID>/.well-known/webauthn でホスト Related Origin Requests
48 Copyright © 2025 Bitkey Inc. All right reserved. •
仕組み 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
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
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 ただ…
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
52 Copyright © 2025 Bitkey Inc. All right reserved. •
Related Origin Requestsという機構がある ◦ RP IDを1つに定めつつ、ドメインが異なるサービスでパスキーの共有が できるようにする • 例外もあるが、「1つの認証認可基盤、(ドメインが異なる)複数のサービス」という状況 に大抵マッチしそう 3. 別解 ~Related Origin Requests~ この章のまとめ
53 Copyright © 2025 Bitkey Inc. All right reserved. まとめ
54 Copyright © 2025 Bitkey Inc. All right reserved. •
今回紹介したRP ID管理の課題は下記の条件下で発生する ◦ 認証認可基盤を自社で開発 ◦ 認証機能の提供先である自社サービスを複数、異なるドメインで運営(*) *...複数の自社サービスをサブドメインを割り当てて運営していれば発生しない 4. まとめ 振り返り
55 Copyright © 2025 Bitkey Inc. All right reserved. 4.
まとめ • 似たような状況になったら、サービスのブランドやアカウントの特性を考慮して意思決定 前提:「認証基盤は1つ」「異なるブランドで自社サービスを複数展開している」 1. サービス間でアカウントの特性が同じ場合 2. サービス間でアカウントの特性が異なる場合 振り返り
56 Copyright © 2025 Bitkey Inc. All right reserved. >
1. サービス間でアカウントの特性が同じ場合 • サービス共通ログインサイトの実装 • Related Origin Requestsの導入 → RP IDを1つに統合できる(= サービス間でパスキーを共有できる) 4. まとめ 似たような状況になったら
57 Copyright © 2025 Bitkey Inc. All right reserved. >
2. サービス間でアカウントの特性が異なる場合 • 動的にRP IDを設定する (= 今回のアプローチ) → RP IDは分けたままにする(= サービス間でパスキーは共有しない) 4. まとめ 似たような状況になったら
58 Copyright © 2025 Bitkey Inc. All right reserved. 4.
まとめ bitkey platformにパスキー認証を実装するときの課題と解決策についてお伝えしました! この発表がこれからパスキー認証を実装する方の参考になれば幸いです 💪
59 End of File Copyright © 2025 Bitkey Inc. All
right reserved.