よくある質問

Push! Passkeyの導入・実装・運用でよくある質問

このページでは、Push! Passkeyの導入前、実装中、テスト、本番運用でよくある質問をまとめています。

質問への回答だけでなく、関連する詳細ページへのリンクも掲載しています。

APIの正式な項目、エラーコード、サンプルコードについては、それぞれの専用ページもあわせて確認してください。

サービスとパスキーの基本
登録・認証
端末・ブラウザ
API・バックエンド実装
認証結果とセッション
エラー・トラブル
セキュリティ
運用・復旧

1. サービスとパスキーの基本

Q1. Push! Passkeyは何を提供するサービスですか？

Push! Passkeyは、Webサイトへパスキー登録・認証機能を追加するための認証APIサービスです。

Challenge生成、WebAuthn登録結果の検証、認証署名の検証、Credential IDと公開鍵の管理、登録・認証画面、トランザクション管理、結果提供をPush! Passkey側で行います。

顧客サイト側では、自社ユーザーとの紐付け、登録前の本人確認、APIキー管理、認証結果確認、ログインセッション発行を行います。

Push! Passkeyとはを読む

Q2. パスキーと生体認証は同じものですか？

同じものではありません。

パスキーは公開鍵暗号を利用した認証方式です。顔認証や指紋認証は、端末内の秘密鍵を利用する本人であることを確認するために使われます。

端末によっては、生体認証ではなくPIN、パターン、端末パスコードを使用します。

Q3. Push! Passkeyへ顔や指紋の情報が送信されますか？

送信されません。

顔や指紋の情報は、OSや端末内の認証機能で処理されます。Push! Passkeyへ送信されるのは、WebAuthnの登録情報や署名結果です。

Q4. パスワードを完全に廃止できますか？

顧客サイトの運用方針によって異なります。

パスキーだけでログインする構成も可能ですが、初回登録、アカウント復旧、管理者確認、既存ユーザー移行などのために、一定期間パスワードやOTPを併用する場合があります。

パスワードを残す場合は、パスワード経路がパスキーより弱い侵入経路にならないよう注意してください。

Q5. Push! Passkeyはログインセッションまで発行しますか？

顧客サイトのログインセッションは、顧客サイト側で発行します。

Push! Passkeyは登録・認証結果を提供します。顧客サイトは結果照会後にユーザー状態、権限、契約状態を確認し、自社のセッションを発行してください。

Push! Passkeyの役割と顧客サイトの役割を左右に分け、Push! Passkey側にChallenge、WebAuthn、Credential、署名検証、result、顧客サイト側に本人確認、user_key、権限、session、recoveryを配置した横長ワイドのFAQ向け法人インフォグラフィック。白背景、青緑系。画像内のテキストは短い役割名だけに限定し、説明文章はできるだけ排除する。

2. 導入前の準備

Q6. 導入前に何を準備すればよいですか？

管理ツールへのログイン
利用ドメインの登録
APIキーの発行
連携するuser_keyの決定
登録前の本人確認方法
認証成功後の戻り先URL
テストユーザーとテスト端末
端末紛失時の復旧方法

実装ガイドを読む

Q7. ドメイン登録が必要なのはなぜですか？

APIキーと利用ドメインを紐付け、許可された顧客サイトからの利用であることを管理するためです。

開発環境、検証環境、本番環境でドメインが異なる場合は、それぞれを分けて登録・管理してください。

Q8. 開発環境と本番環境で同じAPIキーを使えますか？

環境ごとにAPIキーを分離することを推奨します。

開発用キーの漏えいや誤操作が本番へ影響しないよう、ドメイン、APIキー、ログ、ユーザーデータを分離してください。

Q9. user_keyには何を指定すればよいですか？

顧客サイト内でユーザーを一意に識別でき、変更されにくく、別人へ再利用されない値を指定してください。

可能であれば、内部ユーザーIDから外部連携用の識別子を生成します。

メールアドレスは変更される可能性があり、個人情報でもあるため、直接利用する場合は運用上の影響を検討してください。

Q10. パスキー登録前に本人確認は必要ですか？

必要です。

パスキー登録は、新しいログイン手段をアカウントへ追加する重要操作です。

