システム構成・責任分界

顧客サイトとPush! Passkeyが、それぞれ担当する処理を理解する

Push! Passkeyは、既存の会員サイトや業務システムへ、パスキー登録・認証機能を追加するための認証APIサービスです。

Push! Passkeyを利用すると、Challengeの生成、WebAuthn登録結果の検証、認証署名の検証、Credential IDと公開鍵の管理など、パスキー認証基盤に必要な専門処理をジンテック側へ外部化できます。

一方、Push! Passkeyが認証に成功しただけでは、顧客サイトへのログインは完成しません。

顧客サイト側では、認証対象となる自社ユーザーを特定し、Push! Passkeyから取得した結果を確認したうえで、自社サイトのログインセッションを発行する必要があります。

また、ユーザーの契約状態、利用停止状態、権限、パスキー登録を許可する条件、端末紛失時の復旧方法などは、顧客サイト側で設計します。

このページでは、Push! Passkeyを構成するシステム、登録・認証時のデータの流れ、各システムが保持する情報、顧客サイトとジンテックの責任分界について解説します。

• Push! Passkeyを構成するシステム
• 顧客サイトと認証基盤の接続方法
• パスキー登録時の処理フロー
• パスキー認証時の処理フロー
• 顧客サイトとPush! Passkeyの責任分界
• 各システムが保持する情報
• APIキー、認証結果、ログインセッションの安全な取り扱い
• 端末紛失やアカウント復旧時の役割
• 実装開始前に決める項目

1. Push! Passkeyを構成するシステム

複数のシステムが連携して認証を完了する

Push! Passkeyによるパスキー登録・認証は、一つのWebページだけで完結する処理ではありません。

利用者の端末、顧客サイトのフロントエンド、顧客サイトのバックエンド、Push! Passkey認証基盤、顧客サイトのユーザーDBやセッション管理機能が連携して処理を行います。

主な構成要素は次のとおりです。

認証ドメインと顧客サイトは異なる

Push! Passkeyでは、パスキー登録・認証処理を次の認証ドメインで実行します。

https://auth.jintec.com/

利用者が顧客サイトに設置されたボタンを押すと、顧客サイトのバックエンドからPush! Passkeyへ処理開始要求が送信されます。

その後、利用者はPush! Passkeyの認証ドメインでパスキー登録または認証を行います。

パスキーのRPはPush! Passkeyの認証ドメインとなり、WebAuthnのChallenge管理、登録結果の検証、認証署名の検証はPush! Passkey側で行われます。

ただし、顧客サイトのユーザーDBやログインセッションがPush! Passkey側へ移動するわけではありません。

管理ツールは認証処理とは別のシステム

Push! Passkey管理ツールは、契約企業の管理者や開発担当者が接続設定を行うためのシステムです。

管理ツールのURLは次のとおりです。

https://secure.jintec.com/

管理ツールでは、主に次の操作を行います。

• Push! Passkeyを導入するドメインの登録
• ドメインごとのAPIキー発行
• APIキーの無効化や再発行
• 登録・認証トランザクションの確認
• 利用状況やエラー情報の確認

管理ツールは、一般利用者が日常的にパスキー認証を行う画面ではありません。

一般利用者のパスキー処理は認証ドメインで行い、契約企業の設定・運用管理は管理ツールで行います。

2. 全体の接続構成

フロントエンドから直接APIキーを送信しない

顧客サイトのHTMLでは、Push! PasskeyのJavaScriptを読み込み、登録ボタンまたは認証ボタンを設置します。

<script src="https://auth.jintec.com/js/passkey.js"></script>

登録ボタンの例は次のとおりです。

<button
	type="button"
	class="push_btn"
	data-pushpasskey="regist"
	data-endpoint="/pushpasskey/endpoint"
	data-success-url="/regist_ok.html">
	パスキー登録
</button>

認証ボタンの例は次のとおりです。

<button
	type="button"
	class="push_btn auth"
	data-pushpasskey="auth"
	data-endpoint="/pushpasskey/endpoint"
	data-success-url="/auth_ok.html">
	パスキー認証
</button>

ボタンのdata-endpointには、Push! Passkey APIのURLを直接指定するのではなく、顧客サイト内に設置したバックエンドエンドポイントを指定します。

Push! PasskeyのAPIキーは、顧客サイトのバックエンドで管理します。

HTMLやJavaScriptへAPIキーを記載すると、ブラウザの開発者ツール、ページソース、通信内容などから第三者に確認されるおそれがあります。

基本的な通信経路

