セキュリティ上の注意

パスキー認証と顧客サイトのセキュリティを一体として設計する

Push! Passkeyは、WebAuthnの公開鍵暗号を利用して登録・認証処理を提供します。

ただし、パスキー認証を導入するだけで、顧客サイトのアカウント管理、権限管理、セッション管理、復旧運用、ログ管理まで自動的に安全になるわけではありません。

顧客サイトでは、登録前の本人確認、ユーザー識別子の決定、APIキーの保護、認証結果の照合、ログインセッションの発行、利用停止状態の判断、端末紛失時の復旧を安全に設計する必要があります。

本ページでは、Push! Passkeyを安全に実装・運用するための重要事項を、責任分界に沿って説明します。

責任分界
APIキー管理
登録前の本人確認
ユーザー識別子
CSRF・入力検証
認証結果の検証
セッション管理
権限・契約状態の確認
アカウント復旧
ログと監視
管理ツール
インシデント対応

1. セキュリティ責任分界

Push! Passkey側の責任

Challengeの生成と管理
WebAuthn登録結果の検証
認証署名の検証
Credential IDと公開鍵の管理
登録・認証トランザクションの管理
登録・認証結果の提供
認証画面とAPIの保護

顧客サイト側の責任

登録対象ユーザーの本人確認
自社ユーザーとuser_keyの紐付け
APIキーの安全な保管
CSRFと入力値の検証
request_id、kind、user_keyの照合
ユーザーの有効性と権限の確認
ログインセッションの発行
端末紛失・退職・契約終了時の対応
アカウント復旧と本人確認

Push! Passkeyの認証成功は、暗号学的な認証処理が成功したことを示します。

顧客サイトへのログイン許可、管理者権限、契約状態、利用停止状態は、顧客サイト側で判断してください。

左側に顧客サイト、右側にPush! Passkey認証基盤を配置し、中央の責任境界を挟んでセキュリティ責任を比較する横長ワイドの法人向けインフォグラフィック。顧客サイト側に本人確認、user_key、APIキー、権限、session、recovery、Push! Passkey側にChallenge、WebAuthn、Credential、公開鍵、署名検証、resultを配置する。白背景、青緑系。画像内のテキストは短い役割名だけに限定し、説明文章はできるだけ排除する。

2. HTTPSと信頼境界

すべての本番通信でHTTPSを使用する

顧客サイトのフロントエンド
顧客サイトのendpoint
Push! PasskeyのJavaScript
Push! Passkeyの登録・認証画面
顧客バックエンドからAPIへの通信

WebAuthnの公開鍵クレデンシャルは、正規のRPとオリジンに対応付けられます。

顧客サイトもHTTPSで保護し、通信経路上でHTML、JavaScript、Cookie、API応答が改ざんされないようにしてください。

TLS検証を無効にしない

証明書の有効期限を検証する
ホスト名を検証する
信頼できるCA証明書を使用する
開発用の検証無効化設定を本番へ持ち込まない

API接続時に証明書検証を無効化すると、中間者攻撃によってAPIキーや認証結果が窃取・改ざんされる危険があります。

3. APIキーの管理

APIキーはバックエンドだけで使用する

現在の正式仕様では、Push! Passkey APIへ送信するJSON本文のapi_key項目へAPIキーを設定します。

このJSONは、顧客サイトのバックエンドで作成してください。

出力してはいけない場所

HTML
JavaScript
data属性
ブラウザのLocal Storage
ブラウザのSession Storage
Cookie
URL・クエリ文字列
利用者向けエラー画面
通常ログ

推奨する保管場所

公開領域外の設定ファイル
環境変数
OSやコンテナのSecret機能
クラウドの秘密情報管理サービス

漏えい時の対応

対象APIキーを無効化する
新しいAPIキーを発行する
顧客バックエンドの設定を更新する
ログとアクセス履歴を調査する
漏えい経路を修正する

利用者ブラウザ、顧客バックエンド、Push! Passkey APIを横方向に配置し、APIキーを顧客バックエンド内の鍵付き領域だけに保存する構成図。HTML、JavaScript、Cookie、URL、logへの出力禁止を禁止アイコンで示す横長ワイドの法人向けインフォグラフィック。白背景、青緑系。画像内のテキストはbrowser、backend、APIキー、API、HTML禁止、Cookie禁止、log禁止など必要最低限の短い用語だけとし、説明文章はできるだけ排除する。

