次世代認証技術であるpasskeysについて
パスキーの使い方
通常のフロー
IDを入力して → パスワードを入力 → SNS認証
これをパスキーに対応すると
1タップ(+ faceID)で完了
新しいパスワードを考えたり、複雑な条件を満たそうとしたりする必要はありません。
それぞれのパスキーはシステムによって生成され、強度が保証されており、1つのアカウントにのみ使用されます。
しかも、正しいアプリやウェブサイトでだけ使わせるように配慮され、強力なフィッシング耐性が内蔵されています。
追加方法
このアカウントにパスキーを追加してみます。 「アカウント管理」→「パスキーの追加」。ここで、パスキーを作成するためのシステムシートが表示されました。 数回タップするだけで、私のデバイスは私のアカウント用にユニークで暗号的に強力なキーペアを生成し、私のiCloudキーチェーンに保存しました。
webでも使える
パスキーはウェブ上でも使えます。
ここでは、Safariでシャイニーのウェブサイトを見ています。
携帯電話と同じように、ユーザー名フィールドにフォーカスすると、iCloud Keychainのおかげで私のパスキーがすでにそこにあり、すぐに使える状態になっています。
あとはTouch IDでサインインするだけです。
パスキーはオープンスタンダード
Appleのパスキーの実装は、オープンスタンダードに基づいて構築されています。
私たちは、FIDOアライアンス内の他のプラットフォームベンダーと協力して、パスキーの実装がクロスプラットフォームで互換性を持ち、できるだけ多くのデバイスで動作するようにしました。
私のアカウントをパスキーを使うようにアップグレードした後も、友人のPCからサインインすることができます。
もちろん、友人のPCにはローカルにパスキーは保存されていないが、ここでユーザー名を入力することはできる。
サインインを押すと、携帯電話を使わせてくれるというシートが表示されます。すると、QRコードが表示されます。これをスキャンします。
このQRコードはパスキーを使ってサインインするためのものだと認識されます。このオプションを選択すると、私の携帯電話とブラウザが安全に接続されます。
あとは「続ける」だけで、サインインが完了します。このクロスプラットフォームでのサインイン体験は、パスキーの背後にある標準の一部であり、第一級のシステム機能です。一見、とてもシンプルに見えますが、これは単なるQRコードではありません。
裏側では、デバイスがローカルな鍵の合意を行い、近接性を証明し、エンドツーエンドの暗号化通信路を確立しています。すべては、簡単な方法でサインインできるようにするためですが、passkeysの強力なフィッシング耐性を維持するためです。
どのようなデバイスからでも自分のアカウントに安全にサインインできるようにするために、とても役立っています。
パスワードの共有も可能
パスキーをAirDropを使って共有ができます。
私の携帯電話では、私はアカウントの詳細を開いて
AirDriopで共有が可能
これで私のパートナーもパスキーを持つことができます。
このように、どこでも簡単にパスキーを使うことができるのです。
パスキーのデザイン
パスキーについて語るとき、何よりもまず、パスキーはパスワードの代用品です。
パスキーはより速くサインインでき、より簡単に使用でき、より安全です。
以下は、アプリやウェブサイトでパスキーをどのように呼ぶかのガイドラインです。
Passkey は、一般的な、ユーザが目にすることのできる用語です。
"Passkey "はまた、"password "のような普通名詞です。英語では小文字で、"password "のように複数形になることを意味します。私は自分のアカウントにパスキーを持っていて、「設定」でパスキー付きのアカウントをすべて見ることができます。
SFシンボルのperson.key.badgeと.fillも用意されています。
アプリやウェブサイトでパスキーを提供する場合、まったく新しいインターフェースを設計する必要はありません。
そして今、ユーザー名フィールドに、もうひとつの大きな特徴が加わりました。
パスキーはサインインの仕組みに新しいパラダイムをもたらしますが、パスワードからの移行もスムーズで簡単である必要があります。
AutoFillを使用したパスキーは、ファーストクラスの機能として、既存のサインインフローにそのまま組み込むことができます。
AutoFillを使用したパスキーの提示は、パスキーの主要な使用方法です。
しかし、より高度な使い方として、Appleのプラットフォームには、パスキーを使ったサインイン用の幅広い追加UIオプションがあります。
パスキーの使用方法とAutoFillを使用したパスキーの表示方法について
Passkeys は WebAuthentication または WebAuthn 標準をベースに構築されており、公開鍵暗号方式を使用します。
入力可能な単語や文字列ではなく、一意の暗号キー ペアがアカウントごとに生成されます。
パスキーによるサインインを行うには、サーバーのバックエンドに WebAuthn を採用する必要があります。
パスキーは AuthenticationServices フレームワークの ASAuthorization API ファミリーに含まれます。
また、AutoFillのサポートなど、使用できる新しいメソッドもいくつか追加され、このAPIをさらに柔軟にして、既存のサインインフローにシームレスに適合させることができるようになりました。
アプリでパスキーを使い始めるには、まず、webcredentials サービスを使用して、関連するドメインを設定する必要があります。
詳細は、ビデオ「Introducing Password AutoFill for Apps」と「What's new in Universal Links」でご覧いただけます。
アプリのインターフェイスで、ユーザー名フィールドがユーザー名textContentTypeを使用していることを確認します。
これにより、パスキーの候補を提供する場所がシステムに通知されます。
この設定が完了したら、AutoFillによるパスキーリクエストを開始するために必要なコードを以下に示します。
他の WebAuthn リクエストと同様に、まずサーバーからチャレンジを取得する必要があります。
次に、プロバイダとリクエストを作成します。
ASAuthorizationPlatformPublicKey CredentialProvider は、パスキー リクエストを扱うための ASAuthorizationProvider です。
WebAuthn の用語では、サインイン時にアサーションを使用するため、ここでは既存のパスキーでサインインするためのアサーションリクエストを作成しています。
実際にリクエストを処理するのは ASAuthorizationController です。
パスキーリクエストでインスタンスを作成し、そのデリゲートとpresentationContextProviderを設定します。
そして最後に、performAutoFillAssistedRequests を呼び出して、リクエストを開始します。
このリクエストがアプリで実行されている間、ユーザー名フィールドがフォーカスされるたびに、システムは QuickType バーに利用可能なパスキーを提供します。
キーボードが表示されたときにパスキーの準備ができるように、ユーザー名フィールドがフォーカスされる前に、ビューライフタイム内の早い段階でこのリクエストを開始するようにしてください。
QuickType バーの項目が選択されると Face ID が呼び出され、ASAuthorizationController Delegate コールバックを受け取ってサインインを完了します。テキストフィールドには、実際には何も入力されません。
どの種類のクレデンシャルでも認証に成功すると、didCompleteWithAuthorizationコールバックを受け取ります。
最初にすべきことは、取得したクレデンシャルの種類を確認することです。
パスキーによるサインインの場合、それは ASAuthorizationPlatformPublicKey CredentialAssertion となる。アサーション・オブジェクトには、バックエンドでサインインを検証するために必要なフィールドが含まれる。
値を読み込んでサーバで検証し、サインインを完了させる必要がある。
AutoFill によるパスキーリクエストは強力です。
先ほど紹介したコードでは、追加の変更なしに近くのデバイスからパスキーサインインすることも可能です。
鍵のアイコンをタップして、利用可能なすべてのパスキーとパスワードを一覧表示するビューを表示し、近くのデバイスでサインインするオプションにたどり着くことができます。
その後、クロスデバイスのパスキーサインインを実行できます。
どちらの場合も、パスキーが使われると、同じASAuthorizationController Delegateコールバックを受け取ります。
これをサポートするために必要な特別なことは何もありません。
もしユーザーがまだパスキーを持っていない場合は、ログインフォームをそのまま使用することができます。QuickTypeバーにパスワードの候補が表示されますし、フィールドに入力することもできます。
パスワードの項目が選択された場合でも、クレデンシャルはテキストフィールドに入力され、実行中のリクエストをキャンセルすることができます。
このAPIは、既存のサインインフローにそのまま追加できるように設計されており、ユーザーにとって非常に使いやすいものとなっています。
既にパスキーの使用にアップグレードした人が、AutoFill の提案を使う代わりに、とにかくユーザ名を入力しようと決めた場合、AutoFill のリクエストをキャンセルして、ASAuthorizationController を使ってモーダルパスキーサインインシートを表示させる必要があります。
ここからはシングルタップで、同じ ASAuthorizationController Delegate のコールバックを受け取ることができます。
以下は、以前のコードです。AutoFill リクエストからモーダルリクエストに切り替えるには、この performAutoFillAssistedRequests メソッドの呼び出しを performRequests() の呼び出しに置き換えるだけです。
Web
Web プラットフォームも、AutoFill アシストとモーダルパスキーの両方のリクエストをサポートしています。
Web では、セキュリティ キーにも使用される標準の WebAuthn API を介してパスキーが使用されます。アプリと同様に、AutoFill アシスト リクエストを採用すると、Touch ID だけですばやくサインインしたり、利用可能なすべてのパスキーとパスワードを取得したり、近くのデバイスからパスキーを使用したりすることができ、これらはすべて非常に少ないコードで実現できます。
詳細はこちら
プラットフォームの追加機能
AutoFillによるサインインに加え、ASAuthorization APIはさらに多くの便利な機能を提供しています。
ここでは、APIの3つの追加機能と、それらをどのような場合に使用したいかを説明します。
パスキー許可リスト
デフォルトでは、利用可能なすべてのパスキーがシートに表示されます。
パスキーの許可リストを使用して、シートに表示されるパスキーを制限し、一致するアカウントのみが提供されるようにすることができます。モーダルリクエストに許可リストを追加するには、まず、ユーザー名が必要です。
そのユーザー名を使って、一致するクレデンシャル ID のリストを取得し、それを許可リストにすることができます。
クレデンシャル ID とは、パスキーの一意な識別子です。Webauthn サーバーは、与えられたユーザー名のクレデンシャル ID を検索する方法を持つべきです。
ここからは、先ほどと同じようにリクエストを進めるだけです。
さて、パスキーを使用して3つのShinyアカウントを持つ私のデバイスでは、シートは私が使用しようとしている1つのアカウントのみを提供します。
モーダル リクエストを作成する場合、ユーザーがどのアカウントでサインインしようとしているか、例えばユーザー名をすでに入力しているかなどの追加情報があるときは、許可リストを使用する必要があります。
パスキーが保存されていない場合、モーダルパスキーのリクエストを行うとどうなるか
許可リストを使用していて、保存されているパスキーのどれもがそのリストに一致しない場合にも当てはまります。
デフォルトでは、モーダルパスキーリクエストを行う際、一致するパスキーがない場合は、モーダルシートが表示され、近くのデバイスからパスキーでサインインするための QR コードがすぐに表示されます。
これはサインイン時に最も柔軟性があり、パスキーが使用されていることが分かっている場合には最適なオプションです。
しかし、APIには新しいオプションがあり、すぐに利用できる認証情報を優先し、ない場合はデリゲートコールバックで静かにフォールバックするようになっています。
これは、従来のサインインフォームを表示する前に、可能であれば既存のクレデンシャルを迅速に提供するために使用できます。
デバイス上に少なくとも 1 つの一致するクレデンシャルがある場合、使用するオプションに関係なく、フル モーダル シートが表示されます。
現在のデバイスにパスキーがない場合でも、近くのデバイスでサインインするオプションに到達できるように、アプリ内のどこかで AutoFill アシスト リクエストまたはデフォルト フォールバックでのモーダルリクエストを使用していることも確認してください。
複合クレデンシャルリクエストの作成
この例では、アプリがパスキー、パスワード、Sign in with Appleのリクエストを行いました。
私のデバイスにはたまたま3つの異なるアカウントの認証情報が保存されていたので、ここにすべて表示されています。
しかし、より可能性の高いシナリオは、誰かが1つのアカウントしか持っていない場合です。
その場合、シートで1つのアカウントのみを提供します。
既存のASAuthorizationリクエストに追加のクレデンシャルタイプを追加するのは、本当に簡単です。
追加のリクエストタイプのためのプロバイダとリクエストを作成し、それらの新しいリクエストをコントローラに渡すだけです。
これで、モーダルシートは、これらのクレデンシャルタイプのいずれかから利用可能なクレデンシャルを提供することになります。
まとめ
パスワードからパスキーへとユーザーを誘導することで、信じられないほど迅速で便利なサインインを体験してもらうと同時に、全員のセキュリティレベルを向上させることができるのです。