ログイン済みセッションの確認に加えて、既存パスキー、パスワード再入力、OTPなどによる追加確認を検討してください。

3. パスキー登録

Q11. パスキー登録ボタンを押すと何が起きますか？

顧客サイトのJavaScriptがendpointへ登録開始を要求する
顧客バックエンドがセッションと本人確認状態を確認する
api_key、user_key、return_page_urlをPush! Passkey APIへ送信する
登録URLとrequest_idを受け取る
利用者がPush! Passkey登録画面でパスキーを作成する
顧客サイトが結果照会APIで登録結果を確認する

Q12. 登録URLを取得した時点で登録は完了していますか？

完了していません。

登録URLの発行は、登録トランザクションを開始するための処理です。

利用者が登録画面でパスキーを作成し、WebAuthn検証が成功し、結果照会APIでstatus=successを確認した時点で登録成功として扱います。

Q13. 同じユーザーが複数のパスキーを登録できますか？

複数端末や複数の認証器を利用する運用では、複数パスキーの登録を許可する構成が考えられます。

登録上限、端末名の表示、最終利用日時、無効化方法は、顧客サイトの運用方針に合わせて設計してください。

Q14. 同じ端末へ重複登録できますか？

ブラウザ、OS、認証情報プロバイダーの挙動によって異なります。

既存パスキーがある場合に新しいCredentialが作成されることもあります。顧客側では登録済み一覧と利用者向けの管理画面を準備することを推奨します。

Q15. 登録を途中でキャンセルした場合はどうなりますか？

登録結果は成功になりません。

結果照会でfailed、expired、処理中などの状態を確認し、必要に応じて再度登録URLを発行してください。

Q16. 登録URLの有効期限はありますか？

あります。

現在の仕様では、登録URLと認証URLの有効期限は発行から10分間です。

期限切れのURLは再利用せず、新しいURLを発行してください。

4. パスキー認証

Q17. 認証ボタンを押すと何が起きますか？

顧客サイトのJavaScriptがendpointへ認証開始を要求する
顧客バックエンドがuser_keyを決定する
Push! Passkey APIへ認証URL発行を要求する
利用者が認証画面でパスキーを選択する
端末内で顔、指紋、PINなどによる本人確認を行う
秘密鍵による署名をPush! Passkeyが公開鍵で検証する
顧客サイトが結果照会後に自社セッションを発行する

Q18. 認証画面で成功と表示されればログインしてよいですか？

画面表示だけでログインさせてはいけません。

顧客バックエンドから結果照会APIを呼び出し、request_id、kind、user_key、status、判定フラグを確認してください。

Q19. 認証成功後に確認する項目は何ですか？

HTTPステータス
JSON形式
ok
request_id
kind
user_key
status
is_completed
is_success
is_failed
is_expired
未使用の結果であること

認証結果の受け取りを読む

Q20. 同じ認証成功結果を複数回使えますか？

使わないでください。

ログインに利用した結果は顧客サイト側で使用済みとして記録し、再利用を拒否してください。

Q21. 認証成功後もログインできないことはありますか？

あります。

Push! Passkeyの認証成功後でも、顧客サイト側で退会、利用停止、契約終了、権限不足と判断した場合はログインを拒否できます。

Push! Passkey認証成功から顧客バックエンドでrequest_id、kind、user_key、status、flags、used、ユーザー状態、権限を確認し、最後にsession発行へ進む横長ワイドの法人向けFAQフロー図。白背景、青緑系。画像内のテキストはsuccess、request_id、kind、user_key、status、flags、used、state、permission、sessionなど必要最低限の短い用語だけとし、説明文章はできるだけ排除する。

5. 端末・ブラウザ

Q22. どのブラウザで利用できますか？

Chrome、Edge、Safariの最新安定版を推奨します。

FirefoxもWebAuthnを利用できますが、導入環境で登録・認証・認証器選択を実機確認してください。

対応環境を読む

Q23. どの端末で利用できますか？

Windows、macOS、iPhone、iPad、Androidなど、WebAuthnと端末の本人確認機能に対応した環境で利用できます。

Windows Hello、Touch ID、Face ID、指紋、PIN、端末パスコード、FIDO2セキュリティキーなどが利用されます。

Q24. 生体認証がない端末でも利用できますか？

