QRコードのログイン方法と認証

安全で便利な認証方法は、これまで以上に重要になっています。私たちが毎日さまざまなデバイスでアクセスするオンラインサービスの数が増えるにつれて、従来のパスワードベースのシステムは効果が薄れ、より面倒なものになっています。特に、ネイティブアプリ（iOSやAndroidアプリ）に多くのユーザーを抱える企業にとって、この状況はQRコードベースのログインへの需要を高めています。QRコードを使えば、複雑なパスワードやユーザー名を入力する必要なく、迅速かつ簡単にユーザーを認証できます。

このような背景から、次のような疑問が浮かび上がります。

• ネイティブアプリを使ったQRコードベースの認証はどのように機能するのか？
• パスキーを使ったQRコードベースの認証とどう違うのか？

Native QR Code Revolut

Passkeys QR Code Apple

ネイティブアプリのログインでQRコードを使用する著名な例としては、WhatsApp、TikTok、Revolutなどのアプリファーストのサービスが挙げられます。同時に、パスキーログインをサポートする企業のリストも急速に増えています。

この記事では、QRコードベースの認証技術について探ります。ただし、二要素認証の初期設定に使用されるTOTP QRコード（AuthyやGoogle Authenticatorなどの追加アプリで使われるもの）については扱いません。

また、さまざまなQRベースの認証方法を比較し、それぞれの長所、短所、そして潜在的な脆弱性を検証します。

この記事を読み終える頃には、QRコードベースの認証があなたのセキュリティニーズに適した選択肢であるかどうか、より明確に理解できるでしょう。

QRコード（Quick Response code）は、URLからプレーンテキストまで、さまざまな情報を保存できる二次元バーコードです。元々は1994年にトヨタグループの子会社であるデンソーウェーブが、自動車部品を迅速かつ効率的に追跡するために開発しました。以来、QRコードは小さな正方形に大量のデータを保存できる能力から進化を遂げ、さまざまな業界でその地位を確立しました。

「QRコード」という言葉は、実はデンソーウェーブの登録商標ですが、技術自体は広く採用されており、商標による制約はありません。QRコードは白黒の正方形パターンが特徴で、スマートフォンや専用のスキャンデバイス（QRスキャナー）でスキャンすることで、エンコードされた情報にアクセスできます。

QRコードのサポートは、iOSやAndroidなどのモバイルOSに数年前から統合されています。両プラットフォームとも、それぞれのカメラアプリを通じてQRコードのスキャンをネイティブにサポートしており、ユーザーは追加のソフトウェアなしで簡単にQRコードを操作できます。

Subscribe to our Passkeys Substack for the latest news.

Subscribe

一般的に、アプリと連携して使用されるQRコードは、カスタムURLやアプリリンクを活用します。これらのリンクは、デバイスにアプリがインストールされていれば、アプリを自動的に開くようにトリガーできます。アプリがインストールされていない場合、QRコードはユーザーを関連するアプリストアに誘導してアプリをダウンロード・インストールさせることができ、スムーズなユーザー体験を促進します。以下は、Revolutがアプリハンドリングのために登録しているパスのリストです。

https://revolut.com/.well-known/apple-app-site-association
{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "QUZEZSEARC.com.revolut.revolut",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.test",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.retail.india",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.retail.india-debug",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.invest",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.invest-debug",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.revolutx",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.revolutx-debug",
                "paths": ["/app/*"]
            }
        ]
    }
}