4. パスキー登録前の本人確認

ログイン中という理由だけで登録を許可しない

パスキー登録は、その後のログインに使用できる新しい認証手段をアカウントへ追加する重要操作です。

攻撃者が一時的にログインセッションを取得した状態で、自分の端末へパスキーを登録できると、継続的なアカウント乗っ取りにつながります。

推奨する確認

ログインセッションの有効性
最近実施した本人確認
必要に応じたパスワード再入力
既存パスキーによる再認証
OTPなど既存の追加本人確認
管理者操作の場合は権限の再確認

登録通知

新しいパスキーが登録された場合は、利用者へメールや既存の通知手段で知らせる運用を推奨します。

通知にはAPIキー、Credential IDの完全値、セッションIDなどの秘密情報を含めないでください。

5. user_keyの安全な設計

サーバ側で決定する

user_keyは、顧客サイトのセッションまたはDB検索結果からバックエンド側で決定してください。

ブラウザから送信された値だけを信用して登録対象ユーザーを決めてはいけません。

必要な性質

顧客サイト内で一意である
別の利用者へ再利用されない
退会後も誤って別人へ割り当てない
変更されにくい
不要な個人情報を含まない

メールアドレスを直接使用する場合

メールアドレスは変更される可能性があり、個人情報でもあります。

可能であれば、変更されない内部ユーザーIDから外部連携用の識別子を生成してください。

6. CSRF対策

登録開始要求を保護する

ログイン中の利用者に意図しないパスキー登録を実行させないよう、登録開始APIへCSRF対策を適用してください。

フレームワーク標準のCSRFトークン
同期トークンパターン
カスタムヘッダー
OriginまたはRefererの補助確認
SameSite Cookie

SameSiteだけに依存しない

SameSite属性は重要な補助対策ですが、アプリケーションの構成やブラウザ挙動を考慮し、重要操作ではCSRFトークンと組み合わせてください。

GETで状態を変更しない

パスキー登録開始、登録削除、セッション発行などの状態変更処理をGET要求で実装しないでください。

7. 入力値の検証

許可リストを使用する

顧客endpointが受け付ける処理種別は、次の正式な値へ限定します。

regist_start
auth_start
regist_result
auth_result

検証する項目

HTTPメソッド
Content-Type
JSON形式
action
request_idの形式と長さ
return_page_url
CSRFトークン
ログインセッション

接続先URLを入力値から生成しない

actionとPush! Passkey APIの接続先は、バックエンド内の固定対応表で決定してください。

ブラウザから受け取ったURLへAPIキー付きJSONを送信してはいけません。

8. return_page_urlの検証

オープンリダイレクトを防止する

return_page_urlを自由入力のURLとしてそのまま使用すると、認証完了後に利用者を攻撃者のサイトへ誘導する危険があります。

推奨する方法

顧客サイト内の固定URLをバックエンドで設定する
許可するホスト名を限定する
HTTPSだけを許可する
ユーザー情報や秘密情報をURLへ含めない
外部URLを許可する場合は厳格な許可リストを使用する

URLパラメータを認証結果として信用しない

リダイレクト時のpp_statusやpp_error_codeは画面遷移の補助情報です。

ログイン可否は、バックエンドから結果照会APIを呼び出して判断してください。

9. request_idの管理

開始処理と結果を紐付ける

URL発行APIから返されたrequest_idは、顧客サイト側でセッションまたはDBへ保存します。

一緒に保存する情報

request_id
kind
user_key
発行日時
有効期限
使用済み状態
顧客環境やテナント識別子

再利用を防止する

認証成功結果をログインに使用した後は、使用済みとして更新してください。

DBを利用する場合は、request_idへ一意制約を設定し、未使用から使用済みへの更新を原子的に行います。

10. 認証結果をサーバ側で検証する

画面上の成功表示だけでログインさせない

Push! Passkey認証画面から顧客サイトへ戻っただけでは、顧客サイトのログインを許可しないでください。

結果照会で確認する項目

HTTPステータスが正常
レスポンスが正しいJSON
okがtrue
request_idが保存値と一致
kindが開始処理と一致
user_keyが対象ユーザーと一致
statusがsuccess
is_completedがtrue
is_successがtrue
is_failedがfalse
is_expiredがfalse
結果が未使用