利用できる場合があります。

Windows Hello PIN、AndroidのPINやパターン、Apple端末のパスコードなど、OSが許可する本人確認方法を利用します。

Q25. スマートフォンのパスキーをパソコンで使えますか？

対応するブラウザとOSの組み合わせでは利用できます。

パソコンに表示されたQRコードをスマートフォンで読み取り、Bluetoothなどによる近接確認を行うクロスデバイス認証が利用されます。

Q26. Bluetoothを無効にしていても別端末認証できますか？

クロスデバイス認証ではBluetoothによる近接確認が必要になる場合があります。

企業ポリシーでBluetoothが禁止されている場合は、同じ端末に保存したパスキーやセキュリティキーなど、別の認証方法を検討してください。

Q27. LINEやメールアプリ内のブラウザで利用できますか？

アプリ内ブラウザやWebViewでは、WebAuthnやパスワードマネージャーの呼び出しが制限される場合があります。

正常に動作しない場合は、Chrome、Safari、Edgeなどの外部ブラウザで開く導線を用意してください。

Q28. プライベートブラウズでも利用できますか？

ブラウザやOSによって挙動が異なります。

Cookie、セッション、認証情報候補が通常モードと異なる場合があるため、通常のブラウジングモードを推奨します。

6. 端末変更・紛失・同期

Q29. スマートフォンを機種変更したらパスキーは使えなくなりますか？

同期パスキーを利用している場合は、同じApple Account、Googleアカウント、対応パスワードマネージャーを通じて新しい端末で利用できる場合があります。

端末固定のパスキーや同期されていないパスキーは、新しい端末へ自動移行されないことがあります。

Q30. 端末を紛失した場合はどうすればよいですか？

顧客サイトで本人確認を行い、紛失端末に対応するパスキーを無効化してください。

不正利用の疑いがある場合は、顧客サイトの既存ログインセッションも失効させます。

Q31. パスキーを削除したら顧客サイトからも削除されますか？

端末やパスワードマネージャーでパスキーを削除しても、サーバ側に保存されたCredential情報が直ちに削除されるとは限りません。

認証時には利用できなくなりますが、顧客サイト側でも登録済みパスキーを管理・無効化できる画面を用意することを推奨します。

Q32. 複数端末を登録しておくべきですか？

複数端末を利用するユーザーには、予備のパスキーを登録できる運用が有効です。

ただし、登録数の上限、端末名、登録日時、最終利用日時、無効化方法を整理してください。

Q33. パスキーを一つも利用できない場合の復旧方法は？

顧客サイト側でアカウント復旧手順を準備してください。

復旧経路がパスキーより弱くならないよう、登録情報、本人確認書類、管理者確認、既存連絡先などを組み合わせます。

7. フロントエンド実装

Q34. フロントエンドで何を実装しますか？

Push! Passkey JavaScriptの読み込み
登録ボタン
認証ボタン
data-endpoint
成功後URL
処理中表示
エラー表示
二重送信防止

フロントエンド実装を読む

Q35. APIキーをJavaScriptへ設定しますか？

設定しません。

APIキーは顧客バックエンドだけで保持し、Push! Passkey APIへ送信するJSON本文へバックエンド側で付与します。

Q36. data-endpointには何を指定しますか？

顧客サイト内に実装したバックエンドendpointのURLを指定します。

data-endpoint="/pushpasskey/endpoint"

ブラウザからPush! Passkey APIへ直接接続するURLではありません。

Q37. JavaScriptが読み込めない場合はどうなりますか？

登録・認証処理を開始できません。

ブラウザの開発者ツールで、JavaScript URL、HTTPステータス、Content Security Policy、ネットワーク制限を確認してください。

8. バックエンド実装

Q38. バックエンドでは何を実装しますか？

POSTとJSONの受信
actionの検証
セッション確認
CSRF確認
user_keyの決定
api_keyの付与
Push! Passkey APIへのHTTPS通信
HTTP・JSON・必須項目の確認
request_idの保存
結果照合
ログとエラー処理

Q39. どのプログラミング言語で実装できますか？

HTTPSとJSONを扱えるバックエンド言語で実装できます。

Q40. APIキーはどのように送信しますか？

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