1. 利用者が顧客サイトの登録・認証ボタンを押す
2. Push! PasskeyのJavaScriptがボタンの設定を読み取る
3. JavaScriptが顧客サイト内のバックエンドエンドポイントへ要求する
4. 顧客サイトのバックエンドが自社ユーザーを特定する
5. 顧客サイトのバックエンドがAPIキーを付けてPush! Passkey APIへ接続する
6. Push! Passkeyが登録・認証トランザクションを作成する
7. 利用者がPush! Passkeyの認証ドメインでパスキー処理を行う
8. Push! Passkeyが登録・認証結果を検証する
9. 顧客サイトが結果を確認する
10. 認証成功時は顧客サイトが自社のログインセッションを発行する

バックエンドエンドポイントの役割

顧客サイト内のバックエンドエンドポイントは、単なる転送用URLではありません。

主に次の役割を持ちます。

• 現在の利用者を自社サイト上で特定する
• 登録または認証の処理種別を確認する
• Push! Passkeyへ連携するユーザー識別子を決定する
• APIキーを付けてPush! Passkey APIへ要求する
• APIのHTTPステータスとレスポンス内容を確認する
• エラー時に適切な応答をフロントエンドへ返す
• 必要に応じて顧客サイト側の監査ログを記録する

フロントエンドから送信されたユーザーIDを、そのまま信用してPush! Passkeyへ連携してはいけません。

登録対象ユーザーや認証対象ユーザーは、顧客サイトのログインセッションやサーバ側の情報を使って特定します。

3. パスキー登録時の処理フロー

登録前の本人確認は顧客サイトが担当する

パスキー登録は、新しい認証手段をユーザーアカウントへ追加する重要な操作です。

Push! Passkeyは、顧客サイトから連携されたユーザー識別子に対してパスキーを登録します。

しかし、そのユーザー識別子を現在操作している人物へ登録させてよいかどうかは、顧客サイト側で判断します。

登録前には、少なくとも次の状態を確認してください。

• 顧客サイトへ正規の方法でログインしている
• ログインセッションが有効である
• 登録対象のユーザーが利用停止状態ではない
• パスキー登録を許可されたユーザーである
• 必要に応じて追加認証や再認証を完了している
• CSRF対策が適切に行われている

ログインしていない利用者から送られたユーザーIDや、URLパラメータに指定されたユーザーIDだけを根拠として、パスキー登録を開始してはいけません。

登録処理の流れ

1. 利用者が顧客サイトへログインする
2. 顧客サイトが現在のユーザーを特定する
3. 顧客サイトがパスキー登録を許可できる状態か確認する
4. 利用者がパスキー登録ボタンを押す
5. 顧客サイトのバックエンドがPush! Passkeyへ登録開始を要求する
6. Push! Passkeyが登録用トランザクションを作成する
7. Push! Passkeyが一度限りのChallengeを生成する
8. 利用者がPush! Passkey認証ドメインでパスキー登録を行う
9. 利用者端末のAuthenticatorが鍵ペアを生成する
10. 秘密鍵は利用者端末またはパスキープロバイダー側で保護される
11. 公開鍵とCredential情報がPush! Passkeyへ返される
12. Push! PasskeyがChallenge、Origin、RP IDなどを検証する
13. 検証成功後、Credential IDと公開鍵を保存する
14. Push! Passkeyが登録結果を確定する
15. 顧客サイトが登録結果を確認する
16. 顧客サイトが登録完了画面を表示する

Push! Passkeyが確認すること

• 登録開始時に発行したChallengeと一致するか
• Challengeが有効期限内か
• Challengeが再利用されていないか
• 想定したOriginから実行されたか
• RP ID Hashが正しいか
• WebAuthnの処理種別が正しいか
• User Presenceが確認されたか
• 要求したUser Verificationが実施されたか
• 公開鍵アルゴリズムが利用可能か
• Credential情報が正しく生成されているか

顧客サイトが確認すること

• パスキー登録を開始した自社ユーザーが誰か
• 登録を許可してよいユーザーか
• Push! Passkeyへ連携したユーザー識別子が正しいか
• Push! Passkeyから返された結果が成功か
• 対象となるトランザクションが、自社が開始したものか
• 登録成功後に自社画面へどのように反映するか

パスキー登録成功後は、必要に応じて顧客サイト側でも「パスキー登録済み」などの状態を管理できます。

ただし、Credential IDや公開鍵そのものはPush! Passkey側で管理されます。

4. パスキー認証時の処理フロー

Push! Passkeyの認証成功と顧客サイトのログインは別の処理

