3. フォーカス・リサーチ（2）クロスデバイスフローによる認証・認可 | Internet Infrastructure Review（IIR）Vol.59 | IIJの技術

目次

3. フォーカス・リサーチ（2）

クロスデバイスフローによる認証・認可

3.1 はじめに

スマートフォンの急速な普及と機能の進化は、私たちの暮らしに大きな変化を与え続けています。現在では、日常のあらゆる場面でスマートフォンが活用されるようになりました。インターネット上のサービスを安全に利用する上で欠かせない、認証・認可の手続きも例外ではありません。本稿では、近年、注目を集めている、スマートフォンを活用したクロスデバイスフロー（Cross-Device Flow（注1））と呼ばれる認証・認可方式について解説します。

クロスデバイスフローとは、あるサービスを利用する端末（PCやスマートテレビなど）と、その利用のための認証・認可を行う端末（スマートフォンなど）が分かれている認証・認可方式のことです。例えば、「スマートテレビ上で動画配信サービスを利用したい。しかし、テレビのリモコンではユーザIDやパスワードが入力しづらいので、サインイン手続きをスマートフォンで代わりに実行する」といった例が挙げられます。

このケースでは、「入力インタフェースに制約がある端末でサービスを利用したい」という課題をクロスデバイスフローで解決しています。この他にもクロスデバイスフローが必要とされる場面は数多くあり、例えば、「共用端末や公共端末など、機密情報の入力を避けたい端末でサービスを利用したい」「既存の認証・認可フローに多要素認証を追加したい」「複数の端末で同じ秘密鍵を用いた認証・認可を行いたいが、秘密鍵のコピーは避けたい」といったように幅広い活用方法が提案されています。

クロスデバイスフローを実現するための標準仕様は策定中のものを含め複数あり、それぞれユースケースが異なります。以下がその代表的な仕様です。それぞれ詳しく見ていきましょう。

OAuth 2.0 Device Flow
OpenID Connect CIBA Flow
OID4VPのCross Device Flow
SIOPv2のCross-Device Self-Issued OP
CTAP v2.2のHybrid transports

3.2 OAuth 2.0 Device Flow

OAuth 2.0 Device Authorization Grant（RFC8628）（注2）はOAuth 2.0の認可フローの1つです。IETFによって2019年に標準化されました。一般にDevice Flowと呼ばれます。スマートテレビやデジタルフォトフレーム、プリンタなど、ユーザからの入力に制約があるデバイス上で実行するアプリケーションを、別デバイスで補助することを目的に設計されたクロスデバイスフローです。前節で紹介したスマートテレビで動画配信サービスアプリケーションを利用するケースは、まさにDevice Flowの代表的な使用例です。

Device Flowは認可のフローであり、クライアントアプリケーションがサービス（通常、APIとして提供される）を利用するためのアクセストークンを、認可サーバに発行してもらうためのプロトコルです。認証のフローではないので、Device Flowの仕様の範囲には、クライアントアプリケーションがエンドユーザを認証する機能（IDトークンの発行など、エンドユーザを識別する機能）は含まれていません。認証も行いたい場合は、OpenID Connectなどと組み合わせて実装する必要があります。

図-1はDevice Flowによる認可フローの例です。OAuth 2.0 では、サービスを利用するアプリケーションをクライアント、承認を行うアプリケーション（通常はWebブラウザ）をユーザエージェントと呼びます。

図-1 Device Flowによる認可フローの例

