パスキーについて

パスキーについて

セキュリティをアップグレードしましょう：アカウントセキュリティを大幅に強化しながら、ユーザにすばやく簡単なサインインエクスペリエンスをもたらすパスキーのサポートを追加する方法を紹介します。パスキーは、フィッシング攻撃を排除するために構築された、シンプルで強力なクレデンシャルです。パスキーが、どのようにセキュリティを考慮して設計されているかをはじめ、パスキーの使用方法、ログインフローにパスキーを統合する方法、この機能を取り入れる際に必要なプラットフォームやWeb APIについて解説します。

リソース
関連ビデオ

WWDC23
- 組織におけるパスキーの導入
- Webアプリの新機能
WWDC22
WWDC20
- ユニバーサルリンクの新機能
ダウンロード

♪ メローなインストヒップホップ ♪ ♪ こんにちは Garrettです Authentication Experienceチームのエンジニアですこのビデオでは次世代認証技術であるパスキーについてお話させていただきますしかしその前に現在の認証技術であるパスワードについてお話しする必要がありますパスワードでほぼすべての AppやWebサイトにサインインしていることでしょうパスワードは安全に使うのが本当に難しいですすべてのアカウントに安全でユニークなパスワードを作成する必要があることは誰もが知っていますが実際に実行している人はそれほど多くはありません AppやWebサイトを設計する際アカウントの安全性を保つ事と優れたユーザー体験を設計することは常にトレードオフの関係にあると言えますまたAppやWebサイトがすべて正しく動作していてもフィッシングやパスワードの再利用などの問題によりアカウントの漏洩につながる可能性があります macOS MontereyとiOS15ではそのソリューションであるパスキーの開発者向けプレビューを発表し非常に多くの素晴らしいフィードバックを頂きました macOS Venturaと iOS16ではパスキーを誰もが使えるようにすることが可能になります今が採用のチャンスですパスキーはパスワードよりもユーザー体験が優れているだけでなく脆弱なクレデンシャルやクレデンシャルの再利用クレデンシャルのリークやフィッシングなどセキュリティ問題が全カテゴリにおいて改善されますしかもとても使いやすくなりましたお見せしましょうまずは私たちお気に入りのデモApp「Shiny」からこのAppは1日1枚かわいい写真を見ることができパスワードによる典型的なサインインフローを採用していますユーザー名のフィールドをタップすると私のアカウントの自動入力候補が表示されます選択しサインインしますそしてパスワードを入力できます
そしてワンタイムコードが書かれたSMSメッセージが届くまで少し待ちます
来ましたこれでサインインできましたいくつかのステップが必要でしたが AutoFillとパスワードマネージャーの助けを借りてなんとかたどり着けました
サインインできたのでこのアカウントにパスキーを追加してみます「アカウント管理」「パスキーの追加」ここでパスキーを作成の為のシステムシートが表示され続行できました数回のタップで私のデバイスはアカウント用にユニークで暗号的に強力なキー・ペアを生成しそれをiCloud キーチェーンに保存します macOS Venturaと iOS16を搭載したすべてのデバイスで同期して機能します
ではパスキーができたのでその使い方を紹介しましょうサインアウトします先ほどと同じサインインフォームに戻ります前回と同様にユーザー名フィールドにフォーカスを当てます現在私のアカウントにパスキーが保存されており QuickTypeバーに表示されますタップするだけでサインインできますワンステップですパスキーを保存する際新しいパスワードを考えたり複雑な条件を満たそうとしたりする必要はありませんでした各パスキーはシステムによって生成され強度が保証されており 1つのアカウントにのみ使用されますそれでサインインするときは慣れ親しんだ既存のサインインフローで表示できワンタップで使えるようになっていますそして正しいAppや Webサイトでしか使わせないようシステムが配慮し強力なフィッシング対策が組み込まれていますもちろんパスキーは Web上でも有効ですここではSafariでシャイニーの Webサイトを表示しています携帯電話と同じようにユーザー名フィールドにフォーカスすると iCloudキーチェーンのおかげで私のパスキーが既にそこにありすぐ使えるようになっています Touch IDだけでサインインできるんですそれだけです Appleのパスキー実装はオープンスタンダードをベースに構築されています私たちはFIDO アライアンス内の他のプラットフォームベンダと協力しパスキーの実装がクロスプラットフォームで互換性を持ちできるだけ多くのデバイスで動作するように努めていますアカウントをパスキーにアップグレードしても友人のPCからサインインできますもちろん友人のPCはローカルにパスキーが保存されていませんがここで自分のユーザー名を入力することができますサインインを押すと iPhoneを使うためのオプションが表示されたシートが現れますするとQRコードが表示されるのでスキャンします
iPhoneがこのQRコードはパスキーを使ってサインインするためのものだと認識するのでこのオプションを選択すると iPhoneとブラウザがセキュアに接続されますこれで「続ける」だけでサインインできましたこのクロスプラットフォームのサインイン体験はパスキーの背後にある標準の一部でありファーストクラスのシステム機能です一見とてもシンプルに見えますがこれは単なる QRコードではありません裏では各デバイスがローカルなキーの照合を行い近接性を確認しますエンドツーエンドで暗号化された通信路を確立し簡単な方法でサインインできるようにしながらパスキーの持つ強力なフィッシング耐性を維持しますどのデバイスからでも自分のアカウントに安全にサインインできるのは素晴らしいことですまたパスワードの置き換えに重要な機能として 2人以上の間でアカウントを共有できることが挙げられますパスキーは AirDropで共有することができます
私とパートナーが共有しているShinyのアカウントはすでにパスキーを使用するようにアップグレードしていますパスキーの場合クレデンシャルは入力できるものではありませんがそれでも信頼できる人と共有することができます iPhoneでアカウントの詳細を開いてみます
以下はパスワードとパスキーの両方を使用している私のすべてのアカウントです共有アカウントをタップして詳細を確認することができますここでは保存したパスキーに関する情報を取得したりこのアカウントにメモを追加できますパスキーの共有も可能ですパートナーのiPhoneがあります先にそれを選択しておきます
今私のパートナーもパスキーを使っています
パスキーはどこでも簡単に使えるということですパスキーの使い方は先ほど説明したとおりです次にパスキーとは何かそしてパスキーを使用する際のインターフェイスのガイドラインについて説明します次にAutoFillを利用し AppやWebサイトの既存のサインインフローにパスキーを統合する方法を紹介しさらにサインインプロセスを効率化するための追加オプションを紹介しますその後パスキーの仕組みについてもう少し技術的に詳しく説明し最後にパスキーと多要素認証について説明しますまずはパスキーのデザインについてですパスキーについて説明する前の前提として第一にパスキーはパスワードの代わりとなるものですより速くサインインできより使いやすくそしてより安全です AppやWebサイトでのパスキーの参照方法についていくつかのガイドラインをご紹介しますパスキーはユーザーが目にする一般的な用語ですこのビデオはAppleの実装に焦点を当てていますが先ほど紹介したように他の主要なプラットフォームでもすでにパスキーの独自サポートの構築が始まっています「パスキー」は「パスワード」と同じように普通名詞でもあります英語では小文字で "password "のように複数形になることを意味します私のアカウントにはパスキーがあり設定からパスキーのあるアカウントを表示できます Appleのプラットフォームでは SF Symbolsの person.key.badgeと .fillのバリアントも使用できシステムと一致したアイコンを提供することが可能です AppやWebサイトでパスキーを提供する場合新しいインターフェイスをデザインする必要はありませんユーザー名フィールドはほとんどのAppやWebサイトのサインインの中心的なポイントです多くの人がその使い方を知っておりすでに多くのAppやWebサイトがアカウントごとにサインイン体験をカスタマイズするために活用していますユーザー名フィールドにはもう一つ大きな特徴がありますパスキーはサインインの仕組みに新しいパラダイムをもたらしますがパスワードからの移行もスムーズで簡単であることが必要です AutoFillを使用したパスキーはファーストクラスの機能として既存のサインインフローにそのまま組み込むことができます AutoFillでパスキーを提示するのが主な使用方法ですしかしより高度な使い方のために Appleのプラットフォームではパスキーによるサインインのための幅広い追加UIオプションも用意されていますここではパスキーの使用方法とAutoFillでの提示方法について説明しますパスキーはWebAuthentication またはWebAuthn標準に基づいて構築され公開鍵暗号を使用します入力可能な単語や文字列を持つのではなくアカウントごとにユニークな暗号キーペアを生成しますパスキーサインインを行うにはサーバのバックエンドに WebAuthnを採用する必要があります標準的なWebAuthn サーバの実装であればパスキーで動作するはずです Appleプラットフォーム上の AppではパスキーはAuthenticationServices フレームワークの ASAuthorization API ファミリーに含まれますこれはパスワードセキュリティキー Appleでサインインなどあらゆる種類のクレデンシャルを扱うためのAPIですまたこのAPIをより柔軟にし既存のサインインフローにシームレスに適合させるために AutoFillサポートなど使用できるいくつかの新メソッドを追加しています Appでパスキーを使い始めるにはまずwebcredentialsのサービスを使用して関連するドメインをセットアップする必要がありますその詳細はビデオ「Introducing Password AutoFill for Apps」と「ユニバーサルリンクの新機能」でご確認いただけます Appのインターフェイスでユーザー名フィールドが usernameのtextContentTypeを使用していることを確認しますこれによりシステムはパスキーの提案を行う場所を把握できますこれが設定されるとAutoFillによるパスキーのリクエストをスタートするために必要なコードは次のようになります分解してみるとステップはシンプルです他のWebAuthn リクエストと同様にまずサーバからチャレンジを取得する必要があります次にプロバイダとリクエストを作成します ASAuthorizationPlatform PublicKeyCredentialProviderはパスキーリクエストを扱うための ASAuthorizationProviderです WebAuthn的にはアサーションはサインイン時に使うものなのでここでは既存のパスキーでサインインするためのアサーションリクエストを作成しています ASAuthorizationControllerは実際にリクエストを処理するためのものですパスキーリクエストのインスタンスを生成しそのデリゲートと presentationContext Providerを設定しますそして最後にperformAutoFill AssistedRequestsを呼び出してリクエストを開始しますこのリクエストがAppで実行されている間ユーザー名フィールドがフォーカスされるたびにシステムは QuickTypeバーに利用可能なパスキーを提供しますキーボードが表示された時にパスキーの準備ができるようにユーザー名フィールドがフォーカスされる前にビューライフタイム内の早い段階でリクエストを開始するようにしてください QuickTypeバーから項目を選択すると Face IDが呼び出され ASAuthorizationController Delegateコールバックを受け取ってサインインが完了しますテキストフィールドに実際に入力されるものは何もありません任意のクレデンシャルタイプで認証が成功すると didCompleteWithAuthorization コールバックを受け取ります最初にやることは受け取ったクレデンシャルの種類を確認することですパスキーサインインの場合は ASAuthorizationPlatformPublicKey CredentialAssertionが使用されますアサーションオブジェクトにはバックエンドでサインインを検証するために必要なフィールドが含まれます値を読み込みその値をサーバで確認しサインインを完了させる必要があります AutoFillアシストによるパスキーリクエストは強力ですこの小さなコード変更で Appのサインインフローが柔軟になりましたもちろんQuickTypeバーからパスキーの提案を選択しそのパスキーで素早くサインインすることがプライマリのケースとなりますこれが一番多いと思ってください他にも選択肢はあります先ほど紹介したコードでも追加の変更なしで近くのデバイスからパスキーによるサインインが可能です鍵のアイコンをタップすると利用可能なすべてのパスキーとパスワードの一覧が表示され近くのデバイスでサインインするオプションが表示されますするとデバイスをまたいだサインインが可能になりますどちらの場合もパスキーが使われていれば同じASAuthorization ControllerDelegateのコールバックを受け取りますこれをサポートするために必要なことは特にありませんもしユーザーがまだ多くのパスキーを持っていないなら慣れたようにログインフォームを使用することもできますパスワードは QuickTypeバーで提案されフィールドに入力することもできますパスワードのアイテムが選択されるとクレデンシャルはテキストフィールドに入力され実行中のリクエストをキャンセルできますこのAPIは既存のサインインフローに持ち込むことでユーザーが簡単にサインインできるように設計されていますすでにパスキーの使用にアップグレードした人が AutoFillの提案を使用せずにユーザー名を入力することにした場合は AutoFillのリクエストをキャンセルして ASAuthorizationControllerを使用してモーダルパスキーサインインシートを表示する必要がありますここからはやはりシングルタップで同じASAuthorization ControllerDelegateのコールバックを受け取ります以下は以前のコードですこれをAutoFillリクエストからモーダルリクエストに切替えるにはこのperformAutoFillAssisted Requestsメソッドコールを performRequests()コールに置き換えるだけですこれにより利用可能なすべてのパスキーと近くのデバイスのパスキーを使用するオプションがモーダルシートで表示されますパスキーに対応するために Appで必要なコードの変更はこれだけですまたWebプラットフォームは AutoFillアシストとモーダルパスキーの両方のリクエストに対応しています Web上ではセキュリティキーにも使用される標準的なWebAuthn APIを介してパスキーが使用されます Appと同じように AutoFillアシストのリクエストを採用することでTouch IDだけで素早くサインインし利用可能なすべてのパスキーとパスワードを取得したり近くのデバイスからパスキーを使用したりわずかなコードですべて行うことができますまず最初にWebページのユーザー名フィールドに usernameとwebauthnの両方のオートコンプリート詳細トークンを注釈してパスワードとパスキーの両方の候補が正しい場所に表示されるようにしてくださいこれが完了したら JavaScriptで典型的な WebAuthnのサインインを行います WebAuthnではAutoFill スタイルのリクエストは条件付き仲介を使用して呼び出されますまずは標準的なJavaScriptの機能検出を利用して利用可能かどうかを確認することから始める必要がありますそうであればそのままリクエストしてくださいネイティブAPIと同様にサーバから取得したchallengeを使用してリクエストを行うことから始めます AutoFillアシストのリクエストにするには medationを追加します「conditional」パラメータをオプションに追加ください次にnavigator.credentials.getを使用しリクエストを開始します .getコールは promiseを返します解決した場合はアサーションオブジェクトを受け取りそれをサーバに送り返して検証しサインインを完了させることができます Appのように誰かが手動でパスキーを使ってアカウントのユーザー名を入力した場合 APIを使ってモーダルサインインシートを提示する必要がありますモーダルリクエストに切り替えるために必要なのは conditionalパラメーターを削除するだけです WebAuthnを使用する際の注意点として Appleのプラットフォームがユーザー認証（UV）をどのように扱うかが挙げられます UVはWebAuthnレスポンスのブール値フィールドで認証機関が現在のユーザーがデバイスの所有者であることを確認しようとしたかどうかを示します Appleのデバイスでは値が1の場合生体認証またはパスワードやパスコードが使用されたことを示します Appleのプラットフォームでは生体認証が利用できるようになると必ずパスキーのためのUVを要求するようになるのでその心配はありません WebAuthnリクエストの際にユーザー認証の要件を指定するオプションがありますデフォルトはuserVerification：「preferred 」生体認証のないデバイスで悪い経験をさせないために常にデフォルト値を使用します Web上でパスキーを使用する際の注意点をいくつかご紹介します AutoFillアシストのリクエストを行う場合は Appと同じようにページライフタイムの早い段階で行う必要がありますモーダルなWebAuthnリクエストの場合ボタンのクリックなどユーザーのジェスチャイベントをトリガにする必要がありますモーダルリクエストはユーザージェスチャイベント以外のページ読み込み時に1回だけ起動できますがそうすると WebKitがそのページでの後続の呼出しを制限する場合があります AutoFillのリクエストはモーダルではないのでユーザーのジェスチャを必要とせずタイムアウトもかなり長くなります最後にパスキーは Safariのレガシーであるプラットフォーム認証に取って代わります既存のクレデンシャルは引き続き機能し作成されたデバイスにバインドされますが新しいプラットフォームのクレデンシャルはパスキーとして作成されますパスキーは証明書を提供しないので登録時にレガシークレデンシャルと区別することができますこれがパスキーと AutoFillです次はサインインをさらに効率化するためのプラットフォーム機能について説明します ASAuthorization APIは AutoFillによるサインインに加えさらに多くの便利な機能を提供します今回はAPIの追加機能を 3つ取り上げどのような場合に使えるのかを紹介しますパスキー許可リストを始めとしてユーザー名入力後にパスキーシートをモーダルに表示する場合端末に複数のアカウントのパスキーが保存されている可能性がありますデフォルトでは利用可能な全パスキーがシートに表示されますまたパスキー許可リストを使用するとシートに表示されるパスキーを制限し一致するアカウントのみが提供されるようにすることができますモーダルリクエストに許可リストを追加するにはまずユーザー名が必要ですそのユーザー名を使って一致するクレデンシャルIDのリストを取得しそれを許可リストにすることができますクレデンシャルIDはパスキーの一意な識別子です WebAuthnサーバは与えられたユーザー名のクレデンシャル IDを検索する方法を持つ必要がありますここからは同じようにリクエストを進めてください今私の端末には3つの Shinyアカウントがありパスキーを使っていますがシートには私が使おうとしている 1つのアカウントしか表示されませんモーダルリクエストを行う場合ユーザーがどのアカウントでサインインしようとしているのか例えばユーザー名をすでに入力している場合など追加コンテキストがある時は許可リストを使用する必要があります次は現在のデバイスに保存されたパスキーがない場合モーダルパスキーリクエストを行うとどうなるかを説明しますこれは許可リストを使用し保存されたパスキーのどれもがそのリストに一致しない場合にも適用されますデフォルトではモーダルパスキーのリクエストを行った際一致するパスキーがない場合はモーダルシートを表示し近くのデバイスからパスキーでサインインするための QRコードを即座に表示するようになっていますこれはサインイン時に最も柔軟性がありパスキーが使用を把握している場合に最適なオプションですしかしAPIに新しいオプションがありすぐに利用できる信用証明書を優先しそれがない場合はデリゲートコールバックにサイレントでフォールバックしますこれを使用して可能な場合従来のサインインフォームを表示する前に既存のクレデンシャルを迅速に提供することができますデフォルトのオプションを使用したこのモーダルリクエストは現在のデバイスに一致するパスキーがない場合 QRコードの表示にフォールバックします preferImmediatelyAvailableCredentials オプションを使用すると QRコードを取得する代わりにエラー付きのデリゲートコールバックを受け取りますキャンセルされたコードで ASAuthorizationErrorを受け取った場合ユーザーがシートを見て手動で解除したか preferImmediately AvailableCredentialsを渡してすぐに利用できる資格情報がなかったかのどちらかであることを意味しますここからどうするかはこれを呼び出した側の文脈によります例えば通常のサインインフォームを表示する前にローカルの認証情報をテストする方法としてこのオプションを使用する場合ここでフォームを表示するきっかけとなりますデバイス上に少なくとも1つの一致するクレデンシャルがある場合使用されるオプションに関係なく完全なモーダルシートが表示されますまたAppのどこかでAutoFill アシストのリクエストまたはデフォルトのフォールバックによるモーダルリクエストを使用していることを確認し現在のデバイスにパスキーがない場合でも近くのデバイスでサインインするオプションに到達できるようにします ASAuthorization APIの最後の機能として複合クレデンシャルリクエストを行うことを説明しますこの例ではAppがパスキーパスワード Appleでのサインインを要求しています私の端末にはたまたま3つの異なるアカウントの認証情報が保存されていたのでここにすべて表示されていますしかしより可能性が高いのは 1つのアカウントしか持っていないことですその場合この同じ複合クレデンシャルリクエストではシート内の1つのアカウントしか提供されません既存のASAuthorization リクエストに追加のクレデンシャルタイプを追加するのは非常に簡単です追加のリクエストタイプに対応するプロバイダとリクエストを作成しそれらの新しいリクエストをコントローラに渡すだけですこれでモーダルシートはこれらのクレデンシャルタイプのいずれかから利用可能なクレデンシャルを提供しますどのクレデンシャルタイプを使用しても同じデリゲートコールバックを受け取ることができます受け取ったクレデンシャルの種類を確認しそのクレデンシャルの種類に応じたサインインを完了する必要があります ASAuthorization API ファミリのより高度な機能のいくつかをカバーしていますこれからパスキーの動作と安全性について技術的な詳細を説明します現在パスワードを入力してサインインする場合一般的に実際に行われているのはパスワード入力後にハッシュ化ソルティングを行い難読化した値をサーバに送信しサーバがそれを保存していますその後同じハッシュ化された値を生成できればそのアカウントに入ることができるこれはサーバがパスワードの派生物を保存する責任を負うことを意味し攻撃者にとって非常に価値のあるものですもしそれが手に入ればパスワードが分かりアカウントにアクセスできる可能性がありますしかしパスキーは全く違う仕組みになっていますパスキーは単一のタイプ可能な文字列ではなく実際には関連するキーのペアですこれらのキーはアカウントごとに安全かつ一意にデバイスによって生成されます 1つは公開されサーバに保存されもうひとつはサインインしても端末に残るプライベートなものですパブリックキーは秘密ではありませんユーザー名と同じように公開されますプライベートキーはサインインするために必要になりますプライベートキーはサーバが知ることはなくデバイスが安全に保管しますサインインしようとするとサーバはみなさんのデバイスに1回限りのチャレンジを送ります WebAuthnではさまざまなチャレンジレスポンスアルゴリズムが使用できますが Appleプラットフォームのパスキーは標準のES256 を使用しますユーザーのプライベートキーだけがアカウントのチャレンジに対する有効なソリューションを生成することができます端末は署名とも呼ばれるこのソリューションをローカルで生成しこのソリューションのみをサーバに送り返しますキーは端末にのみ保存され第三者に知られることはありませんその後サーバはパブリックキーを使ってソリューションを検証しますデバイスが提供したソリューションが有効であればサインイン完了ですパブリックキーはソリューションが有効かどうかチェックできますがソリューションそのものを生成することはできませんつまりサーバはプライベートキーの実態を知らなくてもみなさんが正しいプライベートキーを持っていることを確認することができるのですまたサーバはプライベートキーを知らないので攻撃者のターゲットとして価値が低いのですこの暗号とキーの保護はすべてデバイスによって完全に透過的に実行されますユーザーはそれを知ることも考えることもありませんユーザーにとってはパスキーは極めてシンプルでどこでも使えるものなのですまたパスキーはデバイス間でサインインする際にフィッシングに強いセキュアな方法で使用できますその仕組みはこうですここには2つデバイスがありますクライアントとはサインインするデバイスや Webブラウザのことで Authenticatorとは私のパスキーを持つデバイスのことですまずクライアントが QRコードを提示しそれをAuthenticatorが読み取りますこのQRコードには1回しか使えない暗号鍵のペアを暗号化したURLが含まれていますその後Authenticatorはネットワークリレーサーバのルーティング情報を含む Bluetoothアドバタイズを作成しますこのローカルエクスチェンジではサーバの選択とルーティング情報の共有が可能ですがさらに2つの機能を備えていますサーバには見えないキーの合意を行うのでネットワーク上を流れるものはすべてエンドツーエンドで暗号化されサーバはそれらを読むことができませんまたこの2つのデバイスが物理的に近接していることの強力なクレームを提供しますつまり電子メールで送信されたQRコードや偽のWebサイトで生成された QRコードは機能しません遠隔地の攻撃者は Bluetoothのアドバタイズを受信してローカルエクスチェンジを完了することができないためですそれがローカルな部分なんですねローカルエクスチェンジとキーの合意が行われると 2つのデバイスは iPhoneが選んだリレーサーバに接続しますそこから標準的な FIDO CTAP操作を行いますがこの操作は先ほどのキーを使って暗号化されているのでリレーサーバには何も見えません
この一連の処理はデバイスと Webブラウザによって行われますデバイス間の通信には Webサイトは一切関与していませんクロスデバイスクロスプラットフォームサインインはパスキーが使える場所であればどこでも使えるシステム機能です以上パスキーの仕組みとデバイス間でも強固なセキュリティ保証を実現する方法についてより技術的な観点から解説しました次は多要素認証です現在認証を考える際によく使われるのが「要素」という考え方です各要素によって得意不得意な攻撃が異なるため要素を組み合わせることでより優れたカバレッジが可能となりますでもパスキーを使えばもうそんなことは考えなくていいんです現在サインインによく使われる方法を紹介します頭の中にあるパスワードはかなりの確率で脆弱なものですパスワードマネージャーはユニークで高エントロピーの文字列を生成することに長けておりデバイスの盗難に対するローカルな保護機能を備えている場合があるほかフィッシングに関するいくつかのヒントを提供してくれます SMSやタイムベースのコードを追加することは状況によっては盗難やフィッシングの対策になりますが本当の意味での解決にはなりませんしかしパスキーの場合すべてデバイスが生成するユニークなキーペアです Appleのデバイスではローカルデバイスの保護という強力な基盤の上に構築されていますまたパスキーはフィッシングから人間の要素を完全に排除しますまたAppやWebサイトのサーバはプライベートキーを持っていないので漏えいすることはありませんパスワードベースのサインインフローに要素を追加することはパスワードだけよりも多くの種類の攻撃から保護することができるため理にかなっていると言えるでしょうしかしパスキーはそれだけで多くのことを防ぐことができるので追加要素を必要としませんパスワードのない未来が楽しみですねそれを実現するための方法をご紹介しますまず最初にサーバに WebAuthnを導入する必要がありますパスキーは標準的な WebAuthnサーバの実装であれば動作するはずですサーバの準備ができたらみなさんのAppやWebサイトに新しいAPIを導入してください AutoFillを利用したパスキーのリクエストは既存のサインインフローにそのまま追加することができますそして最後にユーザーをパスワードから解放することですパスキーはAppや Webサイトに安全にサインインするための利便性とセキュリティの問題を解決する業界標準のソリューションですパスワードではなくパスキーに誘導することで迅速で便利なサインインを体験してもらうと同時にすべての人のセキュリティレベルを向上させることができますご視聴ありがとうございます ♪