Push! Passkeyが返す認証成功は、登録済みのパスキーによるWebAuthn認証が正常に完了したことを示します。

認証成功後に、顧客サイトへログインした状態を作成するのは顧客サイト側です。

Push! Passkeyが顧客サイトのログインCookieやアプリケーションセッションを直接発行することはありません。

認証処理の流れ

1. 利用者が顧客サイトのパスキー認証ボタンを押す
2. 顧客サイトのバックエンドがPush! Passkeyへ認証開始を要求する
3. Push! Passkeyが認証トランザクションを作成する
4. Push! Passkeyが一度限りのChallengeを生成する
5. 利用者がPush! Passkey認証ドメインで認証を開始する
6. 利用者端末が対象となるパスキーを提示する
7. 利用者が顔認証、指紋認証、PINなどを行う
8. 利用者端末が秘密鍵を使ってChallengeへ署名する
9. Push! Passkeyが登録済み公開鍵を使って署名を検証する
10. Push! Passkeyが認証結果を確定する
11. 顧客サイトが結果照会、Webhook、リダイレクトなどで結果を取得する
12. 顧客サイトが対象ユーザーの状態を確認する
13. 顧客サイトがログインセッションを発行する
14. 利用者をログイン後の画面へ遷移させる

認証成功後も顧客サイト側で確認する

認証結果が成功であっても、顧客サイトは自社ユーザーの現在状態を確認します。

例えば、次の状態ではログインを許可しない判断が必要になる場合があります。

• 退会済み
• 利用停止中
• 契約期限切れ
• 管理者によるロック中
• 対象サービスを利用する権限がない
• アカウント統合や削除によってユーザー識別子が無効になっている
• 追加の利用条件への同意が必要

Push! Passkeyはパスキーが正しく利用されたことを確認しますが、顧客サービスの利用可否までは判断しません。

ログインセッション発行時の注意

• サーバ側で認証結果を確認している
• URLパラメータだけを根拠に成功と判断していない
• 対象トランザクションが自社の認証要求と対応している
• 同じ認証結果を複数回使用できない
• 対象ユーザーが現在も有効である
• 認証前のセッションIDを再利用せず、認証後に再生成する
• CookieへSecure、HttpOnly、SameSiteなどを適切に設定する
• 認証成功日時と対象ユーザーを監査ログへ記録する

5. 顧客サイトとPush! Passkeyの責任分界

パスキー認証基盤と顧客サービスを分けて考える

Push! Passkeyは、パスキーによる登録・認証を安全に実行するための認証基盤を提供します。

顧客サイトは、自社サービスのユーザー管理、本人確認、権限管理、ログイン状態を管理します。

両者の責任分界は次のとおりです。

Push! Passkeyが本人確認のすべてを代行するわけではない

Push! Passkeyは、登録済みパスキーを正しく利用できる人物であることを確認します。

一方、初回のパスキー登録時に、その人物が顧客サイトの正当なアカウント所有者であるかを確認するのは顧客サイト側です。

例えば、第三者が何らかの方法で他人のログイン済み画面を操作し、自分のパスキーを登録できてしまうと、その後は第三者のパスキーで正常に認証できる状態になります。

そのため、パスキー登録前には、既存パスワード、メール確認、SMS認証、既存パスキー、管理者承認など、サービスのリスクに応じた本人確認を行います。

認証成功は権限付与を意味しない

Push! Passkeyの認証結果が成功であっても、そのユーザーへ管理者権限を付与したり、有料機能を利用させたりする判断は顧客サイト側で行います。

認証と認可は異なる処理です。

• 認証：その利用者が誰であるかを確認する
• 認可：確認された利用者に何を許可するかを決める

Push! Passkeyは主に認証を担当し、顧客サイトは認可を担当します。

6. 各システムが保持する情報

情報の保存場所を明確にする

Push! Passkeyを安全に実装するためには、どの情報をどのシステムで保持するかを明確にする必要があります。

秘密鍵と生体情報はPush! Passkeyへ保存しない

パスキーの秘密鍵は、利用者の端末、セキュリティキー、またはパスキープロバイダー側で保護されます。

Push! Passkeyや顧客サイトが、秘密鍵そのものを受け取って保存することはありません。

顔画像や指紋情報も、Push! Passkeyや顧客サイトへ送信されません。

顔認証、指紋認証、PINは、利用者端末内で秘密鍵の使用を許可するために利用されます。

ユーザー識別子は変更されにくい値を使用する

Push! Passkeyへ連携するユーザー識別子には、顧客サイトのユーザーを一意に識別できる値を使用します。