ご覧の通り、「/app/*」で始まるすべてのリンクが処理されます。次のセクションでその例を見ていきましょう。QRコード内にカスタムURLやアプリリンクを埋め込むことで、企業や開発者はユーザーを目的のアプリやサービスに直接誘導するカスタマイズされた体験を作り出し、ユーザーインタラクションにおける利便性とセキュリティの両方を向上させることができます。

ネイティブアプリ経由のQRコードログインは、モバイルデバイスのカメラとQRコードに埋め込まれた特定のURLとのシームレスな連携を活用します。このプロセスは通常、ユーザーがウェブサイトや他のデバイスに表示されたQRコードをスマートフォンのカメラでスキャンすることから始まります。QRコードには、iOSやAndroidデバイスにあるような特定のネイティブアプリと連携するように特別に設計されたカスタムURLが含まれています。

例えば、Revolutのようなサービスは、https://revolut.com/app/challenges/qr/e2d78521-d38a-4773-b1b8-27a902a36b4bのようなURLを持つQRコードを使用するかもしれません。このURLは、ユーザーのデバイスにインストールされているRevolutアプリによって認識されるように設定されています。

QRコードがスキャンされると、アプリはこのリンクを自動的にキャッチして認識し、対応するアプリを表示して（上の例では「Revolut」が一致するアプリとして識別されています）、内部でログインプロセスを処理します。このインタラクションは、iOSとAndroidの両方がサポートするディープリンクメカニズムによって促進されます。これにより、特定のリンクがウェブブラウザではなく、インストールされたアプリ内で直接開くことができます。

デバイスにアプリがインストールされていない場合、OSは通常、ユーザーを適切なアプリストア（iOSデバイスの場合はApple App Store、Androidデバイスの場合はGoogle Play Store）にリダイレクトしてアプリのインストールを促します。

これにより、ユーザーが最初にアプリをインストールしていなくても、迅速かつ簡単に入手し、インストール後にプロセスを続行できます。

ほとんどの場合、すでにアプリをインストールしている既存の顧客は、スムーズなログインプロセスを体験できます。QRコードをスキャンすると、アプリが自動的に開き、ユーザー名やパスワードを入力することなく認証が完了します。この方法では、QRコードのスキャンプロセス中に機密情報が送信されないため、主にユーザーの利便性が向上します。

技術的には、携帯電話でログイン済みのセッションを使用して、デスクトップ上の新しいセッションを認証するということが起こっています。これを実現するための技術はいくつかあります。非常に精巧なバージョンは、WhatsAppのセキュリティホワイトペーパーの「Client Registration → Companion Device Registration → Link Using QR-Code」の項で公開されています。

出典：https://engineering.fb.com/2021/07/14/security/whatsapp-multi-device/

WhatsAppは2021年からマルチデバイスアクセスとエンドツーエンド暗号化をサポートしていますが、このプロトコルは主にマルチデバイスメッセージングアプリケーション用に設計されているため、アーキテクチャは認証には完全には適していません。実際の認証実装によっては、安全なハンドシェイクを実現するためのよりシンプルなアプローチがあります。留意すべき点は、ユーザーセッションの安全な処理と、デバイスとサーバー間の通信チャネルを常に確保する必要があるということです。QRコード認証ログインの実装の複雑さに関わらず、いくつかの重要なセキュリティ原則は常に遵守されるべきです。

1. セッションの完全性：デスクトップや他のデバイスで新しいセッションを認証するために使用される、携帯電話上の既存のログイン済みセッションは、安全に検証されなければなりません。これには通常、セッションハイジャックやリプレイ攻撃を防ぐために、安全なトークンやその他の暗号化手法を使用してセッションの信頼性を確認することが含まれます。
2. 暗号化された通信：モバイルアプリ、サーバー、および認証を要求するデバイス間のすべての通信は、HTTPSを使用して暗号化する必要があります。これにより、セッショントークンやログイン詳細などの機密情報が送信中に傍受されたり改ざんされたりするのを防ぐことができます。
3. 安全なトークン生成：QRコード認証プロセス用に生成されるトークンや認証情報は、安全に生成されるべきです。これには、予防措置として他のデバイスで使用できないように、要求元のデバイスに固定すること（例：ブラウザエージェント）が含まれる場合があります。
4. ユーザーによるログイン確認：認証プロセスを完了する前に、ユーザーがログイン試行を確認または承認できるステップを設けることをお勧めします。これは、モバイルデバイス上の通知でユーザーの承認を求め、認証の詳細を表示する形式をとることができ、セキュリティの層をさらに追加します（上のスクリーンショットで見られるように）。
5. 時間ベースの制限：QRコードが第三者の手に渡った場合に不正アクセスに使用されるリスクを最小限に抑えるため、QRコードの有効性に時間ベースの制限を実装します。QRコードを使用できる時間枠を制限することで、潜在的なセキュリティ脅威を減らすのに役立ちます。自動的に更新され、中間者攻撃を避けるために最大有効期間は120秒未満であるべきです。
6. 位置情報ベースの制限：「ありえない移動（impossible travel）」の検出など、ログイン試行に関する制限もQRコードで実施されるべきです。これには、不審なIPベースのインテリジェンスに基づいてログイン試行を自動的に遮断することが含まれる場合があります。例えば、アメリカでQRコードを生成し、ヨーロッパで認証のためにアプリが開かれるような場合です。
7. レート制限、ログ記録、監視：QRコードログインに関連する不審なアクティビティを検出して対応するために、適切なレート制限、ログ記録、監視を実装します。これにより、潜在的なセキュリティ侵害を特定し、ユーザーアカウントを保護するためのタイムリーな措置を講じることができます。
8. ユーザーへの通知：新しいデバイスでのログインが成功した場合、ユーザーに重要な情報（ログインが試行された日時、場所、デバイス、IPアドレスなど）と、ログインがユーザーによってトリガーされなかった場合の対処法（サービスの即時連絡、アカウントの監視、システムがサポートしている場合はすべてのログイン済みデバイスの削除など）を記載したメール通知を送信すべきです。

これらのベストプラクティスに従うことで、企業はユーザーフレンドリーで安全なQRコードベースの認証を実装し、モバイルデバイスの利便性を活用しながら、ユーザーデータとセッションを保護するための堅牢なセキュリティ対策を維持できます。

Become part of our Passkeys Community for updates & support.

Join

次に、パスキーによるQRコードログインを見てみましょう。

パスキーベースの認証は、iOSおよびAndroidエコシステムに統合され、WebAuthn標準で規定されている、安全なクロスデバイス認証システムを提供します。現在、QRコードを介したクロスデバイス認証（CDA）に使用できるのは、iOSまたはAndroidで作成されたパスキーのみです。

パスキーによるQRコードログインがどのように機能するかを分析してみましょう。以下の図は、さまざまなステップの概要を示しています。

iOSとAndroidの両方で、パスキーはプラットフォームのネイティブなオーセンティケーター（例：Face ID、Touch ID、Android生体認証）内に保存されます。これにより、ユーザーのパスキーは、同じApple ID（iOSの場合）またはGoogleアカウント（Androidの場合）でログインしているすべてのデバイスで、最新のOSバージョンで利用可能になります。

• 両方のデバイスがアクティブなインターネット接続を必要とする：認証プロセスに関与する両方のデバイスは、アクティブなインターネット接続が必要です。これは、認証プロセス中にデータを同期し、資格情報を検証するために不可欠です。
• 両方のデバイスがBluetoothをサポートする必要がある：両方のデバイスがBluetoothをサポートし、Bluetoothが有効になっている必要があります。Bluetoothはデバイス間の近接性を確立するために使用され、認証中にデバイスが互いに近くにあることを保証し、それによって遠隔地からのフィッシングのリスクを軽減します。

• デバイスに紐づいたデスクトップパスキー：デバイスに紐づいており、デスクトップ上にあるパスキー（例：Windowsプラットフォーム上）は、QRコードベースのCDAの対象外です。
• Bluetoothへの依存：Bluetoothに依存することは、接続性の問題や、Bluetoothの近接チェックを妨げる可能性のあるデバイス設定のために、時として欠点となることがあります。近接性を確立することはセキュリティを強化できますが、デバイスがBluetooth経由で接続に失敗した場合、ユーザビリティの課題を引き起こす可能性もあります。ただし、一度デバイスが正常にペアリングされると、その後の接続は通常より簡単になります。

Discuss passkeys news and questions in r/passkey.

Join Subreddit

• リモートフィッシング攻撃がない：近接チェックにBluetoothを使用することで、認証プロセス中に両方のデバイスが物理的に近くにあることが保証され、遠隔地からのフィッシング攻撃のリスクが軽減されます。
• 同期されたパスキーがより良いUXを提供：デバイス間でパスキーが同期されることで、ユーザーは複数の認証情報を管理する必要がなくなり、シームレスなユーザー体験が提供されます。

パスキーベースのクロスデバイス認証（CDA）を実装する際には、プロセスについてユーザーに明確なガイダンスを提供することが重要です。ユーザーには、QRコードが表示されること、そしてそれをスキャンするために携帯電話を使用する必要があることを知らせるべきです。

私たちの意見では、ユーザーがCDAに利用できるパスキーを持っていない場合にQRコードが表示されないようにすることが重要です。さらに、QRコードを表示する前に、ユーザーの現在のOSとブラウザがCDAをサポートしていることを確認する必要があります。

Want to find out how many people use passkeys?

View Adoption Data

これらのシナリオを効果的に管理するために、私たちはこの記事で全ての重要なケースを概説しましたので、ここでは詳細には触れません。私たちのパスキーインテリジェンスシステムは、これらの状況を自動的に処理するように設計されており、QRコードが適切な場合にのみ表示され、ユーザーを認証プロセスを通じてスムーズに案内します。これにより、さまざまなデバイスやOS間で高いセキュリティと互換性を維持しながら、シームレスな体験が保証されます。

このセクションでは、この記事で説明した2つの主要なQRコードベースのログイン方法、すなわちネイティブアプリ経由のQRコードログインとパスキー経由のQRコードログインを要約します。各方法には独自の利点があり、セキュリティ、ユーザーエクスペリエンス、実装の複雑さなどの要因に基づいて、さまざまなユースケースに適しています。

• ネイティブアプリ経由のQRコードログインは、ディープリンクを活用してQRコードをモバイルデバイスにインストールされた特定のアプリに接続します。ユーザーがQRコードをスキャンすると、関連するアプリがトリガーされ、シームレスで安全なログインプロセスが促進されます。この方法は、WhatsApp、TikTok、Revolutなどのアプリファーストのアプリケーションで一般的に使用されており、ユーザーはアプリ環境に慣れており、パスワードを入力することなく簡単に認証できます。
• パスキー経由のQRコードログインは、OSのプラットフォームオーセンティケーターと直接統合する、より高度なクロスデバイス認証アプローチを利用します（ネイティブアプリをインストールする必要はありません）。この方法は、同期されたパスキーを使用し、認証プロセス中に両方のデバイスが近接していること（Bluetooth経由で検証）を要求することで、高いレベルのセキュリティを提供するように設計されています。この方法は、フィッシング攻撃に対する強力な保護を提供し、複数のデバイス間で合理化されたユーザーエクスペリエンスを提供します。

両方の方法がどのように比較され、異なる特性を持つかを見てみましょう。

比較表：ネイティブアプリ経由のQRコードログイン vs. パスキー経由のQRコードログイン

比較表では認証ベースの特性に焦点を当てており、セクション3で概説した周辺要件は両方の選択肢に適用されます。パスキーはWebAuthnを介してフィッシング耐性と近接チェックを採用しているため、位置情報ベースおよび時間ベースの制限は不要です。

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

冒頭で概説したように、私たちはクロスデバイス認証の最も一般的な2つのシナリオを詳しく見てきました。それらを簡単に要約しましょう。

• ネイティブアプリ経由のQRコードログインは、ネイティブアプリに強力なユーザーベースを持ち、まだパスキーの実装を検討しておらず、フィッシング攻撃についてあまり懸念していない企業に最適です。この方法は、アプリの既存の認証メカニズムを使用することで利便性とセキュリティを提供し、アプリを頻繁に使用するユーザーの摩擦を減らしますが、頻繁でないアプリのログインには役立ちません。
• パスキー経由のQRコードログインは、特にクロスデバイス認証が必要で、パスキーも検討中または認証要素として既に使用されている環境において、より安全で柔軟なオプションを提供します。プラットフォームレベルの認証とBluetoothベースの近接チェックを活用することで、この方法は将来性のある唯一のフィッシング耐性多要素認証をクロスデバイスのケースにももたらします。

冒頭の質問に答えるために：

• 2つのアプローチの違いは何か：各組織は、ユーザーベース、セキュリティ要件、および望ましいユーザーエクスペリエンスなどの要因を考慮して、自社のニーズに最も適した方法を選択すべきです。アプリ中心のサービスの場合、ネイティブアプリ経由のQRコードログインを統合するだけで十分かもしれません。しかし、最大限のセキュリティ、クロスデバイス機能を優先する場合は、パスキー経由のQRコードログインが堅牢なソリューションを提示します。

どのソリューションが既存の認証アーキテクチャに適合するかの現在の評価に関わらず、パスキーは認証の未来への投資であることを心に留めておくべきです。エコシステムが明らかにこの方向に動いているからです。早期にパスキーの収集を開始することは、さまざまなCDA戦略と組み合わせることができます。