{
    "webcredentials": {
        "apps": [ "A1B2C3D4E5.com.example.Shiny" ]
    }
}

11:47 - Annotating user name text field

override func viewDidLoad() {
    super.viewDidLoad()
    //Additional setup…

    userNameField.textContentType = .username
}

11:59 - AutoFill-assisted passkey sign in

// AutoFill-assisted passkey request

func signIn() {
    let challenge: Data = … // Fetched from server
    let provider =
        ASAuthorizationPlatformPublicKeyCredentialProvider(
            relyingPartyIdentifier: "example.com")
    let request =
        provider.createCredentialAssertionRequest(
            challenge: challenge)

    let controller =
        ASAuthorizationController(
            authorizationRequests: [request])
    controller.delegate = self
    controller.presentationContextProvider = self

    // Start the request
    controller.performAutoFillAssistedRequests()
}

13:29 - ASAuthorizationControllerDelegate callback

// Completing a passkey sign in

func authorizationController(controller: ASAuthorizationController,
     didCompleteWithAuthorization authorization: ASAuthorization) {
    
    guard let passkeyAssertion = authorization.credential as?
        ASAuthorizationPlatformPublicKeyCredentialAssertion
    else { … }

    let signature = passkeyAssertion.signature
    let clientDataJSON = passkeyAssertion.rawClientDataJSON

    // Pass these values to your server, and complete the sign in
…
}

