パスキー認証と2要素認証の仕組み

Posted at 2026-05-03

普段から1Passwordを使っていますが、従来のID・パスワード認証に加えて、2要素認証(2FA)の多様化もあり、Webサービスにスムーズにログインできないことが増えて少しモヤモヤしています。（僕の設定が不十分だからなんですが。）

今回はパスキー認証を中心に関連する用語や仕組みを網羅的にまとめてみました。

この記事では主にMac(macOS Tahoe以降)とiPhone(iOS 26以降)に対して、1Passwordを利用する前提に整理しています。WindowsやAndroidについては触れていません。

この記事で取り扱う内容

この記事では以下の内容を扱います。一通り読むことで、認証まわりの仕組みがある程度理解できるはずです。

主な認証手段の概観
パスキーの仕組み(公開鍵と秘密鍵、認証の流れ)
プロバイダとFIDO2の関係性
1PasswordとiCloudキーチェーンの違い
Touch IDとFace IDの役割
パスキーを運用する際の注意点
1Password中心の運用に揃える手順

用語の整理

認証関係の用語は似たようなキーワードが多く混乱を招きそうなので、一般的なものをまとめてみました。

パスワード関連の用語

この記事を読み進める上で、ワンタイムパスワードやパスキーについては最低限把握しておいた方が良いと思います。

用語	内容
OTP(One-Time Password)	ワンタイム(1回)しか使えないパスワード。時間ベースのTOTPと、カウンタベースのHOTPがある。
TOTP(Time-based One-Time Password)	一定時間ごとに変わる6桁コードを生成する規格(RFC 6238)。認証アプリで使われる。
HOTP(HMAC-based One-Time Password)	カウンタの値で6桁コードが変わる方式。実運用ではあまり見かける機会が少ない。
パスキー	公開鍵暗号方式の鍵ペアを使うパスワードレス認証方式。鍵は文字列ではなくバイト列としての暗号鍵で、利用者は鍵を保管するデバイスやプロバイダを選び、認証時には生体認証などで本人確認を行う。フィッシング耐性が高い。
APIキー	プログラムからサービスにアクセスするための長い文字列。利用者本人ではなくアプリケーションが利用する識別情報で、1Passwordなどのパスワード管理アプリでは資格情報の一種として保管できる。
リカバリーコード	2要素認証用のデバイスやパスキーを失った場合に備えてサービス側が発行する救済用コード。安全な場所(1Passwordのセキュアノートなど)に保管しておく。
PIN(Personal Identification Number)	通常4〜6桁の短い数字列。デバイスやサービスに紐付き、入力試行回数の制限により短くても安全に運用できる。

規格・プロトコル

パスキーや2要素認証を支える背後の規格やプロトコルです。

用語	内容
FIDO2(Fast IDentity Online)	パスワードレス認証の規格群の総称。FIDO Alliance と W3C が共同で策定し、WebAuthnとCTAP2を含む。
WebAuthn(Web Authentication API)	FIDO2のうち、Webブラウザがパスキー機能を呼び出すためのJavaScript API。
CTAP2(Client-to-Authenticator Protocol)	FIDO2のうち、ブラウザやOSとプロバイダ(物理キーなど)の間の通信プロトコル。
OAuth(Open Authorization)	サービス間で認可を委譲するためのプロトコル。「LINEでログイン」などのソーシャルログインの基盤になっている。
OpenID Connect	OAuthを土台にした、本人確認(認証)のためのプロトコル。

物理規格・関連技術

物理的な接続規格や、デバイス内のセキュリティ領域に関する用語です。

