Push! Passkeyとは

既存のWebサイトへ、パスキー登録・認証機能を追加するAPIサービス

パスキーは、パスワードに代わる安全性の高い認証方式です。

しかし、既存の会員サイトや業務システムへパスキーを追加するには、ブラウザ上でWebAuthn APIを呼び出すだけではありません。

パスキー登録用・認証用のChallenge生成、公開鍵とCredential情報の保存、署名検証、複数端末への対応、認証ログ、エラー処理など、フロントエンド、バックエンド、データベースにまたがる実装が必要です。

Push! Passkeyは、こうしたパスキー認証の専門領域を外部の認証基盤として提供し、既存のWebサイトからAPIで利用できるサービスです。

既存のユーザーDBやログイン後の業務処理はそのまま維持しながら、パスキーの登録と認証に必要な機能だけを追加できます。

このページでは、Push! Passkeyでできること、一般的な自営実装との違い、認証の仕組み、実装手順、管理サイトの機能について解説します。

Push! Passkeyで提供される登録・認証機能
Push! Passkeyを利用する場合のRPと認証ドメイン
自社実装とAPI接続の開発範囲の違い
既存サイトとPush! Passkeyの接続方法
JavaScript、HTMLボタン、バックエンドファイルによる実装手順
管理サイトで確認できる接続情報とトランザクション

1. Push! Passkeyでは何ができる？

パスキー認証基盤を一から構築せず、既存サイトへ組み込める

パスキーを自社で直接実装する場合、WebAuthnの仕様を理解し、登録・認証処理をフロントエンドとバックエンドの両方へ実装する必要があります。

Push! Passkeyでは、パスキー登録とパスキー認証に必要な処理を、ジンテックが運用する認証基盤から提供します。

既存サイト側で行う主な作業は、次の3点です。

Push! PasskeyのJavaScriptを読み込む
パスキー登録・認証ボタンのHTMLを設置する
APIキーなどの機密情報を設定したバックエンドファイルを設置する

これにより、自社でWebAuthn認証基盤そのものを構築するのではなく、既存サイトのログインフローへパスキー認証結果を組み込むことができます。

登録APIと認証APIを提供

Push! Passkeyでは、次の2つの基本機能を提供します。

パスキー登録

既存サイトのユーザーと、利用者の端末に作成されたパスキーを紐付けます。

登録時には、Push! Passkey側で登録用Challengeの生成、WebAuthn登録結果の検証、Credential情報と公開鍵の保管を行います。

パスキー認証

登録済みのパスキーを利用して、利用者本人であることを確認します。

認証時には、認証用Challengeの生成、端末から返された署名の検証、登録済みCredentialとの照合をPush! Passkey側で行います。

既存サイトは、Push! Passkeyから返された認証結果を確認し、認証成功後に自社サイトのログインセッションを発行します。

複数のWebサイトを一つの管理サイトで管理

複数の会員サイト、業務システム、Webサービスを運営している事業者にも対応できます。

管理サイトでは、利用するWebサイトごとにAPI接続情報を管理し、それぞれのサイトで発生した登録・認証トランザクションを確認できます。

例えば、次のような情報を把握できます。

どのWebサイトから利用されたか
パスキー登録と認証のどちらが実行されたか
いつ処理が開始・完了したか
認証が成功したか、失敗したか
どの利用者識別子に関する処理だったか
エラーが発生した場合の結果情報

Push! Passkeyは、単にWebAuthn APIを実行するだけでなく、パスキーの利用状況を継続的に確認できる管理環境も提供します。

既存の会員サイトを中央に配置し、JavaScript、HTMLボタン、バックエンドAPI接続の3要素を通じてPush! Passkeyへ接続する構成図。右側にはパスキー登録、パスキー認証、ログ確認の3機能をアイコンで配置する。白背景、青緑系、横長ワイド画像、法人向け、文章は最小限。

2. RPはジンテックの認証ドメインになります

パスキーはRPのドメインに結び付けられる

パスキーは、登録先となるWebサービスのRP IDに結び付けられます。

一般的な自営実装では、パスキーを導入するWebサイト自身がRPとなります。