一つでも条件を満たさない場合は、ログインセッションを発行しないでください。

Push! Passkey認証成功後に顧客バックエンドでHTTP、JSON、request_id、kind、user_key、status、flags、usedを順に検証し、すべて成功した場合だけsession発行へ進む横長ワイドの法人向けセキュリティフロー図。白背景、青緑系。画像内のテキストはHTTP、JSON、request_id、kind、user_key、status、flags、used、sessionなど必要最低限の短い用語だけとし、説明文章はできるだけ排除する。

11. ユーザー状態と権限を確認する

パスキー認証成功と利用許可を分ける

認証結果のuser_keyから顧客サイトのユーザーを検索し、現在の利用状態を確認します。

ユーザーが存在する
退会していない
利用停止されていない
契約期間内である
対象サービスを利用できる
必要な権限を持っている
組織やテナントが有効である

管理者権限や高リスク操作では、通常ログインとは別に再認証や追加確認を行うことを検討してください。

12. セッション管理

認証成功後に新しいセッションを発行する

ログイン前の匿名セッションIDをそのままログイン後に使用せず、認証成功後にセッションIDを再生成してください。

Cookie属性

属性	推奨設定
`Secure`	HTTPS通信だけで送信する
`HttpOnly`	JavaScriptからセッションCookieを参照できないようにする
`SameSite`	サイト構成に応じてLaxまたはStrictを検討する
`Path`	必要な範囲へ限定する
`Domain`	不要に広いサブドメイン共有を避ける

有効期限

一定時間操作がない場合のアイドルタイムアウト
ログイン継続時間の絶対タイムアウト
高リスク操作前の再認証
ログアウト時のサーバ側無効化

13. 二重送信と再試行

処理を冪等にする

利用者の連続クリック、ブラウザ再読込、ネットワークタイムアウト、Webhook再送によって同じ処理が複数回実行される可能性があります。

対策

処理中はボタンを無効化する
request_idを一意に保存する
使用済み結果を再利用しない
条件付きUPDATEを使用する
再試行回数と間隔を制限する
タイムアウト直後に無条件再送しない

URL発行APIがタイムアウトした場合でも、Push! Passkey側で処理が完了している可能性があります。

14. エラー表示

利用者向け表示と内部情報を分離する

利用者向け	内部ログ
再試行方法	request_id
有効期限切れの案内	kind
問い合わせ用受付番号	APIパス
一般化したエラー内容	HTTPステータス
秘密情報を含めない	error_code

表示してはいけない情報

APIキー
セッションID
Cookie
スタックトレース
内部ファイルパス
SQL
データベース接続情報
APIの生レスポンス

15. ログ管理

記録する項目

timestamp
受付番号
request_id
kindまたはaction
処理段階
HTTPステータス
error_code
成功・失敗
再試行回数
管理操作の実施者

記録しない項目

APIキー
Cookie
セッションID
パスワード
秘密鍵
生体情報
不要な個人情報

ログ自体を保護する

閲覧権限を限定する
改ざんを検知できるようにする
保管期間を定める
時刻同期を行う
本番ログを開発端末へ無制限にコピーしない

バックエンドのログ設計をrequest ID、kind、HTTP、error code、transaction ID、timestampの記録項目と、APIキー、Cookie、passwordを記録禁止として比較する横長ワイドのインフォグラフィック。白背景、青緑系、法人向け。画像内のテキストはlog、request ID、HTTP、error、transaction、APIキー禁止など必要最低限の用語だけとし、説明文章はできるだけ排除する。

16. 管理ツールの保護

管理者アカウントを厳格に管理する

Push! Passkey管理ツールでは、ドメイン登録、APIキー発行、利用状況確認などの重要操作を行います。

管理者ごとに個別アカウントを使用する
共有アカウントを避ける
不要な管理者を削除する
退職・異動時に権限を停止する
最小権限を適用する
管理端末を適切に保護する
管理操作ログを確認する

APIキー表示時の注意

画面共有中に表示しない
メールやチャットへ平文で貼り付けない
ソースコード管理へ登録しない
不要なコピーを残さない

17. Credentialの削除・無効化

利用者の状態変更と連動させる

