「スマートフォンの画面で承認してください」を実現するクロスデバイスフローの仕組み：Inside-Out

オンラインバンクなど、インターネット上のサービスを利用する際、スマートフォンを使った認証や認可の手続きを設定するように求められることはないでしょうか。本記事では、近年、注目を集めている、スマートフォンを活用したクロスデバイスフロー（Cross-Device Flow）と呼ばれる認証・認可方式について解説します。

[四谷兼三，IIJ]

本記事は、株式会社インターネットイニシアティブの許可をいただき、「Internet Infrastructure Review（IIR）Vol.59」の「3. フォーカス・リサーチ（2） クロスデバイスフローによる認証・認可」（2023年6月23日発行）を転載したものです。そのため、用字用語の統一ルールなどが、＠ITのものと異なります。ご了承ください。

執筆者プロフィール

四谷 兼三 （よつや けんぞう）
IIJ 技術研究所 技術開発室
次世代認証・認可関連技術の研究・開発に取り組んでいます。

スマートフォンを使った認証、許可の仕組み"
インターネット上のサービスを利用する際、スマートフォンを使った認証や認可の手続きを設定するように求められることはないでしょうか。本記事では、近年、注目を集めている、スマートフォンを活用したクロスデバイスフロー（Cross-Device Flow）と呼ばれる認証・認可方式について解説します。

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

　クロスデバイスフローとは、あるサービスを利用する端末（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

　

OAuth 2.0 Device Flow

　OAuth 2.0 Device Authorization Grant（RFC8628）は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による認可フローの例

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

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

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

OpenID Connect CIBA Flow

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

• コールセンターの担当者が電話口の顧客の情報を取得するケース。担当者は顧客から聞いた会員番号を顧客管理システムで検索する。すると、顧客のスマートフォンに通知が飛び、個人情報を開示して良いか確認する旨のメッセージが表示される。顧客が承認してようやく、顧客管理システムは検索結果として顧客の情報を表示する。この仕組みにより、担当者が無断で顧客情報を閲覧するような情報漏えい事故を防げる。
• 店舗でのクレジットカード決済の承認に使用するケース。顧客が店舗で買い物をする際、レジにてクレジットカードで支払おうとすると、顧客のスマートフォンに通知が飛び、支払い内容の確認メッセージが表示される。顧客が承認すると決済が完了する。サインや暗証番号の入力などよりも確実な本人確認と同意取得が実現できる。