例えば、example.comが自社でWebAuthnを直接実装した場合、原則として、そのドメインを基準としたパスキーが作成されます。

Push! Passkeyでは、パスキー登録・認証部分をジンテックの認証基盤へ外部化するため、パスキーのRPはジンテックが運用する認証ドメインになります。

ジンテックの認証ドメインでパスキーを実行する

利用者が既存サイトに設置されたパスキー登録または認証ボタンを押すと、Push! Passkeyの認証処理が開始されます。

パスキーの作成や署名検証は、Push! Passkeyの認証ドメインを基準として行われます。

これは、自社ドメイン内にFIDO2／WebAuthnを直接実装する方式ではありません。

ジンテックの認証ドメインでパスキー登録・認証を実行し、その処理結果をAPIを通じて既存サイトへ連携する方式です。

既存サイトのログイン管理は自社に残る

RPがジンテックの認証ドメインになる場合でも、既存サイトのユーザーDBやログイン後の権限管理がジンテック側へ移管されるわけではありません。

既存サイトには、次の役割が残ります。

パスキー登録を許可するユーザーの判断
自社ユーザーとPush! Passkey側の識別子との紐付け
認証結果の確認
認証成功後のログインセッション発行
ユーザーの権限、契約状態、利用停止状態の判断
ログイン後に表示する画面や利用可能機能の制御

Push! Passkeyが確認するのは、登録されたパスキーによる認証が正しく完了したかどうかです。

認証に成功した利用者へ、どの権限を与え、どのサービスを利用させるかは、既存サイト側で判断します。

RPの違いを理解したうえで導入する

完全な自営実装では、自社ドメインをRPとして、認証基盤を自由に設計できます。

一方、Push! Passkeyでは、ジンテックの認証基盤を利用することで、WebAuthnの複雑な処理を自社で構築・保守する負担を減らします。

その代わり、パスキーがジンテックの認証ドメインに対して登録されることを前提とした構成になります。

導入時には、次の点を整理します。

既存サイトのどの画面からパスキー登録を開始するか
パスキー登録前に、どの方法で本人確認を行うか
自社ユーザーを識別するために、どの値を連携するか
パスキー認証成功後に、どのログイン処理へ接続するか
パスキーを失った場合に、どのようにアカウントを復旧するか

Push! Passkeyでは、これらの導入設計について事前相談に対応します。

左側に顧客Webサイト、中央にPush! Passkeyの認証ドメイン、右側に利用者のスマートフォンを配置する。顧客サイトのボタンから認証ドメインへ移動し、スマートフォンでパスキー認証を行い、認証結果だけが顧客サイトへ戻る流れを示す。RPはPush! Passkey側であることをドメインと鍵アイコンで表現する。横長ワイド画像

3. 自社実装とAPI接続との違い

自社で直接実装する場合

自社でパスキーを直接実装する場合は、自社システムがRPとなり、パスキー認証基盤を自社で構築します。

自由度が高く、自社独自の認証ポリシーや端末制御を実装できる一方、パスキーに関する専門的な開発と継続的な保守が必要です。

主な実装項目は次のとおりです。

FIDO2とWebAuthnの仕様理解
登録・認証用Challengeの生成
Challengeの一時保存と有効期限管理
フロントエンドでのWebAuthn API呼び出し
Base64URLとArrayBufferの変換
WebAuthn登録結果の検証
OriginとRP ID Hashの検証
認証時のデジタル署名検証
公開鍵とCredential IDのデータベース管理
複数端末・複数パスキーへの対応
初回登録、追加登録、削除の設計
端末紛失時の無効化とアカウント復旧
認証ログと監査ログの保存
OS・ブラウザごとの動作確認
既存ログインやセッション管理との統合
エラー、キャンセル、タイムアウトへの対応

WebAuthn対応ライブラリを利用する場合でも、誰に登録を許可するか、どのようにユーザーとCredentialを紐付けるか、認証成功後にどのようなセッションを発行するかといった設計は自社に残ります。

Push! Passkeyを利用する場合

Push! Passkeyでは、パスキー登録・認証に関する専門領域をジンテックの認証基盤へ切り出します。