エンドユーザが対象デバイス上のクライアントを起動します。
クライアントは認可サーバに対し、認可リクエストを送信します（a）。
認可サーバはそのレスポンスとして、デバイス検証コード（デバイスコード）、エンドユーザ検証コード（ユーザコード）、及びエンドユーザにアクセスしてもらう検証用URLを返します。
クライアントは受け取ったユーザコードと検証用URLを画面に表示します。検証用URLは通常、QRコードとして表示されます。
エンドユーザはスマートフォンなどでQRコードを読み取り（b）、検証用URLを取得します。
取得した検証用URLにユーザエージェントでアクセスします。認証が求められるので、サインインします。
サインイン後の画面に、ユーザコードが表示されます。（エンドユーザにユーザコードの入力を求めるパターンもあります）。
一方、クライアントは、エンドユーザがユーザエージェントを操作している間、認可サーバに対してアクセストークン取得リクエストの送信を繰り返します。リクエストにはパラメータとしてデバイスコードを含めます。
エンドユーザはクライアントが表示しているユーザコードとユーザエージェントが表示しているユーザコードが一致していること、及びその他の注意事項を確認の上、承認します（c）。
認可サーバはアクセストークンを発行し、アクセストークン取得リクエストに対するレスポンスとしてクライアントに返します（d）。

他のOAuth 2.0の認可フローとDevice Flowの大きな差異は、フロントチャネルの実現方法にあります。フロントチャネルとは、クライアントとユーザエージェント間の連携のことです。OAuth 2.0 Authorization Framework（RFC6749）（注3）で定義されているAuthorization Code FlowがOAuth 2.0の認可フローでは最もよく使われますが、Authorization Code Flowではフロントチャネルをリダイレクト（HTTPリダイレクト、もしくはディープリンク（iOSのUniversal LinksやAndroidのApp Links）のようなアプリケーション間連携の仕組みを用いたリダイレクト）によって実現します。しかし、クライアントとユーザエージェントが別デバイスで動作するDevice Flowではリダイレクトが使用できないので、代わりにQRコードの読み取りや目視と手入力などによるエンドユーザの仲介によって実現しています。

Device Flowのフロントチャネルの実現方法はシンプルで、特殊なハードウェアも不要な実装しやすいものである一方、セキュリティ的には強固とは言えない面があります。ソーシャルエンジニアリングや中間者攻撃によって、アクセストークンを詐取されたり、悪意のあるサイトに誘導される危険性が指摘されています。従って、Device Flowは機密性、重要性の高いデータへのアクセスを伴うクライアントでの使用は避けるべきとされています。

3.3 OpenID Connect CIBA Flow

OpenID Connect Client-Initiated Backchannel Authenti-cation Flow（注4）はOpenID Connectの認証・認可フローの1つで、略してCIBAと呼ばれます。OpenID Foundationによって2021年に標準化されました。CIBAもDevice Flow同様、サービスを利用するクライアントとその承認操作を別々のデバイスで実行可能とするクロスデバイスフローです。しかし、そのコンセプトは大きく異なります。Device Flowでは一人のエンドユーザが両方のデバイスを操作するケースがほとんどですが、CIBAはそれぞれのデバイスを別々のユーザが操作するケースを考慮して設計されています。これにより、CIBAは以下のようなユースケースを可能にします。

コールセンターの担当者が電話口の顧客の情報を取得するケース。担当者は顧客から聞いた会員番号を顧客管理システムで検索する。すると、顧客のスマートフォンに通知が飛び、個人情報を開示して良いか確認する旨のメッセージが表示される。顧客が承認してようやく、顧客管理システムは検索結果として顧客の情報を表示する。この仕組みにより、担当者が無断で顧客情報を閲覧するような情報漏えい事故を防げる。

店舗でのクレジットカード決済の承認に使用するケース。顧客が店舗で買い物をする際、レジにてクレジットカードで支払おうとすると、顧客のスマートフォンに通知が飛び、支払い内容の確認メッセージが表示される。顧客が承認すると決済が完了する。サインや暗証番号の入力などよりも確実な本人確認と同意取得が実現できる。