用語	内容
NFC(Near Field Communication)	数センチ以内の近距離無線通信。電子決済や物理セキュリティキーの認証に利用される。
BLE(Bluetooth Low Energy)	低消費電力のBluetooth規格。クロスデバイス認証で物理的な近接確認に使われる。
Secure Enclave	Apple製チップに内蔵されたセキュリティ領域。Touch IDやFace IDの生体データ、パスキーの秘密鍵などを扱う。
AAGUID(Authenticator Attestation GUID)	プロバイダの種類ごとに割り当てられた128ビットの識別子。パスキー作成時にサービス側へ送られ、どのプロバイダで作られたパスキーかを識別するために使われる。サービスのパスキー一覧で「Apple」「1Password」のようなラベルが表示されるのは、この情報をもとに判別している。

認証アプリ・パスワード管理アプリ・物理キー

実際に利用者が扱うアプリや物理的なデバイスの名称です。

用語	内容
iCloudキーチェーン	Apple製のパスワード・パスキー・クレジットカード番号同期サービス。Apple ID紐付けでApple機器間で同期する。
パスワード(Appleの純正アプリ)	iOS 18 / macOS Sequoia で導入された、iCloudキーチェーンを操作するアプリ。中身のデータの実体はiCloudキーチェーンと同一。
1Password	1Password社のクロスプラットフォーム対応パスワード管理アプリ。パスワード・パスキー・TOTP・SSHキーなどを統合管理する。
YubiKey	Yubico社が販売する物理セキュリティキー。
Google Titan Security Key	Googleが販売する物理セキュリティキー。
Windows Hello	Windowsに搭載されたプラットフォーム認証機構。生体認証またはPINで動作する。

1Password以外の主要なパスワード管理アプリとして、Bitwarden、Dashlane、LastPass、Proton Pass、Keeperなどがありますが、この記事では取り扱いません。

認証手段の概観

認証まわりの手段には、大きく分けて、ID・パスワード認証に追加して使う「2要素目」の手段と、ID・パスワード認証そのものを置き換える「主要認証(1要素目)の代替」があります。

SMS認証・メール認証

電話番号やメールアドレス宛に、6桁前後の使い捨てコードが届き、それを入力する方式です。実装が簡単で利用者の手間も少ない一方で、SIMスワップ攻撃やフィッシング、メールアカウント侵害などの耐性は他の方式に比べて低いです。他の方式が使えない場合のバックアップ手段という位置付けです。

認証アプリ(TOTP)

スマートフォン上の認証アプリが、一定時間ごと(通常は30秒〜60秒)に変わる6桁〜8桁のコードを生成する方式です。代表的なアプリには以下のようなものがあります。

Google Authenticator(Google製のTOTP生成アプリ)
Microsoft Authenticator(Microsoft製の認証アプリ兼プッシュ通知アプリ)
Authy(Twilio社のTOTP生成アプリ)
Duo Mobile(Cisco製の認証アプリ。主に企業向けのプッシュ通知認証で利用される)
1Password(本体に組み込まれているTOTP生成機能)

TOTPはRFC 6238として公開されている共通規格で、秘密鍵と現在時刻からコードを計算する関数として動作します。アプリは認証のときに認証サーバーと通信せず、オフラインで動きます。同じ秘密鍵を読み込んだ場合、同時刻だと必ず同じコードを表示するため、特定のアプリに縛られません。

プッシュ通知認証

スマートフォンに「ログインしようとしていますか?」という通知が届き、利用者が承認することで認証を完了します。代表的なサービスや採用例には以下のようなものがあります。

Microsoft 365 / Azure AD(Microsoft Authenticator)
Google アカウント(Google アプリまたは Gmail アプリ)
Cisco Duo 経由の企業向けサービス(Duo Mobile)
各種銀行(各行の独自アプリ)

認証サーバーがインターネット経由でスマートフォン上の対応アプリに通知を送信し、承認 or 拒否をサーバーに返します。
プロトコルが各社の独自仕様であるため、共通規格に基づくTOTPとは異なり、サービス側が指定したアプリでしか動作しません。Microsoft AuthenticatorはMicrosoft系サービス向けにこの方式を提供しており、TOTPとの両方を兼ねる多機能アプリとして使えます。

パスキー