Push! Passkey側では、主に次の処理を担当します。

登録用・認証用Challengeの生成と管理
WebAuthn登録オプションの生成
登録結果の解析と検証
認証署名の解析と検証
Credential情報と公開鍵の保管
パスキー登録・認証画面の提供
複数パスキーに関する管理
認証結果の照会
登録・認証トランザクションの記録
認証結果やエラー情報の返却

既存サイト側は、次の処理を担当します。

パスキー登録・認証ボタンの設置
API接続用バックエンドファイルの設置
APIキーの安全な保管
自社ユーザー識別子の連携
認証結果の確認
認証成功後のログインセッション発行
自社ユーザーの権限と利用状態の判断

比較表

比較項目	自社で直接実装	Push! Passkey
RP	自社ドメイン	ジンテックの認証ドメイン
既存ユーザーDB	自社で維持	自社で維持
WebAuthnフロントエンド	自社で実装	共通JavaScriptを利用
Challenge管理	自社で実装	Push! Passkeyが担当
登録結果の検証	自社で実装	Push! Passkeyが担当
認証署名の検証	自社で実装	Push! Passkeyが担当
Credential DB	自社で構築・管理	Push! Passkeyが管理
登録・認証画面	自社で作成	Push! Passkeyが提供
ログ・トランザクション管理	自社で構築	管理サイトで確認
ログインセッション	自社で発行	自社で発行
カスタマイズ性	高い	API仕様の範囲内
初期開発負荷	大きい	小さくしやすい
継続保守	自社で対応	認証基盤部分はジンテックが対応
導入相談	自社で設計	ジンテックへ相談可能

パスキーを「実装する」のではなく「接続する」

完全自営では、自社がWebAuthn認証基盤そのものを作ります。

Push! Passkeyでは、すでに用意されたパスキー認証基盤へ既存サイトを接続します。

そのため、既存のユーザーDB、既存のログイン画面、ログイン後の業務システムを維持しながら、パスキー認証機能だけを追加しやすくなります。

特に、次のような事業者に適しています。

既存の会員サイトへパスキーを追加したい
現在のユーザーDBを変更したくない
独自のログイン後画面や権限管理を維持したい
WebAuthnの署名検証基盤を自社で保守したくない
複数サイトのパスキー利用状況をまとめて管理したい
まずは限定的な画面や一部ユーザーから導入したい

左側に完全自営実装、右側にPush! Passkeyを配置した比較図。完全自営側にはフロントエンド、バックエンド、Credential DB、署名検証、ログ、復旧を積み上げ、Push! Passkey側では既存サイト、ボタン、API接続、認証基盤の4要素に整理する。横長ワイド画像

4. Push! Passkeyの仕組み

既存サイトには登録・認証ボタンを設置する

Push! Passkeyを利用する既存サイトには、パスキー登録ボタンまたはパスキー認証ボタンを設置します。

ボタンが押されると、既存サイト内に設置したバックエンドのエンドポイントを通じて、Push! PasskeyのAPIへ認証開始要求が送信されます。

APIキーなどの機密情報は、JavaScriptやHTMLには記載せず、既存サイトのバックエンド側で管理します。

利用者とPush! Passkeyの間でパスキー処理を行う

登録または認証処理が開始されると、利用者はPush! Passkeyの認証画面へ遷移します。

その後、利用者のブラウザ、OS、Authenticatorと、Push! Passkeyの認証基盤との間でWebAuthn処理が行われます。

パスキー登録の場合は、端末側で公開鍵と秘密鍵の組み合わせが作成されます。

秘密鍵は利用者側の端末やパスキー管理環境で保護され、Push! Passkey側には公開鍵とCredential情報が保存されます。

パスキー認証の場合は、Push! Passkeyが発行したChallengeに対して、利用者の端末が秘密鍵で署名します。

Push! Passkeyは、登録済みの公開鍵を使って署名を検証します。

既存サイトへ認証結果を返す

登録または認証が完了すると、Push! Passkeyは処理結果を既存サイトへ連携します。

