パスキーの新機能

パスキーの新機能

iOS、iPadOS、macOS、visionOS 26によるパスキーの強化について説明します。キーのアップデートとしては、新しいアカウント作成APIによるサインアップの簡素化、パスキーを最新の状態に保つ方法、パスキーの自動アップグレードやパスキー管理エンドポイントを使用してパスキーをアップグレードする方法、パスキーを安全にインポート／エクスポートする方法などがあります。これらの機能強化によってユーザー体験とセキュリティを向上させる方法、およびこれらのアップデートをアプリに実装し、よりスムーズで安全な認証体験を提供する方法を紹介します。このビデオの内容を十分理解できるよう、最初に、WWDC22の「Meet passkeys」を視聴してください。

関連する章
- 0:00 - イントロダクション
- 0:58 - パスキーのジャーニー
- 3:30 - アカウント作成のAPI
- 10:48 - パスキーを最新の状態に維持する方法
- 14:41 - パスキーの自動アップグレード
- 16:59 - パスキー管理エンドポイント
- 19:12 - パスキーのインポートとエクスポート
リソース
関連ビデオ

WWDC24
- パスキーによるアップグレードと認証情報マネージャによるサインインの効率化
WWDC22
- パスキーについて
Authentication ExperienceチームのエンジニアのAndrewです Appleはサインインをシンプルかつ迅速で安全なものとすることに最大の関心があります
サインインやアカウントセキュリティに関する多くの問題の根本原因はパスワードです業界はオンラインアカウントにパスワードの代わりにパスキーを使うことでこれらの問題を根本から解決しようと取り組んでいますパスキーは最近よく聞くフィッシング詐欺などのパスワードに付きもののセキュリティや使いやすさの問題を根本的に解決しますまた楽しいサインイン体験も提供してくれます
このビデオをご覧になっているということはあなたもこれを実現させるチームの一員ですパスワードをパスキーに置き換えるという最も重要な目標に向かって一緒に取り組んでいるからです
パスキージャーニーとはこの目標までの道筋のことで業界全体でフィッシング不可能な要素のみを使用した認証に移行するまでの道筋を示したものですこれにはいくつかの段階がありますパスキーが登場する前は多くのアカウントはパスワードや SMSまたはメールで送信されるワンタイムコードなどフィッシング可能な要素のみを使用して作成されていました
このジャーニーはパスキーのようなフィッシング不可能な方法をサインイン方法に加えることから始まりました現在ほとんどの業界がこの段階にあります目標はすべてのアカウントでフィッシング可能な要素が一切使われなくなることでその目標を業界が達成するための方法がパスキーですパスキーに関してはユーザーの間に普及しつつあるほか幅広いサービスでサポートが広がるなど全体的に機運が高まっています 2025年にパスキーに関する標準化団体である FIDOアライアンスが行った調査によると調査対象者の69%が少なくとも1つのパスキーを持っていることがわかりました
Googleによればパスキーでサインインしているユーザーはパスワードを使用しているユーザーよりも 4倍の成功率でアカウントに入ることができています TikTokではパスキーを使用しているユーザーのサインイン成功率は 97%という驚異的な数字になっていますこのようなパスキーのサインイン成功率は業界全体でよく聞かれますがパスワードでは聞いたことがありません
順調に普及が進んでいることからパスキージャーニーの進展は明白です iOS、iPadOS、macOS、visionOS 26はパスキーをベースに構築されておりアプリやWebサイト間でパスキーを簡単に発見したり作成したり使用したりできるように新しい機能強化が追加されています 5つの重要なアップデートについて説明します 1つ目は新しいアカウント作成APIですこれは新しいアカウントを作成する最も速くて簡単な方法で最初からパスキーを提供します
次にパスキーを最新の状態に保つ方法について説明しますアカウントの変更を認証情報マネージャと同期させる方法を紹介します
次にパスワードベースの既存のアカウントにパスキーをシームレスに追加できるパスキーへの自動アップグレードについて説明しますその後サービスのパスキー登録ページを認証情報マネージャから直接表示するためのパスキー管理エンドポイントについて説明します
最後にパスキーのインポートとエクスポートについて説明しますこれはパスキーの柔軟性と制御性を向上させる重要なエコシステムの進歩です
最初は新しいアカウント作成APIについてです従来のパスワードベースのサインアップとは異なりパスキーの設定は長くて複雑なプロセスではありません迅速でシンプルなサインアップはとても楽ですパスキーでは複雑なパスワードを作成したりそれらを思い出したりする必要はありません
パスキーではすばやく楽にサインインできフィッシング詐欺対策にもなりますアカウント作成APIと最新のOSリリースを使用することでサインアップを楽しく迅速で根本的に安全な体験とすることができます
そのことをかわいい写真を毎日1枚選んでくれるデモアプリの Shinyを使ってiPhoneでお見せします
誰でも新しいアプリをインストールしたら最初にサインアップする必要がありますこれはアカウント作成APIを導入する前の従来の方法ですまずメールアドレスで新しいアカウントを作成します
すぐにフォームに記入するよう求められます最初はメールアドレスです幸いなことにここは自動入力が役に立ちますこれでメールアドレスは完了です次に氏名を入力します
そしてもちろん恐怖のパスワードも入力しますベストな方法を選択して強力なパスワードを自動で生成します
すべて入力したら最後にをタップしてサインインしますかわいい写真が表示されますなんてかわいいんでしょう次にアカウント作成APIを導入した後もう一度サインインしてみます前回同様にメールアドレスで新しいアカウントを作成します
複数の手順から成るフォームの代わりに Shinyが求めている情報が表示されたシートが提示されることに注目してくださいこの例では氏名とメールアドレスですそしてパスキーがパスワードアプリに保存されますそして一番よいところはすべてが自動的に入力されるところですこれがアカウント作成APIで可能になる新しい合理化されたフローです共有する情報を編集することもできますフィールドをタップすると候補が表示されたピッカーが表示されます候補の中から選ぶか別の情報を手動で入力することもできます今回はデフォルトで問題ありませんそのためをタップし Face IDで認証を行ったら完了です Shinyにサインインできましたより速くシンプルで安全です
サインインがこれまで以上に楽になります
後でiPadで初めてShinyを起動した場合でも
すぐにサインインプロンプトが表示されますこれはアプリが起動時に既存の認証情報がないかどうか確認するように設定されているためです以前に作成したパスキーをすべてのデバイスで利用することができますをタップし Face IDを行うだけで簡単にサインインできますこの体験は iOS、iPadOS、macOS visionOS上のアプリで利用可能でパスワードアプリやサードパーティ製の認証情報マネージャとも連携できます
次にこれらのサインアップ体験を実装する方法について説明します
これはアカウント作成の主要な手順を示した関数です最初に新しいアカウント作成プロバイダを初期化します次にそのプロバイダを使用してパスキー登録リクエストを作成しますこのメソッドではキーの詳細を指定します最初のパラメータは acceptedContactIdentifiersですアプリでサポートされるアカウントIDの種類をシステムに知らせますアプリはアカウントの作成用に選択された 1つのIDのみを受け取りそれをパスキーのユーザー名ラベルとしても使用します shouldRequestNameはユーザーの名前を要求するかどうかを指定しますアカウントの作成にユーザーの名前が必要な場合はtrueに設定します次の3つは作成されるパスキーに関係するものですこれらは標準のパスキー登録と同じであるためリクエストに行う場合と同じようにデータを指定します
パスキーを登録する際に使用するリライングパーティこれは一般的にはドメイン名ですまたサーバからフェッチされる作成されたパスキーによる署名付きの 1回限りの課題さらにユーザーIDはアカウントのために作成した安定した一意の識別子です次に ASAuthorizationControllerまでのインスタンスを取得します SwiftUIビューでは Environment プロパティラッパーを使ってアクセスできます次にリクエストを実行しますユーザーがサインアップフローを問題なく完了すると ASAuthorizationResultが返されますこれをアンラップすると連絡先IDや名前を要求した場合は名前またパスキーオブジェクトにアクセスできるようになりますどうぞサーバで新しいアカウントを作成しユーザーをサインインさせてください
これが実装方法の基本です問題が発生した場合は performメソッドがエラーをスローしますこれらのエラーを処理することで常に最高の体験を提供できるようにできます標準の AuthenticationServicesエラーに加えて特にこのAPIに関連した3つのエラーを処理する必要があります 1つ目は deviceNotConfigured ForPasskeyCreationですこのエラーはパスコードの未設定などデバイスが現在パスキーを作成する状態ではないことを意味していますユーザーがパスキーを作成する資格を現在満たしていないことがわかるため標準のサインアップフォームを表示することができます Shinyでボタンをタップするとカスタムサインアップフォームを表示することでエラーが処理されます次はcanceledですこのエラーはユーザーがサインアップシートを完成せずに閉じた場合にスローされますその場合標準のサインアップフォームを表示できます Shinyでシステムシートが閉じられるとカスタムサインアップフォームを表示することでエラーが処理されます最後は preferSignInWithAppleですこのエラーはアプリが「Appleでサインイン」をサポートしている場合にのみ返されますこれは誤ってアカウントが重複しないようにするためのものです「Appleでサインイン」を使用してサービスのアカウントをすでに作成しているユーザーがアカウント作成フローを開始するとこのようなアラートが表示されユーザーがそのことに気づくようにしますユーザーは「Appleでサインイン」を使用した既存のアカウントを使うか新しいアカウントの作成を続行できますユーザーが既存のアカウントを使う場合にこのエラーがスローされますそのためこのエラーを受け取った場合ベストプラクティスは「Appleでサインイン」リクエストの開始つまり「Appleでサインイン」シートを表示することですこれによりユーザーの選択を尊重し追加のタップなしで既存のアカウントにサインインさせることができますエラーについては以上です別のベストプラクティスとしてアプリの起動時にすぐに既存のアカウントを提供することでそれを使ってアプリにサインインするようユーザーを誘導することもできます iPadでのデモを思い出してください既存のアカウントがあったかどうかまた前回どのようにサインインしたかどうか考える必要もなくすぐにパスキーでサインインするかどうかたずねられましたこれができたのはすぐに利用可能な推奨の認証情報オプションセットによる複合サインインリクエストが Shinyで使用されていたからですデバイスに利用可能なアカウント認証情報がある場合それが認証情報マネージャアプリからのパスキーやパスワードであるかどうか「Appleでサインイン」を使用したアカウントであるかどうかに関係なくすべてをサインインに使用できますまたすぐに利用可能な認証情報がない場合 UIは表示されずサインイン画面も中断されませんこの機能の導入については WWDC22の「Meet Passkeys」をご覧ください
これがサインインを簡単かつ安全に行うための新しい機能であるアカウント作成APIでした
アカウントが作成されたらそのパスキー情報を認証情報マネージャに正確に維持することでスムーズな体験を維持しやすくなりますそこで次にパスキーを最新の状態に保つ方法について説明しますアカウントは静的ではありませんユーザーはユーザー名やメールアドレスなどの情報を更新するためパスキーが無効になることがありますサインイン時に認証情報マネージャにより古い情報が表示されるなら混乱や遅延が生じたりユーザーがサービスにサインインできなくなったりすることがありますそこでアプリやWebサイトがアカウントの変更を認証情報マネージャに知らせることができる新しいAPIコレクションが利用できるようになりましたこれらのシグナルAPIを導入してエントリを正確に保つことで迅速で信頼性の高いサインインを実現し無効にならないようにすることができます
これをShinyでどう活用できるでしょうか例えば私が最近大学を卒業したとして学生用の古いメールから個人用のメールにアカウントを変更したいとします
アプリの設定に移動してをタップし新しいメールアドレスを入力します
そして保存します
するとすぐに認証情報マネージャであるパスワードアプリからユーザー名が変更されたことが通知されます
これをタップするとパスワードにより認証が行われアカウントの詳細が表示されます
ユーザー名が新しい個人用のメールになっていることに気づきますこのように認証情報マネージャの情報がアプリのバックエンドのものと同じなりますなんて几帳面なんでしょうこれはアプリとWeb向けに用意された新しいAPIによって可能になりますアプリ向けに用意された新しい ASCredentialUpdaterクラスには特定の認証情報の変更を報告するためのメソッドが用意されています同様のメソッドが Web向けにも用意されており Safari 19やその他のブラウザで利用可能な WebAuthn標準に含まれています
最初のシグナルはユーザー名の変更ですデモで見たようにユーザーがユーザー名やメールアドレスまたアカウントに表示されるその他のラベルを更新した場合は reportPublicKeyCredentialUpdate メソッドを使用して認証情報マネージャに知らせますこれによりサインイン時に表示されるラベルを常に最新の状態に保ち混乱を防ぐことができますなおパスキーのユーザー名はローカルのみのラベルで認証中にサーバに返されることはありません
Webの場合は PublicKeyCredentialに対して signalCurrentUserDetailsメソッドを使用することで同じことを行えます
次はパスキーの無効化です多くのアプリやWebサイトにはパスキー管理ページがありそこでは個々のパスキーを無効にしたり新しいパスキーを作成したりできますパスキーが無効化されたときはいつでも reportAllAcceptedPublicKeyCredentials メソッドを呼び出して依然として有効な認証情報IDを指定しますこれを行うと認証情報マネージャにより指定したIDセットにないパスキーがすべて削除されますこれによりユーザーがサインインしたときに無効なパスキーが表示されなくなりますこれを定期的に呼び出してアカウントのヘルスチェックを行うこともできます何か変更があった場合このことは認証情報マネージャと最新情報を共有するのに役立ちます
signalAllAcceptedCredentials メソッドを使って同じことをWebでも行えます
結局のところ最も安全なアカウントはパスワードをまったく使用しないアカウントです新しいアカウント作成APIで作成されたアカウントではパスワードを一切使用しないため作成した日から安全に守ることができます
既存のアカウントについてはパスワードが必要なくなった場合に情報マネージャに通知できるようになりました reportUnusedPasswordCredential APIはアカウントがパスキージャーニーの最後の一歩を踏み出しパスワードが一切使用されなくなったことを示しています
もちろんすべての認証情報マネージャがこれらのシグナルの処理に対応していますがこれらの更新シグナルをリッスンし管理対象の認証情報を最新の状態に保つには新しいAPIを導入する必要があります詳しくは ASCredentialProviderViewControllerのレポートメソッドに関するデベロッパ向けドキュメントをご覧くださいこのようにこれらの新しいAPIは認証情報を正確に維持するのに役立ちます次に特に依然としてパスワードを使用してサインインしているユーザーに対してパスキーを導入するように促す方法について考えてみましょうパスキーへの自動アップグレードではパスワードベースの既存のアカウントにパスキーをシームレスに追加することができますアプリやWebサイトでパスワードによるサインインの直後にストレスなく作成できますそれをお見せします Shinyに戻って私が依然としてパスワードでサインインしているとしますユーザー名とパスワードを自動入力しをタップしてサインインします Shinyにはパスキーへの自動アップグレードが導入されているためこのようになりますパスキーが作成されたという通知が表示されますアップセル画面や中断はなくシームレスに移行できよりシンプルで安全なサインイン体験を利用できるようになります先ほど使用したパスワードも引き続き使用できること注意してくださいこのプロセスは安全なサインイン方法としてパスキーを追加するだけですコードを見てみましょうこれはパスキーへの自動アップグレードですユーザーがパスワードでサインインするとアカウントの詳細にアクセスできます最初にアカウントにまだパスキーがないかどうか確認しますない場合はパスキーを作成するときと同じようにパスキー登録リクエストを作成します requestStyleを conditionalに設定することでパスキーへの自動アップグレードを有効にしますこのように設定することでリクエストを実行した後システムおよび認証情報マネージャによって認証情報マネージャが利用可能かどうかこのアカウントにパスワードが使用されたかどうかまたデバイスにパスキーが設定されているかどうかなどのチェックがバックグラウンドで実行されますすべての条件が満たされた場合システムによりパスキーが作成され通知が表示されますそして保存するパスキーオブジェクトがアプリに送られますこれらすべてはユーザーの操作を中断したりブロックしたりすることなく行われますいずれかの条件が満たされなかった場合呼び出しがエラーなしで失敗しますシステムによってUIは表示されず特定のエラー処理も必要ありませんユーザーがパスキーを持っていない場合パスワードでサインインするたびにアプリでアップグレードを促す必要があります
同様のWeb APIもありますパスキーへの自動アップグレードについて詳しくはWWDC24のビデオ「Streamline sign-in with passkey upgrades and credential managers」をご覧ください自動アップグレードはストレスのない理想的な方法です
これを補完するためにパスキー管理エンドポイントのよく知られたURLを導入することで認証情報マネージャからパスキー管理ページまでの直接リンクを表示できますこれはパスキーの導入を強調するのに優れた方法ですそれをお見せしますこれはパスワードアプリの画面です依然としてパスワードを使用している Shinyへの保存エントリが表示されていますパスキーへのアップグレードが利用可能だと新しいセクションに示されていますボタンをタップすると Webサイトが開きパスキー登録に指定されたページに直接移動します
この標準を実装することで認証情報マネージャからパスキー登録ページまでの直接リンクを作成できますこれによりユーザーは別の方法で認証情報マネージャから直接アップグレードできるようになりますまたこれは標準に基づいているため対応しているすべての認証情報マネージャで機能します
これをサポートするにはサーバのよく知られたパスキーエンドポイントパスでJSON応答を調査します応答はリダイレクトを介さずこのパスから直接行われている必要があります
状態コードを200 OKにまたConten-Typeのヘッダを application/jsonにしてこの応答を提供します
応答のコンテンツは Webサイトの関連するページをポイントした JSON辞書です
enrollはユーザーがパスキーをアカウントに追加できるURLですこれはパスワードアプリのボタンのリンク先です manageはユーザーが既存のパスキーを管理することができるURLで変更されたパスワードページに似ていますここでは既存のパスキーを無効にしたり新しいパスキーを追加したりできます
これらのフィールドはすべて任意ですが両方を含めることをおすすめしますこれらのURLが認証セッションなしにアクセスしたユーザーを正しく処理できることが重要になりますサインインが必要な場合はまず認証を行いその後最初にリクエストされたURLにリダイレクトします
このページにはすべてのユーザーエージェントがアクセスでき利用できなければなりませんこれをリクエストするのは Webブラウザだけではありません認証情報マネージャのようなアプリもリクエストします
パスキー管理エンドポイントによく知られたURLを実装することでサービスにパスキーを導入するようユーザーを促すヒントを認証情報マネージャにヒントを提供できます
次にパスキーのインポートとエクスポートについて説明します
ユーザーは独自の認証情報を所有しておりそれらを好きなところで柔軟に管理できなければなりませんそこで iOS、iPadOS、macOS visionOS 26上の対応している認証情報マネージャアプリ間でパスキーを安全に転送できるようになったことをお知らせできることをうれしく思いますこれによりユーザーは自分のデータをより詳細に制御できるようになり使用する認証情報マネージャを自由に選べるようになりました
この新しいプロセスは従来の認証情報エクスポート方法とは根本的に異なりそれらよりも安全です従来の方法では多くの場合暗号化されていないCSVファイルや JSONファイルをエクスポートした後別のアプリに手動でインポートしていました新しい転送プロセスはユーザーにより開始され対応している認証情報マネージャアプリ間で直接行われ Face IDなどのローカル認証によって保護されますこの転送にはパスキーやパスワード確認コードまたその他のデータタイプのデータ形式を標準化している FIDOアライアンスのメンバーと共同で構築されたデータスキーマが使用されていますシステムによりアプリ間でデータを移動する安全なメカニズムが提供されます安全でないファイルは作成されないためエクスポートされたファイルから認証情報が漏洩するリスクがありませんこれは認証情報を移動するための現代的で安全な方法です
プロセスは認証情報マネージャ間で直接行われるためアプリやWebサイトが認証情報の転送で何か行う必要はありません既存のパスキーは変更されず引き続きシームレスに使用できます認証情報マネージャアプリで認証情報の転送サポートを検討している場合 ASCredentialExportManagerと ASCredentialImportManagerのデベロッパ向けドキュメントをご覧ください
パスキーは進化を続けておりよりシンプルな体験でより強力なセキュリティを提供できるようになっています今回の新しいOSリリースでもさらに簡単に作成使用発見できるようになっていますパスワードのない未来に向けて私たちは共に旅をしていますこれをすべての人に実現するにはこれらの機能を導入することが重要になります最高の認証体験を提供するための次のステップは次の通りですまず安全で迅速なオンボーディングのためにアカウント作成APIを導入します次にシグナルAPIを使用してパスキーを最新の状態に保ちユーザー名の更新やパスキーの削除などのアカウントの変更を認証情報マネージャに知らせますパスワードからシームレスに移行できるようにパスキーへの自動アップグレードを有効にします最後にWebサイトからパスキー管理エンドポイントを提供することで認証情報マネージャからパスキーへのアップグレードを発見しやすくします以上がパスキーの最新情報でしたご視聴ありがとうございました