推奨される例は次のとおりです。

• 顧客サイト内部の数値ID
• UUID
• 外部連携専用に発行したランダムな識別子

メールアドレスは変更される可能性があり、個人情報にも該当するため、ユーザー識別子として使用する場合は運用を慎重に設計します。

氏名、電話番号、画面表示名など、一意性が保証されない値をユーザー識別子として使用しないでください。

識別子の再利用を避ける

退会したユーザーのIDを、将来別のユーザーへ再割り当てすると、過去のパスキーとの対応関係に問題が生じる可能性があります。

Push! Passkeyへ連携したユーザー識別子は、原則として別人へ再利用しない設計を推奨します。

7. 信頼境界とセキュリティ

ブラウザから受け取る値を無条件に信用しない

ブラウザから送信される次のような値は、利用者によって変更される可能性があります。

• 処理種別
• ユーザーID
• 成功後URL
• エンドポイントへ送信する追加パラメータ
• HTMLのdata属性
• JavaScriptで生成した値

重要な判断は、顧客サイトのバックエンドで行います。

特に、パスキー登録対象のユーザーは、ブラウザから送信されたユーザーIDではなく、顧客サイトのログインセッションから特定してください。

APIキーはサーバ側だけで利用する

APIキーはPush! Passkey APIへの接続を許可する機密情報です。

次の場所へAPIキーを記載してはいけません。

• HTML
• JavaScript
• CSS
• ブラウザへ返すJSON
• URLのクエリパラメータ
• 公開リポジトリ
• 利用者へ表示するエラーメッセージ

APIキーは、サーバ側の設定ファイル、環境変数、シークレット管理サービスなどで保管します。

可能な場合は、設定ファイルをドキュメントルートの外へ配置してください。

リダイレクト先の画面だけで成功と判断しない

認証後にauth_ok.htmlが表示されたことだけを根拠として、ログイン成功と判断してはいけません。

リダイレクトは利用者のブラウザを目的の画面へ移動させる仕組みであり、サーバ間で認証結果を保証する仕組みではありません。

認証成功後のログインセッションは、顧客サイトのバックエンドがPush! Passkeyの結果を確認した後に発行します。

トランザクションを対応付ける

登録・認証開始時には、Push! Passkey側でトランザクションを識別する情報が発行されます。

顧客サイトでは、自社が開始した処理とPush! Passkeyから返された結果を対応付けます。

確認する代表的な項目は次のとおりです。

• トランザクションまたはリクエストを識別する値
• 登録または認証の処理種別
• 顧客サイトのユーザー識別子
• 処理開始日時
• 処理完了日時
• 成功、失敗、処理中などの状態
• エラーコード
• 同じ結果がすでに使用されていないか

CSRFとセッション固定攻撃へ対策する

パスキー登録の開始操作は、ユーザーアカウントへ新しい認証手段を追加する重要操作です。

顧客サイトの登録開始エンドポイントには、通常の会員情報変更画面と同様にCSRF対策が必要です。

また、認証成功後は、認証前に使用していたセッションIDをそのまま継続せず、セッションIDを再生成してセッション固定攻撃を防止します。

8. 障害・紛失・アカウント復旧時の責任

認証基盤の障害と顧客サイトの障害を切り分ける

Push! Passkeyを利用した認証では、複数のシステムが連携します。

問題が発生した場合は、どの区間で失敗しているかを確認します。

顧客サイトでは、Push! Passkeyのトランザクション情報と自社のアプリケーションログを照合できるようにします。

端末紛失時の対応

利用者が端末を紛失した場合、顧客サイトでは次のような対応方針を決めておく必要があります。

• 別端末に同期されたパスキーでログインできるか
• 複数のパスキー登録を許可するか
• 登録済みパスキーを管理画面から停止できるか
• 管理者による本人確認後に登録を解除できるか
• 既存のパスワードやOTPを復旧手段として残すか
• 復旧後に既存パスキーをすべて無効化するか
• 紛失申告を監査ログへ記録するか

Push! Passkey側がCredentialを管理していても、誰からの依頼で停止や再登録を認めるかは、顧客サービスの本人確認方針に基づいて判断します。

アカウント復旧は顧客サイトの業務設計

すべてのパスキーを利用できなくなった場合に備えて、アカウント復旧手順が必要です。

復旧手段がパスキーより著しく弱い場合、攻撃者は通常のパスキー認証ではなく、復旧経路を狙います。

サービスの重要度に応じて、次のような方法を組み合わせます。

