パスキーによるアップグレードと認証情報マネージャによるサインインの効率化

既存のパスワードベースのアカウントを、パスキーを使用できるように自動でアップグレードする方法を学びましょう。アカウントセキュリティとサインインの容易さを向上させるべき理由とそれを実現する方法、認証情報マネージャアプリ向けの新機能に関する情報、新しいパスワードアプリでご自身のアプリ情報を差別化する方法を紹介します。

リソース

関連ビデオ

ダウンロード

こんにちは Garrettです今日は皆さんのアプリやWebサイトにパスキーへの自動アップグレードを実装する方法や優れたサインイン体験を実現するための新しい開発の数々をご紹介しますこのセッションでは既存のアカウントをパスキーに自動アップグレードする方法

認証情報マネージャで使える新機能の数々新しいパスワードアプリで皆さんのアプリを差別化する方法を説明します

最初にご紹介するのはパスキーへの自動アップグレードです

通常サインインは次のような流れで行われます

まずユーザー名を入力し

パスワードを入力します

SMSにコードが届いたら

これを入力します

これでやっとサインインできました

このように Webサイトやアプリにサインインする際は複数の手順が必要ですこの方法だとセキュリティは向上しますが時間がかかって面倒です

アプリによってはこの段階でインタースティシャルアップセルが表示されパスキーなど別の方法でより早くサインインする方法が案内されますがこのアプリは自動的にパスキーにアップグレードされるようになっているのでご覧のようにパスキーが作成されたという通知が表示されていますアップセル画面の表示も中断もなくより簡単でセキュアなサインイン体験がスムーズに実現しますこれはもちろん皆さんのWebサイトでも可能です

この体験はさらに強力で安全なサインイン方法にできるだけ簡単かつスムーズに移行できるようにするためのものですアプリをもう一度開くと 1回タップするだけで超高速かつ簡単にサインインできます

この一連の流れを比べてみましょう最初の手順はまったく同じです

1つのボタンでアカウントを選択します

従来のサインインの場合はこのあとも手順がいくつかありますがパスキーの場合は手順はこれだけでサインイン完了ですしかもパスキーの方がずっと安全です

フィッシング攻撃などの認証情報の詐取攻撃は今日インターネットでのアカウント侵害の最も一般的な手口となっています

最も効果的なフィッシング対策はフィッシングされる要素が一切ないアカウントを設定することです

新しいアカウントを保護するための最善の方法は最初からパスキーを設定することですパスキーなら忘れることもなくリセットの必要もめったにない上に 1回タップまたはクリックするだけでサインインできます

パスキーにするだけでフィッシングに対するアカウントの脆弱性を克服できます

しかし今日のほぼすべてのアカウントではフィッシングされる恐れのあるパスワードやSMS メールプッシュ通知有効期限のあるコードしか使われていません

これらを組み合わせれば少しは効果的ですがどの要素も基本的にはフィッシングに対して脆弱なものばかりです

今業界ではフィッシング攻撃に脆弱なサインイン方法からフィッシング不可能なパスキーなどの認証方法への移行が始まったばかりです

既存のアカウントでこのプロセスを開始するにはまずフィッシング不可能なサインイン方法を代替的な方法として追加します

このように段階的にパスキーを導入することでユーザーが各自のペースで移行できるようになります

最終的な目標はフィッシングに脆弱な認証要素を完全になくすことですがこのセッションではユーザーができるだけ簡単な方法でスムーズにパスキーを使い始められるようこの最初の第1歩を踏み出すことに重点を置きます

これはパスキーへの自動アップグレードのためのシーケンス図ですシステムはアプリからリクエストを受けるとこの時点でパスキーを作成するのが適切かどうかを判断し適切と判断した場合は新しいパスキーを返します

この判断を行うためシステムはリクエストを受け取ると以下を実行しますまずシステムは一連の内部チェックを行ってこの時点でパスキーを作成するのが適切かどうか判断します

例えばデバイスに認証情報マネージャが設定されておりパスキーへの自動アップグレードに対応しているかどうか

パスキーの使用に必要なパスコードなどがデバイス上で設定されているかどうか Webでのリクエストの場合はこれがプライベートブラウズ以外のタブであることを確認します

システムはリクエストを受理してよいと判断すると利用可能な認証情報マネージャにリクエストを渡します認証情報マネージャにも独自の受理条件があり最も重要な条件は以前にもパスキーを使用して同じアカウントのユーザー名とパスワードを入力したことがあったかどうかつまりこのアカウントのユーザー名がパスキーと同じかどうかということです

ユーザー名が同じで認証情報マネージャのその他の条件も満たしている場合は新しいパスキーが返されアプリに渡されます