16:05 - Modal passkey sign in

// Modal passkey request

func signIn() {
    let challenge: Data = … // Fetched from server
    let provider =      
        ASAuthorizationPlatformPublicKeyCredentialProvider(
            relyingPartyIdentifier: "example.com")
    let request = 
        provider.createCredentialAssertionRequest(
            challenge: challenge)
    
    let controller = 
        ASAuthorizationController(
            authorizationRequests: [request])
    controller.delegate = self
    controller.presentationContextProvider = self

    // Start the request
    controller.performRequests()
}

16:53 - HTML user name field annotation

<input type="text" id="username-field" autocomplete="username webauthn" >

17:09 - AutoFill-assisted passkey sign in on the web

// AutoFill-assisted WebAuthn request (JavaScript)

function signIn() {
    if (!PublicKeyCredential.isConditionalMediationAvailable ||
        !PublicKeyCredential.isConditionalMediationAvailable()) {
        // Browser doesn't support AutoFill-assisted requests.
        return;
    }

    const options = {
        "publicKey": {
            challenge: … // Fetched from server
        },
        mediation: "conditional"
    };

    navigator.credentials.get(options)
        .then(assertion => { 
            // Pass the assertion to your server.
        });
}

18:14 - Modal passkey sign in on the web

// Modal WebAuthn request (JavaScript)