• 本人確認済みメールアドレスへの確認
• 登録済み電話番号への確認
• 本人確認書類
• 管理者による目視確認
• 契約情報や顧客番号の確認
• 対面確認
• 複数担当者による承認
• 一定時間の利用制限
• 復旧実行時の通知

復旧が完了した場合は、既存のパスキーをそのまま残すか、すべて停止して再登録させるかを決めておきます。

サービス停止時の代替手段

Push! Passkeyを主要なログイン手段として利用する場合は、認証基盤やネットワークへ一時的に接続できない状況も想定します。

顧客サイト側で検討する項目には、次のようなものがあります。

• 従来認証を一時的な代替手段として残すか
• 管理者だけに緊急ログイン手段を用意するか
• 認証障害中のメンテナンス画面
• 利用者への障害案内
• 顧客サポートの受付方法
• 障害復旧後の認証ログ確認
• 重要操作を一時的に停止するか

代替認証を残す場合は、その認証方法が攻撃者の恒常的な迂回経路にならないように設計します。

9. 導入前に決める項目

実装開始前に顧客サイト側の方針を整理する

ユーザー識別

• Push! Passkeyへ連携するユーザー識別子は何か
• 識別子は一意か
• 識別子は変更されないか
• 退会後に同じ識別子を別人へ再利用しないか
• 個人情報を必要以上に連携していないか

パスキー登録

• どの画面から登録を開始するか
• 登録前にどの本人確認を行うか
• ログイン直後だけ登録可能にするか
• 1ユーザーに複数パスキーを許可するか
• 登録数の上限を設けるか
• 追加登録時に再認証を要求するか

パスキー認証

• パスキー認証を通常ログインに使用するか
• 重要操作の追加認証に使用するか
• ユーザーIDを先に入力させるか
• 認証成功後の遷移先はどこか
• どの時点でログインセッションを発行するか
• 認証結果をどの方法で取得するか

ユーザー状態と権限

• 利用停止中のユーザーをどう扱うか
• 契約期限切れのユーザーをどう扱うか
• 退職者や退会者のパスキーをどう停止するか
• 管理者と一般利用者で認証後の権限をどう分けるか
• 認証済みでも追加確認が必要な操作はあるか

紛失・復旧

• 端末紛失時の受付方法
• パスキーをすべて失った場合の本人確認方法
• 管理者がパスキーを無効化できるか
• 復旧後に既存パスキーを残すか
• 複数端末登録を推奨するか
• 従来認証を復旧手段として残すか

開発・運用環境

• 開発、検証、本番でドメインを分けるか
• 環境ごとにAPIキーを分けるか
• APIキーをどこに保存するか
• API通信のタイムアウトを何秒にするか
• 通信エラー時に何回再試行するか
• 顧客サイト側でどのログを保存するか
• 個人情報やAPIキーをログへ出力しない設計になっているか

環境ごとに接続設定を分ける

開発環境、検証環境、本番環境でドメインが異なる場合は、それぞれをPush! Passkey管理ツールへ登録し、APIキーを分けて管理します。

本番用APIキーを開発者のローカル環境へ保存したり、開発環境のソースコードへ記載したりしないでください。

まとめ

パスキー認証と顧客サイトへのログインを分けて設計する

Push! Passkeyは、パスキー登録・認証に必要となるChallenge管理、WebAuthn検証、Credential IDと公開鍵の管理、認証署名の検証、トランザクション管理を提供します。

顧客サイト側は、自社ユーザーの本人確認、ユーザー識別子の連携、認証結果の確認、ログインセッションの発行、権限管理、契約状態の確認、端末紛失時の復旧を担当します。

重要な責任分界は次のとおりです。

• Push! Passkeyは、登録されたパスキーによる認証が正しいかを確認する
• 顧客サイトは、誰にパスキーを登録させるかを判断する
• Push! Passkeyは、認証結果を顧客サイトへ提供する
• 顧客サイトは、認証結果を確認してログインセッションを発行する
• Push! Passkeyは、Credential IDと公開鍵を管理する
• 顧客サイトは、自社ユーザーの権限、契約、利用停止状態を管理する
• APIキーは顧客サイトのバックエンドで保管する
• 秘密鍵と生体情報は利用者端末から外へ送信されない

Push! Passkeyを安全に導入するには、「認証APIへ接続できたか」だけでなく、登録前の本人確認、認証後のセッション発行、ユーザー状態の確認、紛失時の復旧までを一連の仕組みとして設計する必要があります。

システム構成と責任分界を確認した後は、「実装ガイド」で導入作業の順序と必要なファイルを確認してください。

実装ガイドを読む