FIDO2という規格に基づく、公開鍵暗号方式の鍵ペアを使うパスワードレス認証です。秘密鍵が利用者のデバイス側に保管され、認証時には生体認証やPINで本人確認を行います。秘密鍵を保管するプロバイダ(保管先)には以下のようなものがあります。

iCloudキーチェーン(Apple機器に統合された保管先)
Windows Hello(Windows搭載のプラットフォーム認証機構)
1Password、Googleパスワードマネージャなどのパスワード管理アプリ

利用者は文字列を覚えたり入力したりする必要がなく、操作の流れも生体認証やPIN入力で完結します。仕組みの面では、認証時にアクセス先のドメイン名が暗号計算に組み込まれる構造になっているため、ドメインが異なるフィッシングサイトでは認証が成立しません。SMS・TOTP・プッシュ通知などと比較してフィッシングへの耐性が高いです。
近年、主要サービスでの対応が進み、ログインや2要素認証の選択肢として普及しています。

物理セキュリティキー

パスキー(プラットフォーム型)と同じFIDO2方式のプロバイダ(認証器)で、秘密鍵を物理デバイス本体に保管します。USB Type-CやType-A、NFCなどにより接続します。主に以下のような製品が存在します。

YubiKey
Google Titan Security Key

価格や持ち歩きの手間、紛失時のリスクがあるため、一般的には追加で購入する必要は低いです。

ログイン画面で「セキュリティキーを使用」を選んだ場合、物理キーがない環境では、内蔵のTouch IDやインストール済みの1Passwordなどが応答します。

SNS認証(OAuth) — 主要認証の代替

Facebook、X(旧Twitter)、LINE、Google、AppleなどのSNSログインを経由したログインです。
OAuth(およびOpenID Connect)というプロトコルを使った認証手段で、これまでに挙げた2要素目の手段とは異なり、ID・パスワードに代わる主要認証(1要素目)の選択肢として提供されます。
主要認証として並ぶ手段にはほかに、メール経由のマジックリンク(クリックするだけでログインできる一時URL)や、法人向けのSAML SSOなどがあります。

同一サービスに対して過去にログインしたSNSと異なる手段を使うと、別アカウントとして扱われてしまい、購入履歴やポイントなどが分散されてしまいます。各サービスごとにログイン方法を1つに固定して使い、1Passwordの該当サービス(メモ欄など)にログイン方法を控えておくことが有効です。

認証手段ごとの強度の違い

各方式は、突破されにくさやフィッシングへの耐性に違いがあります。最も耐性が高いのはパスキーと物理セキュリティキー(FIDO2方式)で、ドメイン名そのものが暗号計算に組み込まれるため、偽サイトでは認証自体が成立しません。

これに対し、認証アプリ(TOTP)・プッシュ通知・メール・SMSは、利用者が偽サイトでコード入力や承認をしてしまうと突破される余地があり、特に通信網を介するSMS認証はもっとも弱い位置付けです。SNS認証(OAuth)は性質が異なり、強度はSNS側のアカウント保護状況に依存します。

パスキーの仕組み

パスキーは、サービス側のサーバーに登録される公開鍵と、利用者のデバイス側に保管される秘密鍵のペアによって成り立つ認証方式です。利用者が文字列を覚えたり入力したりする必要がない代わりに、デバイス側で暗号計算を行うことで本人性を証明します。

パスキー(秘密鍵)の実態

パスキー(秘密鍵)は暗号鍵としてのバイト列です。実装上はECDSA(楕円曲線暗号、P-256)が使われており、鍵の長さは256ビットです。文字列ではないため、人間が見たり、覚えたり、入力したりする対象ではありません。アプリやOSが内部的に取り扱う対象であり、利用者は鍵を保管するデバイスやプロバイダを選んだうえで、認証の際は本人確認(生体認証やPIN)を行うだけの仕組みです。

公開鍵と秘密鍵の保管場所

公開鍵と秘密鍵は、それぞれ異なる場所に保管されます。役割と保管場所を整理すると次のようになります。

