パスキー認証とは?概要とOkta CICを活用するメリットを解説!
はじめに
様々なWebサービスへのログイン認証方式として、パスワード認証が広く使用されています。Yahoo Japan社による調査(2020年)によると、約76%の人が、サービスへのログインにパスワードを使用していると回答しています。
しかし、パスワード認証には、セキュリティやユーザビリティの観点で様々な課題があるため、昨今ではパスワードレス認証の提供が増えつつあります。
Okta CIC(Auth0)は、これまで以下のパスワードレス認証に対応してきました。
- WebAuthnベースの生体認証
- ワンタイムパスコード認証(OTP)
- マジックリンク認証
そして、2024年1月の機能アップデートで、Okta CICは新たにパスキー認証(Synced passkey)に対応しました。
本ページでは、以下をご紹介します。
- パスキー認証の流れ
- パスキー認証の仕様
- パスキー認証実現のために必要な機能
- Okta CICを使ってパスキー認証を実現するメリット
パスキー認証(Synced passkey)とは
パスキー認証の流れ
パスキー認証でのWebサービスへのログイン操作は、ユーザ側から見ると以下のような流れとなります。
- Webサービスにアクセス
- 生体認証やPIN入力による認証を実施
- Webサービスへのログイン成功
パスキー認証は、公開鍵暗号方式及びチャレンジレスポンス認証を用いたパスワードレス認証として、FIDO Allianceによる標準化規格であるFIDO認証に含まれます。公開鍵暗号方式は、初回パスキー登録処理の中で、公開鍵をWebサービス側に保管し、秘密鍵をユーザの端末側に保管します。認証処理においては、ユーザの本人確認を行うため、サービス提供者側が発行したチャレンジに対して、ユーザが署名を行う際に秘密鍵を使用します。そして、サービス提供者側において、ユーザ側から返却されたチャレンジの正当性を判断するために、公開鍵を使用します。
パスキー認証処理の流れは、以下の通りです。
- Webサービス:ユーザ側からログイン要求を受ける
- Webサービス:今回のフローでのみ有効なチャレンジを生成し、ユーザのデバイス側に対し、チャレンジに対する署名を要求
- ユーザのデバイス:ユーザに対し、本人確認を要求
- ユーザ:生体認証やPIN入力による認証を実施
- ユーザのデバイス:端末に登録済の秘密鍵で署名を実施し、Webサービス側にチャレンジを返却
- Webサービス:返却されたチャレンジ値と②で生成したチャレンジ値を、登録済みの公開鍵を使用して検証を実施。検証成功すれば、ログイン処理完了
パスキー認証は、パスワード認証と比較してユーザ側・サービス提供側の観点で、以下のメリットがあります。
- 端末の生体認証やPIN入力を用いて認証を行うため、スマートフォンのロック解除と同様の操作でサービスにログインできる
→ユーザ側:利用するサービスの認証のために、新たにパスワード等の認証情報を用意する必要がない - 秘密情報(秘密鍵)をユーザ側でのみ保管するため、ユーザ側とサービス提供側との間で秘密情報の共有が不要。サービス提供側から公開鍵が流出してしまっても、ユーザ側から秘密情報が流出しない限り、認証は成功しない
→サービス提供側:パスワード認証と比較して、セキュリティ強度の高い認証基盤を実現
パスキー認証は、秘密鍵の保管方法の違いにより、Device-bound passkeyとSynced passkeyの2つの仕様に区分されています。
これまで、Okta CICでは、Device-bound passkeyのみに対応していましたが、2024年1月のアップデートにより、新たにSynced passkeyに対応しました。
パスキー認証の仕様
- Device-bound passkey
Device-bound passkeyは、単一の端末内でのみ、秘密鍵が保持される仕様です。そのため、端末外にパスキー情報が洩れることはありません。一方で、登録済端末の紛失時や交換時には、再度パスキー登録が必要となります。
- Synced passkey
Synced passkeyは、複数の端末間で、パスキー情報の同期できる仕様です。Apple, Google等のプラットフォームにおけるアカウントに紐づく形で同期ができ、各プラットフォームのクラウド上に秘密鍵が保管されます。- Apple (iOS/iPadOS/macOS):iCloudキーチェーンによる同期
- Google (Android):Google Password Managerによる同期
各プラットフォームが提供しているOS端末を利用する必要がありますが、同じプラットフォームのOS端末であれば、複数の端末同士で秘密鍵共有ができるため、端末紛失時や交換時においても、継続して登録済のパスキーを利用できます。
上記2つの仕様に加えて、Cross-device Authenticationという仕様があります。
- Cross-device Authentication (Hybrid)
Cross-device Authentication(Hybrid)は、パスキー非対応の端末からWebサービスへログインする際に、パスキー認証に対応した別端末を利用してパスキー認証を実現する仕様です。
Cross-device Authenticationの仕組みを悪用して本人以外がWebサービスへログインすることを防ぐため、Webサービスへのログインを試行する端末と、パスキー認証に利用する端末とが、Bluetoothによるペアリング通信を行う事を前提とし、両者が近距離にあることを制約事項としています。
パスキー認証実現のために必要な機能
ユーザのパスキー認証を実現するために、Webサービス側では、主に以下の機能が必要です。
- ユーザ向け機能
- パスキー登録/認証処理機能
- 画面機能
・パスキー登録画面
・パスキー認証画面
・パスキー認証移行提案画面
- 登録パスキーの管理機能
・登録済パスキー/端末の閲覧
・登録済パスキー/端末の削除
- 管理者向け機能
- アプリケーションやユーザ単位等でのパスキー認証利用選択機能
- 登録パスキーの管理機能
・ユーザがパスキー登録済みの端末の閲覧
・ユーザがパスキー登録済みの端末の削除
・ユーザのパスキー認証利用日の閲覧
Okta CICを使ってパスキー認証を実現するメリット
Okta CICでは、以下のパスキー認証に関連する機能が提供されています。
- ユーザ向け機能
- パスキー登録/認証処理機能
- 画面機能
・パスキー登録画面
・パスキー認証画面
・パスキー認証移行提案画面
- 管理者向け機能
- 連携アプリケーション毎のパスキー認証利用選択機能
- 登録パスキーの管理機能
・ユーザがパスキー登録済みの端末の閲覧
・ユーザがパスキー登録済みの端末の削除
・ユーザのパスキー認証最終利用日の閲覧
Webサービス側では、「パスキー認証実現のために必要な機能」で記載した機能が必要ですが、Okta CICを利用することで、当該機能を一から実装する必要がなくなります。結果として、パスキー認証導入に伴う開発負担を減らすことができます。
また、Okta CICでは、既存ユーザに対してパスキー認証への移行を促すための画面提示も可能です。
なお、上記以外の機能は、Okta CICでは提供されていないため、ユーザ自身によるパスキー管理機能等は、Webサービス側で実装する必要があります。
おわりに
本ページでは、パスキー認証の流れと仕様、実現のために必要な機能やOkta CIC活用のメリットをご紹介しました。
今後、Okta CICでのパスキー認証実現方法についての記事も作成予定です。
Okta CICでのパスキー認証実現方法についてご興味のある方は、記事が公開されるまでお待ちいただければ幸いです。
参考
- Passkeys - Auth0 docs
- FIDO2 - FIDO Alliance
- Cross-Device Authentication:Terms/ | passkeys.dev
- Device-bound passkey:Terms | passkeys.dev
- Synced passkey:Terms | passkeys.dev
お問い合わせ・資料請求
株式会社マクニカ Okta 担当
- TEL:045-476-2010
- E-mail:okta@macnica.co.jp
平日 9:00~17:00