既存サイトは、その結果を確認して、あらかじめ指定した成功画面へ利用者を遷移させます。

パスキー認証成功後に自社サイトのログイン状態を作る場合は、既存サイト側のバックエンドでログインセッションを発行します。

登録処理の基本フロー

利用者が既存サイトへログインする
既存サイトがパスキー登録を許可するユーザーを特定する
利用者が「パスキー登録」ボタンを押す
既存サイトのバックエンドからPush! Passkeyへ登録開始を要求する
Push! Passkeyが登録用Challengeを発行する
利用者の端末でパスキーを作成する
Push! Passkeyが登録結果を検証する
公開鍵とCredential情報を保存する
登録結果を既存サイトへ返す
既存サイトが登録完了画面を表示する

認証処理の基本フロー

利用者が既存サイトの「パスキー認証」ボタンを押す
既存サイトのバックエンドからPush! Passkeyへ認証開始を要求する
Push! Passkeyが認証用Challengeを発行する
利用者の端末で顔認証、指紋認証、PINなどを行う
端末内の秘密鍵でChallengeへ署名する
Push! Passkeyが登録済み公開鍵で署名を検証する
認証結果を既存サイトへ返す
既存サイトが自社のログインセッションを発行する
利用者をログイン後の画面へ遷移させる

秘密鍵や生体情報は既存サイトへ送られない

パスキー認証時に、秘密鍵そのものがPush! Passkeyや既存サイトへ送信されることはありません。

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

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

Push! Passkeyが受け取るのは、秘密鍵によって作成された署名などのWebAuthn認証結果です。

左に顧客サイト、中央にPush! Passkey認証基盤、右に利用者端末を配置する。顧客サイトには登録・認証ボタンとバックエンドエンドポイント、中央にはChallenge、Credential DB、署名検証、右には顔・指紋・PINと秘密鍵を配置する。顧客サイトから認証開始要求を送り、認証結果だけを受け取る流れを矢印で示す。横長ワイド画像

5. 実装までの手順

1. Push! Passkeyの利用を申し込む

最初に、Push! Passkeyの利用を申し込みます。

利用予定のWebサイト、現在のログイン方式、パスキーを利用する画面、ユーザー識別方法などを確認し、接続方法を整理します。

複数のWebサイトで利用する場合は、サイトごとの管理方法も事前に確認します。

2. 管理サイトのアカウント情報を受け取る

利用開始の準備が完了すると、Push! Passkey管理サイトへログインするためのアカウント情報が発行されます。

管理サイトでは、API接続に必要な情報や、登録済みサイトの設定を確認できます。

3. 管理サイトでAPI接続情報を取得する

管理サイトへログインし、利用するWebサイトに対応したAPIキーを取得します。

APIキーは、Push! Passkeyを利用する事業者とWebサイトを識別するための重要な情報です。

APIキーをHTMLやJavaScriptへ直接記載してはいけません。

必ず、ブラウザから内容を確認できないバックエンド側の設定ファイルで管理します。

4. 開発言語に対応したサンプルコードをダウンロードする

Push! Passkeyでは、対応する開発環境向けのサンプルコードを提供します。

サンプルコードには、Push! Passkey APIとの通信、登録・認証処理の開始、結果確認、エラー処理などの基本的な実装が含まれます。

自社の開発環境に合わせて、必要なファイルをダウンロードします。

5. バックエンド側へ接続ファイルを設置する

使用する言語やフレームワークに合わせて、次の役割を持つ構成要素を既存サイトへ実装します。

サーバー側設定

Push! Passkeyへの接続情報を設定するファイルです。

主に次の情報を設定します。

Push! Passkey認証基盤のURL
管理サイトで発行されたAPIキー
既存サイト側のユーザー識別子
API通信のタイムアウト時間

ユーザー識別子には、既存サイトでログイン中のユーザーID、UUID、または外部へ連携しても問題のない識別値を設定します。

APIキーは機密情報であるため、フロントエンドへ出力しないでください。

可能な場合は、ドキュメントルート外への配置や、環境変数による管理を推奨します。

バックエンドエンドポイント