鍵の種類	保管場所	役割
公開鍵	サービス側のサーバー	受け取った署名を検証する。
秘密鍵	利用者のデバイス内(iCloudキーチェーン、1Passwordのボルト、物理キー本体など)	認証時に署名を生成する。デバイス外には出ない。

サービス側のサーバーは、秘密鍵がどこに保管されているかを知りません。「公開鍵に対応する秘密鍵を持つ利用者が、認証のたびに送られるチャレンジに署名できればログインを許可する」という考え方に基づいています。秘密鍵自体はネットワーク上を流れず、デバイス内部にとどまります。

パスキーが生成されるタイミング

パスキーは、以下の流れで利用者のデバイス内で新規生成されます。

サービス画面でパスキーを追加する
ブラウザがWebAuthn API経由で、OSにパスキー作成を依頼する
OSが「保存先を尋ねるダイアログ」を表示し、利用者がプロバイダを選ぶ(1Passwordなど)
選ばれたプロバイダが秘密鍵と公開鍵のペアを生成する
秘密鍵はプロバイダに保管され、公開鍵だけがサーバーに送信される

鍵は作成の際に選択されたプロバイダへ保存され、それ以降、同じ公開鍵と秘密鍵(キーペア)を繰り返し利用します。

認証フロー(チャレンジと署名)

ログイン時の動作は、おおむね次のような流れになります。

サーバーがランダムな値(使い捨てのチャレンジ)を生成して、ブラウザ経由でデバイスに送る(通常16〜32バイト程度)
デバイス内のプロバイダが、本人確認(生体認証やPINなど)を経たうえで、秘密鍵を使ってチャレンジに電子署名する
署名がブラウザ経由でサーバーに送られる(秘密鍵そのものはデバイスのプロバイダから外に出ない)
サーバーが公開鍵を使って署名を検証する。整合していれば認証成功

チャレンジは毎回異なる値が使われるため、過去の通信を傍受して署名データを盗んだとしても、次回の認証には使えません。このフローは鍵が手元のデバイスに保管されている場合は、ブラウザとOSとプロバイダの間でローカルに完結します。

クロスデバイス認証

別のデバイス(例えばiPhone)に保管されたパスキーを、作業中のデバイス(例えばMac)で借りて使う仕組みです。MacのSafariでパスキー認証を試みたとき、QRコードが表示され、iPhoneのカメラで読み取ることで認証を成立させるフローです。仕様上の通信方式名は hybrid transport と呼ばれ、BLE(物理的な近接確認)と中継サーバー(データ通信)を組み合わせて成立します。

1Password を Mac と iPhone の両方で使っている環境では、両端末に同じパスキーが同期されているため、クロスデバイス認証が必要になる場面は通常ありません。MacのSafariでQRコードのダイアログ(macOS純正のパスキーUI)を目にすることはありますが、これはApple純正側の規定の動作で、Mac側の1Passwordから直接ログインを完了できる場面ではダイアログを閉じて構いません。

プロバイダとFIDO2の関係性

プロバイダの動作を支えているのが、FIDO Alliance と W3C が共同で策定しているFIDO2と呼ばれる規格群です。FIDO2には、ブラウザがJavaScript経由でパスキー機能を呼び出すためのAPIであるWebAuthnとブラウザとプロバイダ(物理キーなど)の間の通信プロトコルであるCTAP2が含まれています。

WebAuthn、FIDO2、パスキーという言葉は、文脈によってほぼ同じものを指して使われていることが多いものの厳密には階層が異なります。FIDO2が規格全体の総称で、WebAuthnはその中のブラウザ向けJavaScript API、CTAP2はブラウザとプロバイダの間の通信プロトコル、パスキーは利用者向けの呼称という関係になります。

1PasswordとiCloudキーチェーン

Mac・iPhone環境で使えるパスキーのプロバイダとして、主にiCloudキーチェーンと1Passwordの2つが選択肢になります。