それでは、このような認証・認可をどのようにして実現しているか、CIBAの詳細を見ていきましょう（図-2）。まず、用語を整理しておきます。CIBAでは、クライアントを実行するデバイスを消費デバイス（Consumption Device）、エンドユーザが承認操作を実行するデバイスを認証デバイス（Authentication Device）と呼びます。認証デバイスは通常、スマートフォンです。なお、認証デバイス上で承認操作を行うアプリケーションを指す言葉はCIBAでは定義されていませんが、本稿では便宜上、これを認証アプリケーションと呼ぶことにします。また、CIBAはOpenID Connectの認証・認可フローなので、アクセストークンと共にIDトークンも発行するプロトコルです。これらを発行するサーバをOpenID Provider（OP）と呼びます。

図-2 CIBAによる認証・認可フローの例

クライアントがOPに対して、認証リクエストを送信します（a）。リクエストには、対象のエンドユーザを指定する識別子をパラメータとして含めます。
OPは認証リクエストに対し、レスポンスとして認証リクエストIDを返します。
OPはエンドユーザデータベースから、エンドユーザに紐付く認証デバイスを検索し、その認証デバイスに同意取得メッセージを送信します（b）。多くの場合、プッシュ通知（Apple Push Notification Service やFirebase Cloud Messaging）が使用されます。
同意取得メッセージを受信した認証デバイスは認証アプリケーションを起動し、画面にメッセージを表示します。
エンドユーザは同意するか拒否するか選択し、回答をOPに送信します（c）。
エンドユーザが同意した場合、OPはアクセストークンとIDトークンを発行します。
クライアントはトークンエンドポイントをポーリングし、トークンを取得します（d）。このときのリクエストにはパラメータとして認証リクエストIDを含めます。クライアントが通知用のエンドポイントを公開できる場合は、ポーリングせずにトークン発行時に通知を受信するオプションもあります。

なお、OPと認証デバイス間で行うやり取りのプロトコルは、CIBAの仕様では定義されていません。通信方法も転送するメッセージ仕様も実装者による設計に委ねられています。

CIBAがDevice Flowや後ほど触れる他のクロスデバイスフローと大きく異なるのは、フロントチャネルを使わず、バックチャネルのみで完結するフローである点です。バックチャネルとはクライアントとOP間、及び認証アプリケーションとOP間のやり取りを指します。クライアントと認証アプリケーション間の直接のやり取りがないので、先のコールセンターの例のように、消費デバイスと認証デバイスが地理的に離れたユースケースに対応できます。

もう1つ、CIBAの大きな特徴はクライアント主導型（Client-Initiated）の認証・認可フローであるという点です。他のOAuth/OpenID Connectのフローの場合、クライアントが任意のタイミングでエンドユーザのリソースにアクセスしようとすると、一度認証・認可を済ませた後、その後長期間、クライアントがトークンを保持し続けることになります。CIBAでは、クライアントからの要求があるごとに短期間有効なトークンを発行するという運用が可能になるので、より柔軟なリソース保護ができます。

このように、CIBAは他の認証・認可フローでは対応が難しいユースケースをサポートする貴重なフローです。特に金融業界から注目を集めており、OpenID Foundationが普及を図っているFAPI （金融などの強固なセキュリティを必要とする分野向けのOAuth/OpenID Connectのプロファイル）（注5）にも組み込まれています（注6）。

3.4 OID4VPのCross Device Flow

本節では、現在、OpenID Foundationによって策定が進められているOpenID for Verifiable Presentations（注7）（略して、OID4VPと呼ばれます）について解説します。まずは、OID4VPの前に、OID4VPが取り扱う対象であるVerifiable Credentialについて簡単に説明しておきましょう。

Verifiable Credential（VC）とは、検証可能なデジタル資格証明書のことです。例えば、パスポート、卒業証明書、社員証、等々を電子化したものです（注8）。発行者がデジタル署名を行い、第三者が検証できるようになっています。標準化されたVCの規格は複数あり、デジタル運転免許証用のISO/IEC 18013-5 Mobile driving licence（mDL）（注9）や汎用のデータ形式であるW3C Verifiable Credentials（注10）などがあります。

