こんにちは。IDソリューション本部の本間です。ヤフーには新卒で入社し現在2年目で、主にYahoo! ID連携のサーバーサイドの開発・運用を担当しています。

Yahoo! ID連携は主にスマートフォンアプリやウェブアプリなどで使われますが、今回は以前当Tech Blogでも紹介した、スマートフォンやPC以外のデバイスにも使える認可の仕組みである「OAuth 2.0 Device Flow」を導入したGYAO!アプリがリリースされましたので、Device Flowの仕組みとヤフーにおける実装を紹介したいと思います。

• ブラウザー・WebViewが利用できないデバイスの課題とOAuth 2.0 Device Flow

ブラウザーが使えないデバイスでログインする

最近はスマートフォンやPC以外の機器からでもインターネットに接続しサービスを利用するシーンが当たり前になりました。最近のゲーム機はインターネット接続を介したアップデートが可能ですし、家庭向けのテレビでも動画配信サービスを利用することが増えています。またテレビやモニターに接続して使うChromecastやApple TVなどをお持ちの方も多いのではないでしょうか。

このようなデバイスを利用したサービスにおいても、ユーザーごとに最適なコンテンツを配信したり有料サービスを提供するためにはサービスにログインしてもらうことが必要です。

しかし、テレビなどのデバイスは文字入力が容易ではなく、画面に表示されるソフトウエアキーボードをリモコンで操作しIDやパスワードを入力するログインはユーザーにかなりの負担を強いてしまいます。

また、Apple TVはOSの仕様上、従来のブラウザーやWebViewを使ったログインが採用できません。そこで登場したのが「OAuth 2.0 Device Flow」です。

「OAuth 2.0 Device Flow」とは

「OAuth 2.0 Device Flow」とはIETFで策定が進められている仕様で、インターネットの接続はできるがブラウザーやWebViewが使えない、あるいはテレビのように文字の入力が容易ではないデバイス向けの認可の仕様です。

• OAuth 2.0 Device Flow for Browserless and Input Constrained Devices（外部サイト）

仕様としては2017年12月現在標準化が検討されているDraftの段階ですが、GoogleやFacebook、Huluなどの他社でも既に導入が進んでいます。

Device Flowのシーケンス

Device Flowのシーケンスを次の図で説明します。ここでDevice Clientはユーザーがログインしたいデバイスやアプリを指します。
Authorization ServerはIdentity Provider(ヤフーやGoogleなど)が提供する認可サーバーです。End Userはブラウザーが利用できるスマートフォンやPCを使用します。

① Device ClientがAuthorization Serverにアプリケーションを識別するためのClient IDを送信します。Authorization Serverからユーザー検証用のUser Code、デバイス検証用のDevice Code、Verification URIが返却されます。User CodeとDevice Codeは関連付けられた一組の文字列です。

② End UserがスマートフォンなどのブラウザーからVerification URIにアクセスし、ログインしてからUser CodeをAuthorization Serverに送信します。正しいUser Codeが送信されるとログイン完了画面がブラウザーに表示されます。この時User Codeに関連付けられたDevice Codeを認証済みにします。

③ End UserのUser Codeの送信を待つ間Device ClientはClient IDと①で取得したDevice Codeを含むリクエストを一定間隔でAuthorization Severに送信し続けます。Device Codeが認証済みになっている場合はAccess TokenとRefresh TokenがDevice Clientに返却されます。取得したAccess TokenによってDevice ClientからWeb APIが利用できるようになり、ユーザーに最適なコンテンツを提供できます。

以上がDevice Flowのシーケンスです。

Device FlowではUser CodeとDevice Codeを使って手持ちのスマートフォンやPCのセッションをEnd Userのデバイスと共有しDevice Clientとの連携を可能にします。

Device Flowを導入したテレビ版GYAO!アプリ

2017年9月よりグループ会社で提供しているGYAO!のFire TVとAndroid TV向けのアプリにDevice Flowを導入いたしました。

• テレビでのログインが簡単になりました -GYAO!- (外部サイト)

Device Flowを使ったログインをGYAO!アプリの画面でご説明したいと思います。なお、画面上ではUser Codeを確認コードと呼んでいるため以降は確認コードという名称で説明します。

確認コードを表示(GYAO!アプリ)

テレビでGYAO!アプリを起動します。メニューからログインを選択すると次の画面が表示されます。

この画面ではユーザーにスマートフォンやPCを使ってアプリに表示される8桁の確認コードを入力することを求める内容が表示されます。確認コードは前述のシーケンス①で取得したUser Codeを表示します。確認コードを表示している間アプリは一定間隔でAuthorization ServerにToken Requestを送信し続けます(シーケンス③)。