// Account creation

@Environment(\.authorizationController) var authorizationController

func performPasskeySignUp() async throws {
    let provider = ASAuthorizationAccountCreationProvider()
    let request = provider.createPlatformPublicKeyCredentialRegistrationRequest(
        acceptedContactIdentifiers: [.email, .phoneNumber],
        shouldRequestName: true,
        relyingPartyIdentifier: "example.com",
        challenge: try await fetchChallenge(),
        userID: try await fetchUserID()
    )

    do {
        let result = try await authorizationController.performRequest(request)
        if case .passkeyAccountCreation(let account) = result {
            // Register new account on backend
        }
    } catch
        ASAuthorizationError
        .deviceNotConfiguredForPasskeyCreation {
        showPasswordSignUpForm = true
    } catch ASAuthorizationError.canceled {
        showPasswordSignUpForm = true
    } catch
        ASAuthorizationError.preferSignInWithApple {
        await performSignInWithApple()
    } catch { ... }
}

12:30 - Changing the user name

// Changing the user name

try await ASCredentialUpdater()
    .reportPublicKeyCredentialUpdate(
        relyingPartyIdentifier: "example.com",
        userHandle: userHandle,
        newName: "andrew@example.com"
    )

12:58 - Changing the user name

// Changing the user name

await PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: userHandle,
    name: "andrew@example.com",
    displayName: "andrew@example.com"
});