VCは通常、資格所有者のウォレットと呼ぶアプリケーションに格納します。しかし、mDLやW3C Verifiable CredentialsはVCのデータ仕様に過ぎないので、発行者から取得してウォレットに格納するプロトコルや、ウォレットから検証者に提示するプロトコルは定義されていません。これらのプロトコルの設計は実装者に委ねられています。例えば、医療情報用のVC（W3C Verifiable Credentials形式）を扱う仕様であるSMART Health Cards（SHC）（注11）はその一例です（ちなみに、デジタル庁が提供している新型コロナワクチン接種証明書アプリもSHCを採用しています（注12））。OpenID FoundationはVCの普及を進めるため、これらのプロトコルの標準化を進めています。VCを発行するプロトコルであるOpenID for Verifiable Credential Issuance（略して、OID4VCIと呼ばれます）（注13）とVCを提示するプロトコルであるOID4VPです。OID4VCIもOID4VPもVCのデータ仕様からは独立しており、mDLでもW3C Verifiable Credentialsでもその他の形式でも扱えるようになっています。

では、本節の主眼であるOID4VPについて見ていきましょう。そもそも、VCを提示する、とはどういうことでしょうか。例えば、お酒の購入に年齢確認を求められるシナリオを想像してください。物理的な身分証明書の場合は、実店舗で店員に対面で提示するようなケースです。一方、VCは電子データですから、対面である必要はありません。オンラインショッピングで利用できます。

酒店のWebサイトで酒類をカートに入れて、購入ボタンをクリックする。20歳以上であることを証明するVCを提示するよう求められる。
提示ボタンをクリックすると、ディープリンクによってウォレットが起動し、酒店にVCを提示して良いか確認するメッセージが表示される。
承諾するとリダイレクトで酒店のWebサイトに戻り、VCが酒店側に渡る。このとき、Selective Disclosureという仕組みにより、VCに含まれる生年月日以外の不必要な情報は渡さないようにできる。
酒店のWebサイトは取得したVCを検証し、年齢を確認し、20歳以上であれば購入を許可する。

上記は、OID4VPを実行するソフトウェアとウォレットが同一デバイス上に存在する、つまりアプリケーション間のリダイレクトが使用できる場合のフローで、Same Device Flowと呼ばれます。OID4VPにはCross Device Flowも存在します。先の例で言うなら、PCでオンラインショッピングをする際に、スマートフォンのウォレットに格納されているVCを使用するケースです。Cross Device Flowではリダイレクトの代わりにQRコードを使用して、両デバイス間を連携させます。

では、OID4VPのCross Device Flowを詳しく見ていきましょう（図-3）。OID4VPでは、VCを持つエンドユーザを所有者（Holder）、VCを提示する相手を検証者（Verifier）、VCを検証者に提示する際のデータ形式をVPトークンと呼びます。VPトークンには複数のVCを含めることができます。検証者のアプリケーションはHTTPSリクエストを受信するためのサーバが必要です。

図-3 Cross Device Flowの認証例

所有者がPCで検証者のサービスにアクセスします（a）。
検証者アプリケーションがリクエスト取得用URIをQRコードに変換して画面に表示します。
所有者はスマートフォンのウォレットでQRコードをスキャンします（b）。
ウォレットは取得した検証者サーバのリクエスト取得用URIにアクセスします（c）。
検証者サーバはリクエストの詳細をレスポンスとして返します。リクエストの詳細には提示を求めるVCに関する詳細な要求事項が記述されています。
ウォレットは取得したリクエストに従って、提示するVCの内容について所有者に同意を求めるメッセージを表示します。
所有者は内容を確認の上、VCの提示を承認します。
ウォレットは検証者サーバにVPトークンを送信します（d）。
検証者によるVCの検証後、所有者はPCで検証者のサービスの利用を続行します。