function signIn() {
    var options = {
        "publicKey": {
            challenge: … // Fetched from server
        }
    };

    navigator.credentials.get(options)
        .then(function (assertion) { 
            // Pass the assertion to your server.
    });
}

20:55 - Modal passkey request with allow list

// Modal request with allow list

func signIn(userName: String) {
    let challenge: Data = … // Fetched from server
    let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
        relyingPartyIdentifier:"example.com")
    let request = provider.createCredentialAssertionRequest(
        challenge: challenge)

    let credentialIDs: [Data] = … // Fetched from server for provided userName
    request.allowedCredentials = credentialIDs.map(
        ASAuthorizationPlatformPublicKeyCredentialDescriptor.init(credentialID:))

    let controller = ASAuthorizationController(authorizationRequests: [request])
    controller.delegate = self
    controller.presentationContextProvider = self

    // Start the request
    controller.performRequests()
}

22:56 - Modal passkey request with silent fallback

// Modal passkey request, silent fallback

func signIn() {
    let challenge: Data = … // Fetched from server
    let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
        relyingPartyIdentifier:"example.com")
    let request = provider.createCredentialAssertionRequest(
        challenge: challenge)

    let controller = ASAuthorizationController(authorizationRequests: [request])
    controller.delegate = self
    controller.presentationContextProvider = self

    // Start the request
    controller.performRequests(options: .preferImmediatelyAvailableCredentials)
}