13:07 - Revoking a passkey

// Revoking a passkey

try await ASCredentialUpdater()
    .reportAllAcceptedPublicKeyCredentials(
        relyingPartyIdentifier: "example.com",
        userHandle: userHandle,
        acceptedCredentialIDs: acceptedCredentialIDs
    )

13:46 - Revoking a passkey

// Revoking a passkey

await PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: userHandle,
    allAcceptedCredentalIds: acceptedCredentialIds
});

14:04 - Removing a password

// Removing a password

try await ASCredentialUpdater()
    .reportUnusedPasswordCredential(
        domain: "example.com",
        username: "andrew@example.com"
    )

15:36 - Automatic passkey upgrade

// Automatic passkey upgrade

func signIn() async throws {
    let accountDetails = try await signInWithPassword()
    guard !accountDetails.hasPasskey else { return }

    let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
        relyingPartyIdentifier: "example.com")

    let request = provider.createCredentialRegistrationRequest(
        challenge: try await fetchChallenge(),
        name: accountDetails.userName,
        userID: accountDetails.userID,
        requestStyle: .conditional
    )

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

- 0:00 - イントロダクション
- The Authentication Experience team is working to eliminate passwords in favor of passkeys — a more secure and user-friendly method that eradicates phishing and streamlines the sign-in process.
- 0:58 - パスキーのジャーニー
- Recent updates to iOS, iPadOS, macOS, and visionOS make passkey creation, management, and upgrading easier, accelerating passkey adoption. The industry is transitioning from phishable passwords and SMS/email codes to non-phishable passkeys. Currently, many accounts offer passkeys as an additional sign-in method, but the goal is to eliminate phishable factors entirely. Adoption of passkeys is growing rapidly and passkeys have high sign-in success rates. In a 2025 survey, the FIDO Alliance found that 69% of people surveyed have at least one passkey. Google found that users signing in with passkeys are four times more successful than users who sign in with passwords.
- 3:30 - アカウント作成のAPI
- The new account creation API revolutionizes the sign-up process for apps. This API is available on iOS, iPadOS, macOS, and visionOS, and works with both the Passwords app and third-party credential managers. With this API, people can create accounts with passkeys, which eliminates the need to remember complex passwords, makes the experience more user-friendly, and reduces the risk of phishing attacks. The sign-up process after adopting the account creation API is incredibly streamlined. Instead of a multi-step form, a pre-filled sheet shows exactly what the app is requesting for sign-up, for example, email and name. Sign-up information is editable by the person. Upon completion, the system automatically generates a passkey, which is saved in the Passwords app. The benefits of passkeys extend beyond sign-up. Signing in with passkeys is effortless, and passkeys are automatically synced across all devices to ensure a seamless user experience. You can easily implement the account creation API in your apps by following a few core steps. The API handles potential errors gracefully, providing people with a smooth sign-up experience even if their device is not configured for passkey creation or if they already have an account using Sign in with Apple.
- 10:48 - パスキーを最新の状態に維持する方法
- New signal APIs enable apps and websites to notify credential managers when account information changes, such as usernames or email addresses, or when passkeys are revoked. This ensures that credential managers remain up-to-date, preventing confusion and login issues. For example, when someone updates their email address in an app, the app immediately signals the credential manager, which then updates its records. These APIs support accounts without passwords which are the most secure accounts. The APIs also inform credential managers when passwords are no longer needed, enhancing overall security and improving user experience.
- 14:41 - パスキーの自動アップグレード
- Automatic passkey upgrades enhance account security for users still signing in with passwords without introducing friction. After a successful password login, apps and websites can create passkeys in the background without any user interaction or interruptions. A notification informs a person when a passkey is added, providing a simpler and more secure sign-in option moving forward. The password remains valid, and the upgrade process occurs silently on every password sign-in attempt if a passkey doesn't already exist.
- 16:59 - パスキー管理エンドポイント
- By implementing the standard well-known URL for passkey management endpoints, websites can directly link credential managers to their passkey enrollment and management pages. This approach streamlines the passkey-upgrade process for people, so they can easily switch from passwords within their credential managers. The JSON response from the server must include URLs for enrollment and management, be served with a '200 OK' status code, and be accessible to all user agents, including apps and web browsers.
- 19:12 - パスキーのインポートとエクスポート
- Passkeys can now be securely transferred between participating credential manager apps across iOS, iPadOS, macOS, and visionOS 26. This user-initiated process, secured by local authentication like Face ID, reduces the risk of credential leaks. The transfer uses a standardized data schema developed by the FIDO Alliance, ensuring compatibility between apps. Deliver the best authentication experience for your users and help them move to a more secure future without passwords. Adopt the account creation API for secure and quick onboarding, keep passkeys up-to-date using the signal API, enable automatic passkey upgrades, and support passkey management endpoints.

関連する章

リソース

関連ビデオ

WWDC24

WWDC22