{
	"api_key": "xxxxxxxxxxxxxxxx",
	"user_key": "customer_user_123",
	"return_page_url": "https://example.com/login"
}

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

Q41. APIキーをHTTPヘッダーへ設定してもよいですか？

現在の正式仕様ではJSON本文へ設定します。

独自にヘッダーへ変更するとPush! Passkey APIの仕様と一致しないため、APIリファレンスに記載された形式を使用してください。

Q42. APIへ接続するとHTMLが返ってきました

API URL、HTTPメソッド、Webサーバ設定、プロキシ、HTTP 405・500などを確認してください。

バックエンドではContent-TypeとJSON解析を確認し、HTML応答を成功として扱わないでください。

Q43. タイムアウト後すぐに同じ処理を再送してよいですか？

無条件の再送は避けてください。

タイムアウト時でもPush! Passkey側で処理が完了している可能性があります。二重発行を防ぐため、処理種別、保存済みrequest_id、再試行回数を確認してください。

9. APIと結果照会

Q44. Push! PasskeyにはどのAPIがありますか？

API	用途
`/regist_url`	登録URLを発行する
`/auth_url`	認証URLを発行する
`/regist_result`	登録結果を照会する
`/auth_result`	認証結果を照会する

APIリファレンスを読む

Q45. result APIには何を送信しますか？

{
	"api_key": "xxxxxxxxxxxxxxxx",
	"request_id": "u_1234567890abcdef1234567890abcdef"
}

Q46. statusにはどの値がありますか？

status	内容
`issued`	URL発行済み、処理開始前
`in_progress`	登録・認証処理中
`success`	正常終了
`failed`	失敗
`expired`	有効期限切れ

Q47. ポーリング間隔はどの程度がよいですか？

短すぎる間隔で連続照会しないでください。

利用者体験とAPI負荷のバランスを考慮し、一定間隔で照会し、最大回数と全体の待機時間を設定してください。

Q48. リダイレクト、ポーリング、Webhookのどれを使うべきですか？

画面遷移中心の構成ではリダイレクトと結果照会、同一画面で待機する構成ではポーリング、サーバ間で非同期に結果を受け取る構成ではWebhookが適しています。

いずれの方式でも、顧客バックエンドで保存済みトランザクションと結果を照合してください。

10. セッションとCookie

Q49. 認証成功後にセッションIDを変更する必要がありますか？

必要です。

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

Q50. Cookieにはどの属性を設定しますか？

Secure
HttpOnly
SameSite
適切なPath
必要最小限のDomain

Q51. Push! PasskeyのCookieを顧客サイトのログインCookieとして使えますか？

使用しません。

Push! Passkeyの認証結果を確認した後、顧客サイト自身のセッション管理方式でCookieを発行してください。

Q52. ログアウト時にパスキーも削除されますか？

削除されません。

ログアウトは顧客サイトのログインセッションを終了する処理です。パスキーの削除・無効化は別の操作として実装してください。

11. エラー・トラブル

Q53. 利用者へerror_codeをそのまま表示してよいですか？

利用者向けには、理解しやすい案内へ変換することを推奨します。

error_codeは内部ログや問い合わせ時の調査に使用し、画面には再試行方法や有効期限切れなどの具体的な対応を表示してください。

エラーコードを読む

Q54. request_idが見つからないと表示されます

保存したrequest_idと照会時に送信したrequest_idが一致しているか確認してください。

別セッション、別タブ、期限切れ、DB保存失敗、文字列の切り詰めも確認します。

Q55. domain mismatchが発生します

APIキーに紐付くドメイン、登録済みドメイン、実際のアクセスドメイン、戻り先URLを確認してください。

Q56. kind mismatchが発生します

登録開始で発行したrequest_idを認証結果APIへ送るなど、処理種別が混在していないか確認してください。

Q57. 認証画面が開きません

JavaScriptが読み込まれているか
endpointが正常なJSONを返しているか
redirect_urlが取得できているか
ポップアップブロックの影響がないか
CSPでauth.jintec.comが遮断されていないか
URLの有効期限が切れていないか

Q58. 認証処理が端末でキャンセルされます

利用者のキャンセル、端末ロック、認証器未登録、認証画面のタイムアウトなどが考えられます。