iCloudキーチェーンと「パスワード」アプリの関係

iCloudキーチェーンは、Apple IDにより紐付けられたApple機器間でパスワード・パスキー・クレジットカード番号などが同期される仕組みです。iOS 18 / macOS Sequoia 以降ではパスワードアプリ経由で中身を操作しますが、データの実体はiCloudキーチェーンと同じです。

1Passwordの特徴

1Passwordは、Mac、iPhone、Windows、Linux、Android、各種ブラウザ拡張といった複数のプラットフォームに対応しており、同じボルト(資格情報の保管庫)を環境をまたいで利用できます。同期は1Passwordのアカウントに紐付いており、パスワードのほかにパスキー、TOTP、SSHキー、APIシークレット、メモなどを統合的に扱えます。

ドメインのチェックが厳密なつくりになっていて、登録時とまったく同じドメインでないとオートフィル候補を出しません。これによって似たドメインの偽サイトでは候補が表示されないため、結果的にフィッシング対策としても機能します。

iCloudキーチェーンの特徴

iCloudキーチェーンはApple機器であれば追加のアカウントなしに使えて、OSとの親和性が高いです。Apple IDとの紐付けで自動的に同期されるため、設定の手間もなく、Apple純正のアプリやSafariの自動入力との連携が標準で組み込まれています。

ただし、Windows・Android・Linuxなどの他のプラットフォームには対応しておらず、機能も限定的です。Apple製品以外を併用する環境では、機器をまたいだパスキーの利用に手間が発生します。

使い分けの方向性

1PasswordはMac・iPhone・Windows・Linux・Androidなどに対応するクロスプラットフォーム型で、TOTPやSSHキーまで統合的に管理でき、開発者・エンジニアからの支持も厚いという特徴があります。iCloudキーチェーンはApple機器中心ですが、OSに純正で組み込まれているため追加の手間なしに使えます。

完全にApple機器のみで使うならiCloudキーチェーンでも十分回せますが、Apple以外のプラットフォームの併用や、より幅広い機能を活かしたい場合は1Passwordが選択肢になります。1Passwordはサブスクリプション制で月数百円〜千円程度の費用が発生するため、機能面とコストのバランスをどう見るかが分かれ目です。

Touch ID と Face ID の役割

Touch ID(指紋認証)とFace ID(顔認証)は、iPhoneやMacに搭載されているApple製チップ内のSecure Enclaveというセキュリティ領域で扱われます。生体情報はチップから外には出ず、クラウドにも同期されないため、新しい機器に乗り換えた場合は、機器ごとに改めて登録が必要になります。

Touch IDやFace IDは、利用される場面によって、いくつかの異なる役割を担います。

パスキー認証時の本人確認(秘密鍵で署名する許可を出すスイッチとして働く)
パスワード保管庫(1PasswordやiCloudキーチェーン)の解錠時の本人確認
デバイス本体のロック解除(iPhoneのロック画面解除、Macのスリープ復帰時など)

「鍵そのもの」(秘密鍵やパスワード)は別の場所(iCloudキーチェーン、1Passwordのボルト、Secure Enclave内のパスキー領域など)に保管されていて、Touch IDやFace IDは、その鍵を取り出して使うための許可を与える役割を担います。鍵を扱うための入口、というイメージで捉えると整理しやすくなります。

認証時に求められる本人確認は、FIDO2の仕様では「ユーザー検証(User Verification)」と呼ばれ、生体認証だけに限らず、PIN・デバイスパスコード・物理タップなどでも代替できます。Touch IDセンサーがないMacや古いiPadでも、デバイスパスコードを使ってパスキー認証を完結させることができます。

パスキーの運用で意識しておきたいこと

ここまでの仕組みを踏まえて、日常運用の中で意識しておくと運用が安定しやすくなる点をまとめます。

作成時の保存先確認