このプロセスで条件が満たされない場合はエラーが返されますがこれは必ずしも何か問題があるという意味ではなく今回はパスキーが生成されなかったというだけのことです

パスキーへの自動アップグレードは段階的に実装すると考えてくださいパスキーはリクエストすれば必ず登録できるとは限りませんが登録できた場合はアップセル画面が不要になりアプリの操作も中断されずスムーズなユーザー体験が実現します

これはパスワードによるサインインが行われた時にパスキーの作成を促す際のフローです

パスワードを使ってサインインするとアカウントのパスキーの有無がチェックされない場合は作成を促します

現在多くのアプリではサインイン後すぐにこのようなダイアログが表示されアップグレードが促されます

パスキーへの自動アップグレードではこのような手順が不要になりますこの場合は .conditionalという登録用の新しい requestStyleを渡すことができます

システムとパスキーマネージャの前提条件を満たしている場合はパスキーが返されパスキーが作成されたという通知がデバイスに表示されますこの間アプリで実行中の操作は中断されません

前提条件が満たされないとエラーになり UIは表示されません

この段階で既存のアップセルダイアログを表示するか別の機会にもう一度試すかを選択できます

Webの場合も同様です標準のパスキー登録はこのようになりますが

ここでは mediationの conditionalパラメータによってモーダルでパスキーを作成するリクエストが自動アップグレードスタイルのリクエストに変更されます

Webの場合はリクエストスタイルを変更する前に getClientCapabilitiesを使ってブラウザが対応しているかどうか確認します

業界内でパスワードからパスキーへの移行が進んでいる中パスキーへの自動アップグレードによってこの流れに拍車がかかるでしょう

アプリやWebサイトのパスキーへのサポートを提供するプロセスは他の機能の開発と実装と同じで「学習」「開発」「テスト」「出荷」のフェーズを辿りますがパスキーの場合はほかとは少し異なり最終目標が2つあります 1つ目はサインインを簡単にすることもう1つはアカウントのセキュリティ強化です

パスキーのサポートを提供することでサインインは大幅に簡単になりますがパスワードとの併用を続けた場合はフィッシング攻撃やパスワードの使い回しを狙った攻撃から完全に逃れることはできません

つまりフィッシング可能な全ての要素を取り除くためのサインインのオプションを検討する時期にあるということです

皆さんのサービスを利用しているユーザーがパスワードを使用していないならぜひパスワードの排除を検討してください

同様にユーザーが多要素認証を使ってサインインしている場合は現在使用されている追加要素のほとんどが未だフィッシング攻撃に脆弱でありそれがパスキーへの移行が進んでいる根本的な理由であることを忘れないでください

パスキーを採用することでサービスへのサインインを大幅に高速化簡素化できますまた今日の一般的な多要素認証よりもさらに強力なセキュリティ対策を実現できます

今すぐパスワードを排除するのは難しいかもしれませんがこれがパスキー実装の最終目標であることを忘れないでください

次に認証情報マネージャで利用可能な新機能を紹介します

認証マネージャもパスキーへの自動アップグレードに対応しています

それに加えて有効期限のあるコードを入力できるようになり

ユーザー名パスワードワンタイムコードもテキストフィールドに入力可能になりました

これらはすべて従来の認証情報マネージャAPIへの追加機能ですこれらの機能に対応するため Info.plist用の新しいキーと対応するAPIが用意されています詳しくは認証サービスに関するドキュメントを参照してください

CredentialProviderExtensionのメカニズムもパスワードパスキー確認コードに対応するようになり AutoFillを使うアプリを3つまで選択できるようになっています

以上が認証情報マネージャの改良点です

最後にパスワードアプリについて説明しますこれはmacOS Sequoia iOS 18 visionOS 2の新機能です

このアプリでは Webサイトの名前やアイコンに注目が集まりますぜひ個性を発揮してください Webサイトやアプリの表示を変更する場合はそのための標準的な方法が用意されていますので後ほど説明します

トップレベルのパスキーのセクションではフィッシング耐性の高いサインインを採用しているアプリやWebサイトがハイライト表示されます確認コードのセクションもあります簡単にコードを見つけてコピーできるのでまるで専用の認証アプリみたいですね

セクションには脆弱なパスワードや使い回しパスワード漏洩したデータに含まれている保存済みパスワードのリストが表示されます Well-Known URL for Changing Passwords仕様が採用されている場合はボタンからパスワード変更用のWebページを開けます

macOSではメニューバー項目を有効にしておけばパスワードと確認コードに素早く簡単にアクセスできます別の認証情報マネージャから簡単にパスワードを読み込んだり読み出すこともできます