23:06 - Silent fallback delegate callback

// Handling a silent fallback
    
func authorizationController(controller: ASAuthorizationController, 
    didCompleteWithError error: Error) {
    
    guard let error = error as? ASAuthorizationError else { … }

    if error.code == .canceled {
        // Either the user canceled the sheet, or there were no credentials available.
        showSignInForm()
    }
}

24:40 - Combined credential request

// Combined credential modal request

func signIn() {
    let challenge: Data = … // Fetched from server
    let passkeyProvider = ASAuthorizationPlatformPublicKeyCredentialProvider(
        relyingPartyIdentifier:"example.com")
    let passkeyRequest = passkeyProvider.createCredentialAssertionRequest(
        challenge: challenge)

    let passwordRequest = ASAuthorizationPasswordProvider().createRequest()
    let signInWithAppleRequest = ASAuthorizationAppleIDProvider().createRequest()

    let controller = ASAuthorizationController(
        authorizationRequests: [passkeyRequest, passwordRequest, signInWithAppleRequest])
    controller.delegate = self
    controller.presentationContextProvider = self

    // Start the request
    controller.performRequests()
}

25:02 - Combined credential callback

// Completing a combined credential request

func authorizationController(controller: ASAuthorizationController, 
     didCompleteWithAuthorization authorization: ASAuthorization) {

    switch authorization.credential {
    case let passkeyAssertion as ASAuthorizationPlatformPublicKeyCredentialAssertion:
        finishSignIn(with: passkeyAssertion)

    case let signInWithAppleCredential as ASAuthorizationAppleIDCredential:
        finishSignIn(with: signInWithAppleCredential)

    case let passwordCredential as ASPasswordCredential:
        finishSignIn(with: passwordCredential)

    default:
        // Handle other credential types
        break
    }
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC23

WWDC22

WWDC20