新しいサービスでパスキーを作成するとき、保存先を尋ねるダイアログが表示されます。1Passwordに集約する方針であれば、このダイアログで1Passwordを選んで進めます。サービス側のパスキー一覧にはAAGUIDをもとに[Apple][1Password]のようなラベルで表示されるため、後から保存先がどちらなのかは一目で確認できます。

同じサービスに複数のパスキーが登録される場合

WebAuthnの仕様の上では、同じサービスに対して、異なるプロバイダで作成した複数のパスキーを並列に登録しておくことが可能です。たとえば1回目に1Passwordで作成し、2回目にiCloudキーチェーンでも作成すると、サービス側に2つの公開鍵が登録された状態にできる場合があります。

複数登録できるサービスでは、ログイン時に両方が候補として並ぶため、毎回どちらを選ぶかを判断する手間が増え、整理するときに誤って現役側を削除してしまう余地もあります。いずれの場合も、運用上は保管先を1つに絞っておくと、見通しがよくなります。

サービス側に登録があるが、対応する秘密鍵が見つからないとき

パスキーは1つのサービスに対して複数登録できる仕様ですが、過去に売却・初期化したデバイスで作成したパスキーが手元のどのプロバイダにも残っていない、別のプラットフォームで作成して同期されていない、などの理由で「サーバー側にパスキー登録は残っているが、対応する秘密鍵がアクセス可能な範囲にない」状態になることがあります。

この場合、不要になったパスキーの登録を削除して新規に作り直したくなりますが、サービスによっては利用者が自分で削除する手段がなく、サポートに連絡してサーバー側で削除してもらう必要があります。例えばメルカリでは、削除依頼の際に運転免許証等の本人確認書類の提出を求められることがあり、対応に数日を要する場合もあります。サポートの対応待ちの間も、メール+パスワードや既存のSNSログインなどでログインは継続できるためアカウントが完全に使えなくなるわけではありませんが、新規作成時に保存先(プロバイダ)を確認しておくことが、こうした手間を未然に防ぐ最善の方法になります。

1Password中心の運用に揃える手順 — iPhone・Mac の設定

1Passwordユーザーがパスワード・パスキー・TOTPのすべてを1Passwordに集約して運用するための設定を確認しつつ、競合を避けるためにiCloudキーチェーン側の自動入力を抑える手順をまとめます。

iPhoneでの設定

主な設定は[設定]-[一般]-[自動入力とパスワード]から確認可能です。

パスワードとパスキーを自動入力
- パスワード・パスキー・確認コードの自動提案機能全体のオン・オフを制御します。
- 1Passwordを使う場合はONにしておきます。
自動入力の取得元
- ログイン時に自動入力を提供するアプリ(プロバイダ)を選ぶ項目で、複数選択が可能です。
- 1PasswordをON、Apple純正のパスワードアプリをOFFにします。
  - 複数の候補が表示されるのを防ぎます。