フロントエンドのボタン操作を受け付け、Push! Passkey APIと通信するためのファイルです。

Push! Passkeyから提供されるサンプルコードをベースとして設置します。

フロントエンドのJavaScriptからは、このバックエンドエンドポイントのURLを指定します。

6. JavaScriptを読み込む

パスキー登録・認証ボタンを設置するHTMLのheadタグ内などで、Push! PasskeyのJavaScriptを読み込みます。

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

このJavaScriptが、対象ボタンのクリックを検知し、既存サイトのバックエンドエンドポイントを通じてPush! Passkeyの処理を開始します。

7. パスキー登録ボタンを設置する

パスキー登録ボタンを表示したい場所へ、次のようなHTMLを記述します。

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

各属性の役割は次のとおりです。

属性	役割
data-pushpasskey	実行する処理の種類を指定する。パスキー登録の場合は`regist`を指定する
data-endpoint	既存サイト内に設置したバックエンドのエンドポイントを指定する
data-success-url	パスキー登録が正常に完了した後の遷移先URLを指定する

8. パスキー認証ボタンを設置する

パスキー認証ボタンを表示したい場所へ、次のようなHTMLを記述します。

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

パスキー認証の場合は、data-pushpasskeyへauthを指定します。

data-success-urlには、認証成功後に表示する画面を指定します。

実際の会員サイトでログイン状態を作成する場合は、画面を表示するだけでなく、バックエンド側で認証結果を確認し、自社のログインセッションを安全に発行する処理が必要です。

9. 登録・認証成功後の画面を用意する

サンプルには、次のような成功後画面が含まれます。

regist_ok.html：パスキー登録成功後の画面
auth_ok.html：パスキー認証成功後の画面

実運用では、自社サイトのデザインと処理フローに合わせて変更します。

例えば、次のような画面へ遷移できます。

パスキー登録完了画面
マイページ
ログイン後トップページ
重要操作の実行確認画面
パスキー設定一覧画面

10. テスト環境で動作確認する

本番導入前に、次の項目を確認します。

パスキー登録ボタンから処理を開始できるか
登録済みパスキーで認証できるか
登録・認証成功後に正しい画面へ遷移するか
キャンセル時に適切な案内が表示されるか
タイムアウト時にエラー処理が行われるか
未登録ユーザーが認証した場合の処理
同じユーザーが複数端末で登録した場合の処理
スマートフォンとパソコンでの動作
主要なOSとブラウザでの動作
APIキーがフロントエンドへ表示されていないか
認証成功前にログインセッションが発行されていないか

最小構成は、JavaScript、ボタン、バックエンド接続ファイル

実装領域	必要な対応
フロントエンド	Push! PasskeyのJavaScriptを読み込み、登録・認証ボタンを設置する
バックエンド	APIキーをサーバー側で安全に保持し、顧客サイトのバックエンドエンドポイントを実装する
認証後処理	認証結果に応じて自社のログインセッションや画面遷移を処理する

これにより、既存サイトへパスキー登録とパスキー認証の導線を追加できます。

導入手順を横方向に6段階で示す。利用申し込み、管理サイトログイン、APIキー取得、バックエンドファイル設置、JavaScriptとボタン設置、動作確認の順にアイコンで表現する。コードは短い記号表現にとどめ、文章は最小限にする。横長ワイド画像

6. 管理サイトの紹介

Webサイトごとの接続情報を管理する

Push! Passkeyの管理サイトでは、サービスを利用するWebサイトの情報を管理します。

複数のWebサイトを運営している場合も、それぞれの接続設定を管理サイト上で確認できます。

WebサイトごとにAPI接続情報を分けることで、どのサイトから実行された登録・認証処理なのかを識別できます。

APIキーを発行・管理する

Push! Passkey APIを利用するためのAPIキーを管理サイトで確認します。

APIキーは外部へ公開せず、既存サイトのバックエンド側で安全に管理します。

APIキーの取り扱いについては、次の点に注意してください。

HTMLへ直接記載しない
JavaScriptへ直接記載しない
Gitなどの公開リポジトリへ登録しない
エラーメッセージやアクセスログへ不用意に出力しない
開発環境と本番環境で適切に分離する
不要になったAPIキーを継続利用しない