端末紛失、退職、退会、契約終了、不正利用の疑いがある場合は、パスキーの利用停止または削除を行える運用を準備してください。

必要な運用

登録済みパスキーの一覧確認
特定パスキーの無効化
全パスキーの無効化
ユーザーアカウント自体の停止
実施者と実施日時の記録
利用者への通知

Credentialの無効化と、顧客サイトの既存ログインセッションの無効化は別の処理です。

重大な不正利用が疑われる場合は、既存セッションも失効させてください。

18. アカウント復旧

パスキーより弱い復旧経路を作らない

パスキーを安全に導入しても、メールだけの簡単な確認や、推測しやすい秘密の質問だけでアカウントを復旧できると、攻撃者は復旧経路を狙います。

復旧設計で決める項目

本人確認方法
必要な証拠や登録情報
管理者承認の要否
復旧後の通知
既存パスキーを残すか無効化するか
既存セッションを失効させるか
監査ログの保管

複数パスキーの登録

利用者が複数端末を所有する場合は、予備のパスキーを登録できる運用にすると、復旧負荷を軽減できます。

19. フィッシングと利用者案内

正規ドメインを案内する

パスキーはRPとオリジンに対応付けられるため、偽サイト上では正規サイト用のパスキーを通常利用できません。

ただし、利用者が偽のサポート窓口へ情報を渡す、リモート操作を許可する、アカウント復旧を悪用されるなど、パスキー以外の手段による攻撃は残ります。

利用者へ案内する事項

正規の顧客サイトURL
認証画面の正規ドメイン
APIキーやPINを問い合わせないこと
不審な登録通知を受けた場合の連絡先
端末紛失時の連絡方法

20. コンテンツセキュリティ

XSSを防止する

顧客サイトにXSS脆弱性があると、利用者の操作、画面表示、セッション情報、登録・認証フローが攻撃者に悪用される可能性があります。

出力時にHTMLエスケープする
危険なHTML挿入を避ける
インラインJavaScriptを減らす
Content Security Policyを設定する
外部スクリプトの読込先を限定する
依存ライブラリを更新する

CSP設定時の注意

Push! PasskeyのJavaScriptと認証画面への接続を許可しつつ、不要なドメインを広く許可しないでください。

21. Webhookを利用する場合

サーバ間通知として検証する

HTTPSを使用する
送信元を検証する
署名または共有秘密情報を検証する
タイムスタンプと再送を確認する
同じrequest_idを重複処理しない
応答時間を短くする
処理失敗時の再試行を設計する

Webhook本文のstatusだけでセッションを発行せず、保存済みトランザクションと照合してください。

22. 開発・検証・本番環境の分離

設定を混在させない

ドメインを分離する
APIキーを分離する
ユーザーデータを分離する
ログ保管先を分離する
戻り先URLを分離する
環境ごとの秘密情報を分離する

本番データを開発環境へ持ち込まない

テストには専用ユーザーと専用Credentialを使用してください。

本番APIキーをローカル開発端末や公開リポジトリへ配置しないでください。

23. 依存関係とサーバ運用

ソフトウェアを更新する

OS
Webサーバ
PHP、Node.js、Python、Java、.NET
フレームワーク
HTTPクライアント
セッションストア
ログ基盤

不要な情報を公開しない

デバッグ画面
開発用APIドキュメント
ディレクトリ一覧
設定ファイル
バックアップファイル
バージョン管理ディレクトリ

24. 監視と異常検知

確認する事象

短時間の大量URL発行
同一ユーザーへの大量登録試行
大量の認証失敗
期限切れの急増
存在しないrequest_idの大量照会
domain・kind不一致の増加
管理者による大量APIキー操作
通常と異なる時間帯の管理操作

アラートへ秘密情報を含めない

監視通知にはrequest_id、error_code、受付番号などを使用し、APIキーやCookieを含めないでください。

25. インシデント対応

事前に手順を決める

事象	主な対応
APIキー漏えい	無効化、再発行、設定更新、ログ調査
端末紛失	Credential無効化、既存セッション失効、本人確認
不正パスキー登録	登録削除、セッション失効、本人確認、原因調査
アカウント乗っ取り	ユーザー停止、全Credential無効化、ログ保全
管理者アカウント侵害	管理権限停止、APIキー確認、管理操作ログ調査