確認コードを設定するアプリ
- 2要素認証の設定リンク(otpauth://スキーム)や設定用QRコードを開いたときに、TOTPの保存先となるアプリを1つ選ぶ項目です。
- デフォルトはApple純正のパスワードアプリの可能性があるため、1Passwordを選択し、TOTPを集約するように変更します。

Google Authenticator、Microsoft Authenticator、Duo MobileのようなTOTP専用アプリは、パスワード・パスキーの自動入力には対応していないため自動入力の取得元の選択肢には存在しません。

Macでの設定

主な設定は[システム設定]-[一般]-[自動入力とパスワード]から確認可能です。ただしMacには macOS 固有の事情があり、OS標準の自動入力の取得元一覧に1Passwordが現れない設計のため(詳細は本節末の補足を参照)、iPhoneとは反対方向の設定が必要になります。さらに、Safari上でWebAuthn(パスキー)が呼び出されたとき、Apple純正のパスキーUIが前面に出てくる挙動を完全には抑止できません。1Passwordを含む3rd partyのプロバイダは、Apple純正UIを置き換えるのではなく並列で動作する位置付けです。

パスワードとパスキーを自動入力
- macOS標準の自動入力機能のオン・オフを制御するトグルです。
- 1Password中心の運用ではOFFにしておきます。
  - ログイン時の自動入力候補がiCloudキーチェーン側から出なくなり、候補が1Password側だけに揃います。
Universal Autofill(ネイティブアプリ向け)
- Slack や Spotify、Discord など Mac 上のネイティブアプリに1Passwordから値を入れるための機能です。
- [システム設定]-[プライバシーとセキュリティ]-[アクセシビリティ]で1Passwordをオンにしておきます。
  - ログイン入力欄にカーソルを置いた状態で Cmd + \ を押すと、1Passwordから候補が呼び出せます(Safari上ではこの操作は通常不要で、拡張機能側が反応します)。

新規パスキー作成時は、保存先を尋ねるダイアログが表示され、iCloudキーチェーンや1Passwordなどから明示的に選択できます。サービス側のパスキー一覧には、AAGUID をもとに「Apple」「1Password」のようなラベルで表示されます。

Mac のシステム設定の「自動入力の取得元」一覧には1Passwordが表示されず、Apple純正の「パスワード」のみが並びます。これは設定不備ではなく、1Password が macOS の標準自動入力ではなく独自の経路で動作する設計のためで、Mac 上で1Passwordを使う場合は Safari拡張機能とアクセシビリティ権限の経路で動作します。

補足: Safariで1Passwordの自動入力が効かないサイトがあるとき

サイトによっては、入力欄にカーソルを置いても1Passwordのオートフィル候補が表示されないことがあります。原因は大きく2パターンに分かれますが、日常的に遭遇するのはほぼ2番目のケースです。

1つ目は、1Passwordがそのサイトを認識していない(エントリ自体を提示しない)ケースです。
1Passwordはドメインを厳密に照合する設計になっており、登録時のドメインと一致しないサイトでは候補を出しません。これは似たドメインのフィッシングサイトで誤って入力するのを防ぐためのセキュリティ機能で、意図された挙動です。サービス側のドメインが変わった、フィッシングサイトに誘導されている、登録時とは別ドメインのログイン画面に来ている、といった場面で発動するもので、通常の利用ではあまり遭遇しません。

2つ目は、1Passwordがサイトを認識している(拡張アイコンをクリックすると該当エントリが出る)のに、入力欄に候補が提示されないケースです。
これは1Passwordがページ上のフォームフィールドの検出に失敗している状況で、サイト側の作り方やSafari拡張機能の制約に起因します。実運用で遭遇する大半はこちらです。主な原因としては、ログインフォームがiframe(別ドメインの埋め込み)内にある、Shadow DOMでフォームが隠されている、JavaScriptでフォームが動的に生成されている、入力要素のtype属性やname属性が変則的になっている、サイトが autocomplete="off" を指定している、Safari拡張機能のサイト権限が制限されている、といったことが挙げられます。

回避策としては、入力欄を一度クリックしてフォーカスを当ててから Cmd + Shift + X で1Password拡張を呼び出す、拡張機能アイコンから手動でコピーして貼り付ける、[Safari]-[設定]-[拡張機能]-[1Password]-[ウェブサイト]で対象サイトの権限を「許可」に変更する、1PasswordおよびmacOSを最新版に更新する、といった方法があります。Chromeの1Password拡張はSafariよりもAPI制約が緩いぶん自動入力の対応範囲が広い傾向があり、利便性を優先する場合は主に使うブラウザを切り替えるという選択肢もあります。

さいごに

パスワード関連の用語や考え方が複雑になったと感じたので、自分の中で整理する目的で今回まとめてみました。仕組みを把握しておくと、正常にログインできない場面でも落ち着いて対応できるようになります。

利用するサービスが増えるほど煩雑になっていきますが、定期的に保存先(プロバイダ)の状況を確認して、パスキーの管理もしていきたいと感じました。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up