トランザクション情報を確認する

管理サイトでは、Push! Passkeyで実行された登録・認証処理の履歴を確認できます。

トランザクション情報を確認することで、導入後の利用状況やエラー発生状況を把握できます。

確認対象となる情報には、次のような項目があります。

登録または認証の種別
処理の受付日時
処理の完了日時
対象となるWebサイト
既存サイトから連携されたユーザー識別子
処理結果
成功・失敗の状態
エラーコード
認証処理を識別するリクエスト情報

これにより、どのWebサイトで、どれだけパスキーが利用されているかを確認できます。

ユーザーとパスキーの利用状況を確認する

管理サイトでは、Push! Passkeyを利用するユーザーや、登録されたパスキーに関する情報を確認できます。

運用上必要な範囲で、次のような確認を行います。

パスキーが登録されているか
複数のパスキーが登録されているか
最後に利用された時刻
登録または認証処理の履歴
利用停止や無効化の状態

具体的に表示される項目や操作可能な範囲は、契約内容や管理権限によって異なる場合があります。

複数の管理ユーザーに対応

事業者内で複数の担当者がPush! Passkeyを管理する場合に備え、管理ユーザーを登録できます。

運用担当者、開発担当者、管理責任者など、社内体制に合わせて管理します。

管理サイト自体へのログインについても、安全な認証方法を用いて保護します。

詳細は管理操作マニュアルで確認

管理サイトの具体的な操作方法については、Push! Passkey管理操作マニュアルで解説します。

管理操作マニュアルでは、主に次の内容を案内します。

管理サイトへのログイン
Webサイト情報の登録・確認
APIキーの確認
管理ユーザーの登録・編集
利用者情報の確認
トランザクション履歴の確認
エラー発生時の確認方法
アカウント情報の変更
セキュリティ上の注意事項

管理サイトのダッシュボードをイメージした法人向け画面。左側にWebサイト一覧と管理メニュー、中央に登録・認証件数のカード、下部に日時、サイト名、処理種別、結果を並べたトランザクション一覧を配置する。実在する個人情報やAPIキーは表示しない。横長ワイド画像

まとめ

既存システムを維持しながら、パスキー認証部分を外部化する

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

自社でパスキーを直接実装する場合は、WebAuthn APIの呼び出しだけでなく、Challenge管理、登録結果の検証、署名検証、Credential DB、複数端末対応、ログ、復旧、互換性確認など、幅広い開発と運用が必要です。

Push! Passkeyを利用すると、これらのパスキー認証基盤をジンテック側へ切り出すことができます。

既存サイト側で必要となる基本構成は、次のとおりです。

Push! PasskeyのJavaScriptを読み込む
パスキー登録・認証ボタンを設置する
APIキーを設定したバックエンドファイルを設置する
自社ユーザー識別子を連携する
認証結果を確認する
認証成功後に自社のログインセッションを発行する

既存のユーザーDBや業務システムを大きく変更するのではなく、パスキー登録・認証部分を外部サービスとして接続する構成です。

自社に残す機能と、外部化する機能を分けて考える

Push! Passkeyがパスキー認証に成功した場合でも、利用者の契約状態、権限、利用停止状態、ログイン後に利用できる機能は、既存サイト側で判断します。

Push! Passkeyはパスキーによる本人認証を担当し、既存サイトは自社サービスのユーザー管理と権限管理を担当します。

この責任分担により、既存システムの構成を維持しながら、パスキー認証の専門的な処理だけを外部化できます。

導入前の設計から相談できます

パスキーは、登録ボタンを設置するだけで運用設計まで自動的に完成するものではありません。

安全に導入するためには、登録を許可する条件、ユーザー識別子の連携、認証成功後のセッション発行、端末紛失時の復旧方法などを事前に整理する必要があります。

Push! Passkeyでは、現在のログイン方式やシステム構成を確認したうえで、導入方法の設計相談に対応します。

まずは既存サイトの一部画面や限定ユーザーから導入し、段階的にパスキーの利用範囲を広げることも可能です。