確認コード入力画面(スマートフォン等)

ユーザーは手持ちのスマートフォン等のブラウザーでGYAO!アプリに表示されているURLを直接入力するか、QRコードを読み取って確認コード入力画面にアクセスします。ただし、この時ブラウザーがYahoo! JAPANに未ログインの場合はYahoo! JAPANのログイン画面を経由します。

確認コードの入力が完了するとスマートフォンの画面が次の画面に切り替わり、GYAO!アプリにログインが完了したことがユーザーのブラウザー上に表示されます。

ログイン完了画面(GYAO!アプリ)

確認コードの入力が完了すると、テレビ版GYAO!アプリは自動的に次の画面に切り替わります。

このようにしてユーザーはテレビ側でIDとパスワードを入力することなくGYAO!アプリにログインできます。

QRコードの利用

Device Clientに表示するQRコードの利用はDevice Flowの仕様上は任意とされています。ヤフーではユーザーの利便性を考慮しQRコードを用いることにしましたが、QRコード内のURLに確認コードを含めることはしませんでした。

技術的にはEnd Userのブラウザーがログイン状態であれば、確認コードを含むQRコードを読み取るだけでDevice Clientをログイン状態にする実装も実現可能です。この実装はユーザーの利便性は非常に高い一方でユーザーの確認無しにログインがされてしまうため、仕様上でも望ましくない実装とされています。

また、QRコードに確認コード含めれば入力フォームに自動で確認コードを埋めることができ、ユーザーに手動で入力してもらう手間が省け利便性が向上すると考えられます。しかし、ヤフーではこれらの実装はしませんでした。これは乗っ取りのリスクを考慮したためです。

乗っ取りのリスクとぜい弱なDevice Flowの実装

悪意のあるユーザーが他のユーザーのアカウントの利用権限を奪取する乗っ取りという行為が存在します。乗っ取りの被害にあうと、知らないうちに有料コンテンツが購入されてしまうなどのリスクがあり、ユーザーが不利益を被る可能性があります。

確認コードを含むQRコードを読み取るだけでログイン状態にするぜい弱性のある実装をした場合のDevice Flowを利用した乗っ取りには次のケースが考えられます。

ここではDevice Clientを利用するAとスマートフォンを所持するBがいるとします。そしてAに悪意があるとします。

1. AがDevice ClientでQRコードを発行する
2. AがBに対してQRコードをメールなどで送付し「Bのスマートフォン」に読み込ませる
3. Bのブラウザーがログイン状態で再認証をしない場合に、BがQRコードを読み込んだ段階でAのDevice ClientがBのアカウントでログイン状態になる
4. AはBの課金コンテンツなどを不正に入手

このようにして、Aは簡単にBのアカウントを乗っ取ることができてしまいます。

また、QRコード読み込み直後にDevice Clientをログイン状態にはせずに、User Codeをブラウザーの入力フォームに自動で埋める実装をした場合でもボタンを一つクリックしただけでDevice Clientがログイン状態になり、ユーザーの期待しない動作を誘発する可能性があります。

ヤフーにおけるDevice Flowの実装

ヤフーでは乗っ取りのリスクを考慮し、QRコードに確認コードは含めずユーザーによる確認コードの入力が必ず伴うように設計・実装しました。これにより乗っ取りのリスクが完全に排除できるわけではありませんが、確認コードの入力によってユーザーはDevice Clientにログインすることを認識しやすくなり、乗っ取りのリスクが低減すると考えられます。

また、全体の9割近くのユーザーがQRコードの利用を選択しており、QRコードは非常に便利な存在であることがうかがえます。一般的にユーザーの利便性の追求が求められるWebサービス開発ですが、リスクとのトレードオフをしっかり考え設計・実装を進める必要がありました。

まとめ

• インターネットの接続はできるがブラウザーやWebViewが使えない、あるいはテレビのように文字の入力が容易ではないデバイス向けの認可の仕様であるDevice Flowをご紹介しました。
• Device Flowを導入したGYAO!アプリのログインの流れを説明しました。
• Device Flowの導入にあたり、QRコードを例にユーザーの利便性とリスクのバランスを取りながらサービスを設計・実装する必要性があることを説明しました。

今後について

Device Flowは現在は弊社のサービスとグループ会社向けの提供となっておりますが、今後必要に応じて一般のデベロッパーの皆さまにお使いいただけるように準備を進めてまいります。一般公開ができましたらぜひとも一度デベロッパーの皆さまにお使いいただければと思います。