OID4VPのCross Device Flowでは、最初のQRコードによるURI取得以降、検証者とウォレット間の通信はインターネットを使用する前提になっています。これを拡張し、インターネットが使えない環境でOID4VPを使用するためのOpenID for Verifiable Presentations over BLE（注14）という仕様も現在、策定中です。例えば、大規模コンサート会場や地下のライブハウスなど、スマートフォンが安定的にインターネットに接続できない環境で、代わりにBLE（Bluetooth Low Energy）による無線通信によって、電子チケットをVCとして提示するようなケースが想定されています。

VCの利用が想定されるユースケースは、日常のあらゆる場面に渡ります。OID4VPの標準化が完了し、本格的な普及が進めば、そのCross Device Flowを使う機会も非常に身近になることでしょう。

3.5 SIOPv2のCross-Device Self-Issued OP

Self-Issued OpenID Provider v2（注15）（略してSIOPv2と呼ばれます）はOpenID Foundationが策定を進めている仕様で、OpenID Connectを拡張し、エンドユーザ自身がIDトークンを発行できるようにするための仕様です。以前の仕様（v2が付かないSIOP）はOpenID Connect Core 1.0（注16）の仕様の一部でしたが、現在、SIOPv2という独立した仕様として標準化作業が進められています。

OpenID Connectでは、OpenID Provider（OP）がエンドユーザの身元を証明するIDトークンを発行し、エンドユーザを認証したい第三者（Relying Party（RP））に提示します。その利用方法の代表例は、Webサービスを利用する際のソーシャルログイン（GoogleやAppleなどのアカウントでログイン）です。このとき、GoogleやAppleなどがOPとなり、WebサービスがRPとなります。SIOPは、このOPの役割をエンドユーザ自身が担い、自らのIDトークンを発行する仕組みです。

SIOPのメリットは、巨大プラットフォームによる中央集権的なID管理から離れ、エンドユーザ自身がID管理を行える点にあります。ソーシャルログインを使用すれば、どのRPを使用したかの情報がOPに収集されます。また、OPのアカウントが停止されてしまえば、RPの利用もできなくなります。こういった中央集権的なID管理の弊害を克服するため、SSI （Self-Soverign Identity、自己主権型アイデンティティ）という考え方が普及し始めています。SIOPはOpenID ConnectをSSIに対応させるための仕様です。

SIOPv2のプロトコルでは2つのフローを定義しています。1つが従来からあるSame-Device Self-Issued OPで、RPのクライアントアプリケーションとOPが同一端末で動作するフローです。RPとOP間の連携にリダイレクトを使用します。もう1つが、SIOPv2で新たに追加されたCross-Device Self-Issued OPで、OPが別デバイス（通常、スマートフォン）で動作するフローです。それでは、Cross-Device Self-Issued OPのフローについて見ていきましょう（図-4）。

図-4 Cross-Device Self-Issued OPによる認証例

エンドユーザがRPにアクセスします（a）。
RPが自己発行リクエストURIを画面に表示します。通常、QRコードとして表示されます。
エンドユーザはスマートフォンでQRコードをスキャンします（b）。自己発行リクエストURIはOPを起動するディープリンクになっています。
ディープリンクからOPを起動します。画面にはIDトークン発行の承認を求めるメッセージが表示されます。
エンドユーザが承認すると、OPはRPのバックエンドサーバに対して、発行したIDトークンを送信します（c）。

Cross-Device Self-Issued OPの他にも、SIOPv2では以前の仕様から以下のような機能強化が行われる予定です。

IDトークンに含めるエンドユーザ識別子は、以前はエンドユーザの公開鍵のフィンガープリントを使う仕様でした。v2ではこれに加え、DID（Decentralized Identifier）を使用できるようになります。これにより、外部の検証可能データレジストリ（Verifiable Data Registry）が使用できるようになります。
OID4VPと組み合わせて、VCをIDトークンと共に提示できるようになります。RPはVCを検証することで、信頼できる発行者が発行したVCとIDトークンを紐付けることができるようになります。VCの検証処理はRP（=検証者）側で完結しますので、VCの発行者に情報が収集されるということもありません。