次にパスワードアプリでアカウントがどう表示されるか見てみましょう

このアカウントにはパスキーとパスワードが設定されています

特定のアプリやWebサイトで同じユーザー名のパスキーとパスワードが保存されている場合パスワードアプリはこの2つを 1つのエントリとして統合します

WebサイトでOpenGraphメタデータ標準が実装されている場合はアカウントが保存されているサイト名がパスワードアプリに表示されます

実装されていない場合はパスワードアプリが Webサイト名の取得を試みるかドメイン名にフォールバックします

OpenGraphWeb標準を実装すると Webページのヘッダタグに特定のメタタグを追加して Webサイトのメタデータを宣言できます

Webサイトが適切に表示されるようすべてのページサブドメインユーザーエージェントにメタデータが設定されていることを確認してください

さらに Webサイトのアイコンがアカウントの横に明確に示されるよう高解像度のアイコンを用意しましょう

最後に有効期限のある確認コードを使うアプリやWebサイトの場合は標準のQRコードに加えて otpauth:リンクを提供することでワンタップでコードを設定できるようになります

このリンクをタップするとシステムのデフォルトの確認コードアプリが起動し別のデバイスでも今使っているデバイスでも簡単にコードを設定できます

確認コードに使用できる認証アプリのリストを表示する場合は「Appleパスワード」もリストに追加してください

確認コードの詳細については「Secure login with iCloud Keychain verification codes」をご覧ください

今後以下をぜひ実行してみてくださいパスキーをまだ導入していない方は今が絶好のタイミングですパスキーはパスワードよりもずっと速く簡単でセキュリティも向上します自動アップグレードによってかつてないほど簡単にこの移行が可能になっています

Webサイトのメタデータを更新しパスワードアプリで Webサイトを差別化しましょう

最後に確認コードの設定を効率化してどのデバイスの認証情報マネージャでもスムーズに設定できるようにしましょう

ご視聴ありがとうございましたフィッシング攻撃をなくす取り組みにご協力いただきありがとうございます

0:01 - Offering a passkey upsell

// Offering a passkey upsell

func signIn() async throws {
    let userInfo = try await signInWithPassword()
    guard !userInfo.hasPasskey else { return }
    let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
        relyingPartyIdentifier: "example.com")

    guard try offerPasskeyUpsell() else { return }
    let request = provider.createCredentialRegistrationRequest(
        challenge: try await fetchChallenge(),
        name: userInfo.user,
        userID: userInfo.accountID)

    do {
        let passkey = try await authorizationController.performRequest(request)
        // Save new passkey to the backend
    } catch { … }
}

0:02 - Automatic passkey upgrade

// Automatic passkey upgrade

func signIn() async throws {
    let userInfo = try await signInWithPassword()
    guard !userInfo.hasPasskey else { return }
    let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
        relyingPartyIdentifier: "example.com")

    let request = provider.createCredentialRegistrationRequest(
        challenge: try await fetchChallenge(),
        name: userInfo.user,
        userID: userInfo.accountID,
        requestStyle: .conditional)

    do {
        let passkey = try await authorizationController.performRequest(request)
        // Save new passkey to the backend
    } catch { … }
}

0:03 - Modal passkey creation (web)

// Modal passkey creation

const options = {
    "publicKey": {
        "rp": { … },
        "user": {
            "name": userInfo.user,
            …
        },
        "challenge": …,
        "pubKeyCredParams": [ … ]
    },
};

await navigator.credentials.create(options);

0:04 - Automatic passkey creation (web)

// Automatic passkey creation

let capabilities = await PublicKeyCredential.getClientCapabilities();
if (!capabilities.conditionalCreate) { return; }

const options = {
    "publicKey": {
        "rp": { … },
        "user": {
            "name": userInfo.user,
            …
        },
        "challenge": …,
        "pubKeyCredParams": [ … ]
    },
    "mediation": "conditional"
};

await navigator.credentials.create(options);

0:05 - New Credential provider Info.plist keys

<dict>
	<key>NSExtensionAttributes</key>
	<dict>
		<key>ASCredentialProviderExtensionCapabilities</key>
		<dict>
			<key>ProvidesPasswords</key>
			<true/>
			<key>ProvidesPasskeys</key>
			<true/>
			<key>SupportsConditionalPasskeyRegistration</key>
			<true/>
			<key>ProvidesOneTimeCodes</key>
			<true/>
			<key>ProvidesTextToInsert</key>
			<true/>
		</dict>
	</dict>
</dict>

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

パスキーによるアップグレードと認証情報マネージャによるサインインの効率化

関連する章

リソース

関連ビデオ

WWDC23

WWDC22

WWDC21