結果照会とブラウザ側エラーを確認し、利用者へ再試行を案内してください。

Q59. どこから切り分ければよいですか？

フロントエンド
顧客endpoint
Push! Passkey API通信
認証画面
結果照会
顧客サイトのセッション

トラブルシューティングを読む

12. セキュリティ

Q60. パスキーならCSRFやXSS対策は不要ですか？

必要です。

パスキーは認証方式を強化しますが、顧客サイトのCSRF、XSS、セッション固定、権限管理、オープンリダイレクトなどを自動的に防止するものではありません。

Q61. APIキーをログへ出してもよいですか？

出力しないでください。

APIキー、Cookie、セッションID、パスワード、秘密鍵、不要な個人情報はログへ記録しません。

Q62. return_page_urlをブラウザから自由に指定してよいですか？

推奨しません。

顧客バックエンドで固定URLを設定するか、HTTPSと許可ホストのリストで検証してください。

Q63. 認証結果をURLパラメータだけで判断してよいですか？

判断してはいけません。

URLパラメータは画面遷移の補助情報として扱い、顧客バックエンドから結果照会APIを呼び出してください。

Q64. 管理ツールのアカウントを複数人で共有してよいですか？

共有を避け、管理者ごとに個別アカウントを使用してください。

退職・異動時の停止、最小権限、管理操作ログの確認を行います。

セキュリティ上の注意を読む

13. ログ・監視・問い合わせ

Q65. 障害調査のために何をログへ記録しますか？

timestamp
受付番号
request_id
actionまたはkind
API
HTTPステータス
error_code
再試行回数

Q66. 問い合わせ時に何を伝えればよいですか？

発生日時とタイムゾーン
request_id
処理種別
error_code
OSとバージョン
ブラウザとバージョン
利用端末と本人確認方法
再現手順

APIキー、Cookie、セッションID、パスワードを問い合わせ本文へ記載しないでください。

Q67. 監視すべき異常はありますか？

短時間の大量URL発行
大量の認証失敗
期限切れの急増
存在しないrequest_idの大量照会
domain・kind不一致の増加
大量の管理操作

14. 運用・管理

Q68. 登録済みパスキーを利用者が確認できますか？

顧客サイト側で登録済みパスキーの管理画面を用意することを推奨します。

端末名、登録日時、最終利用日時、無効化操作などを表示すると運用しやすくなります。

Q69. 退職・退会時に何をすればよいですか？

顧客サイトのユーザーを停止する
登録済みCredentialを無効化する
既存ログインセッションを失効させる
管理権限を削除する
操作ログを記録する

Q70. APIキーを定期的に変更する必要がありますか？

組織の秘密情報管理方針に従ってローテーションを検討してください。

漏えいの疑いがある場合、担当者変更、環境廃止、設定ファイル流出時は直ちに無効化・再発行します。

Q71. 本番公開前に何を確認すればよいですか？

HTTPS
APIキー管理
登録前の本人確認
user_key
CSRF
return_page_url
request_id保存
結果照会
権限確認
セッション再生成
結果再利用防止
復旧手順
管理者管理
ログ

Push! Passkey導入・運用の確認項目をsetup、registration、authentication、device、API、result、session、security、recovery、logの10項目に分けた2段構成のFAQチェックリスト型インフォグラフィック。横長ワイド、白背景、青緑系、法人向け。画像内のテキストは各項目名だけに限定し、説明文章はできるだけ排除する。

15. 関連ページ

基本と構成

実装

結果・調査・運用

まとめ

迷った場合は、フロントエンド・バックエンド・認証結果を分けて確認する

Push! Passkeyの導入では、登録URL・認証URLの発行、利用者端末でのWebAuthn処理、結果照会、顧客サイトのセッション発行が別々の処理として進みます。

APIキーはバックエンドだけで管理し、user_keyは顧客サイトのセッションやDBから決定してください。

認証画面の成功表示だけでログインさせず、顧客バックエンドから結果照会APIを呼び出し、request_id、kind、user_key、status、判定フラグを確認します。

端末変更、紛失、退職、退会、不正登録を想定し、パスキー無効化、既存セッション失効、本人確認、通知、ログ保全の運用を準備してください。