3.6 CTAP v2.2のHybrid transports

FIDO2（注17）はFIDO Allianceが推進している、パスワードレスでWebサービスにサインインするための認証技術です。FIDO2はW3C Web Authentication（WebAuthn）（注18）とそれを補完するClient to Authenticator Protocol（CTAP）（注19）から構成されています。WebAuthnはFIDO Allianceの協力の下、W3Cによって標準化された仕様で、認証器（Authenticator）と呼ばれる生体認証やセキュリティキーなどによる認証を使用して、Webサービスへのサインインを実現するための仕様です。CTAPはFIDO Allianceによって標準化された仕様で、USBやNFCで接続する、端末に組み込みでない外部の認証器を使用するための仕様です。

現在、策定中のCTAP v2.2では、Hybrid transportsという、スマートフォンを外部認証器として使用するためのプロトコルが提案されています。つまり、PCなどでWebサービスにサインインする際の認証をスマートフォンで行うことができるようになります。類似のソリューションは既にいくつかの事業者によって提供されていますが、いずれも独自仕様による実装でした。FIDO Allianceはこれを標準化しようとしています。Hybrid transportsを使用した認証はFIDO Cross-Device Authentication flow（CDA）（注20）と呼ばれることになるようです。ちなみに、似た語感のMulti-Device FIDO Credentials（注21）というものもありますが、これはエンドユーザが所有する端末間でクレデンシャル（認証資格情報）を同期する仕組みのことで、Passkeys（注22）とも呼ばれます。CDAとPasskeysは独立した仕様であり、Passkeysによってクレデンシャルが同期されていないPCとスマートフォン間でもHybrid transportsは利用可能です。

図-5はHybrid transportsを使用したサインイン手順の例です。

図-5 Hybrid transportsを使用したサインイン手順例

PCでFIDO2対応のWebサイトのサインイン画面を開きます（a）。
使用する認証器の選択ダイアログが表示されるので、スマートフォンを選択します。
画面にQRコードが表示されます。
スマートフォンでQRコードを読み取ります（b）。
スマートフォン側で認証アプリケーションが起動します。
このとき、フィッシングのリスク削減のため、BLEアドバタイズを用いてPCとスマートフォンが近接していることの確認が行われます（c）。
エンドユーザが指紋認証などを行います。
スマートフォンの認証アプリケーションとPCのWebブラウザ間にWebSocketを用いた「トンネル」と呼ぶ信頼できる安全な通信経路を確立します（d）。トンネルの仕様は実装者に委ねられています。
認証アプリケーションはトンネル経由でWebブラウザにクレデンシャルを提供します（e）。
Webブラウザはクレデンシャルを使用してWebAuthnによるサインインを実行します（f）。

一度、トンネルによってリンクした後、次回以降の認証ではQRコードの読み取りの手順は省略されます。

FIDO2はWebサイトへのサインイン手順の置き換えに特化しているので、OAuth/OpenID Connectと組み合わせて利用することが可能です。従って、既存のOAuth/OpenID Connectがカバーしている領域の大半に、Hybrid transportsによるクロスデバイスフローを採用できる見込みがあります。現在、まだ策定中の段階ですが、実用化されれば、非常に大きな可能性を持つ仕様と言えるでしょう。

3.7 おわりに

以上、標準化済み、及び現在標準化に向けて策定中のクロスデバイスフローの仕様をご紹介しました。それぞれ特徴があり、対象となるユースケースは異なります。しかし、いずれもスマートフォンの持つ特性や機能（高い普及率、常時携帯、先進的な生体認証、QRコード対応、プッシュ通知対応、等々）を活用して、より安全で使いやすい認証・認可フローを実現しようという狙いは同じです。今後、クロスデバイスフローの普及が更に進むことで、オンラインサービスや取引の安全性は向上し、より快適なユーザ体験がもたらされることが期待されます。