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

こんにちは、ID連携黒帯 倉林 雅（@kura_lab）です。

昨年の「知っておきたい7つのID連携実装パターン」に続き今年も23日を担当することになりました！祝日も記事を投稿いたします！

今年のAdventCalendarも「Yahoo! JAPANを支える技術」をテーマとしていますが、今回は少し先の未来をみすえて今後Yahoo! JAPANを支えることになるかもしれない新しい技術についてご紹介しようと思います。

すでにPCやスマホ上で認証を行いサービスを利用することは普通になりつつありますが、今後はテレビやゲーム機、ビデオカメラなどのデバイスでも認証や決済を利用したサービスが増えてくると思われます。Identity Provider（認証・認可を行いユーザーの属性情報を提供する事業者）各社が提供を開始しはじめデファクトスタンダードとなりつつある「OAuth 2.0 Device Flow」をご紹介します。

ブラウザー・WebViewが利用できないデバイスで認可する方法が必要

2015年11月より第4世代Apple TV向けのOSとしてtvOSがリリースされました。第3世代まではプリインストールのアプリのみの利用で新しい機能を利用するためにはOSのアップデートを待つ必要がありましたが、tvOSではApp Storeが利用できるようになりiOSのようにアプリをダウンロードできるようになっています。
Yahoo! JAPANではヤフオク!がいち早く対応しアプリをリリースしています。

新しいApple TVは「Shared Experience」をコンセプトとしており、ヤフオク!では大画面テレビでヤフオク!の商品をみんなでさがす新しい体験の提供を目指しています。この季節ですと「家族団らんのお茶の間のテレビでヤフオク!アプリをつかって子どもが欲しがっているゲームをお父さんが落札」みたいなこともあるかもしれません。今後は他のアプリも提供され、PCやスマホではできなかった体験ができるようになっていくと思います。

アプリをインストールできるようになり便利になったApple TVですが、開発者にとっては課題もあります。それは「tvOSではSafariなどのブラウザーやアプリ内でのWebViewが利用できない」ということです。
iOSのSafariやAndroidのChromeなどのブラウザーのことをSystem Browser、アプリ内のWebViewのことをEmbedded Browserと呼ぶこともありますが、tvOSではこれらを利用できません。ブラウザーやアプリ内のWebViewでPC版・スマホ版のWebを表示させるようないわゆるガワアプリを実装できないようにし、UXの向上を図るためだと思われます。

これはブラウザーやWebView上でログイン画面を表示できないため、WebアプリケーションやネイティブアプリのようにOAuth 2.0やOpenID Connectによる認証、認可ができません。
ユーザーを認証しWeb APIを利用したサービスを提供するために、ブラウザー・WebViewが利用できないデバイスにおいてもユーザーに同意を求められるインターフェースが必要となります。

WebViewからSFSafariViewControllerやChrome Custom Tabsへ

tvOSの話からそれますが、アプリにおけるWebViewについて少しふれておこうと思います。
セキュリティ関連のお仕事をされている方は、WebViewによるフォームの送信や認証はよくないと思われたかもしれません。WebViewはアドレスバーが表示されないためアクセス中のURLをみることができません。また、SSL証明書の確認ができず暗号化通信をしているかどうかも確認できません。
WebViewによるフォームの送信や認証が増えると、個人情報やID, パスワードを盗み取ることを目的とした悪意あるアプリの画面と本物の画面が区別しにくくなりフィッシングの助長につながるため推奨はできません。

これはここ数年課題となっていましたが、iOS9から利用できるようになったSFSafariViewController, Chrome 45から利用できるようになったChrome Custom Tabsを用いることで解決できるようになりました。これらを用いることでブラウザーと同じ機能が利用できるとともに、アドレスバーでURLやSSL証明書を確認することも可能になります。

iOS, AndroidアプリでOAuth 2.0やOpenID Connectを利用する場合にはSFSafariViewControllerやChrome Custom Tabsを利用するとよいと思います。
技術的な詳細についてはまた別の機会にご紹介したいと考えています。

アプリでID・パスワードよるアクセストークン発行APIはおすすめできない

IDとパスワードによるアクセストークン発行APIについてもふれておこうと思います。
AndroidやiOSのネイティブアプリの開発担当の方から「ユーザーのID・パスワードをリクエストしてアクセストークンを発行できるAPIを提供できませんか？」という相談をときどき受けます。

ブラウザーやWebViewは利用できませんが、tvOSにはソフトウェア・キーボードがあるため、IDとパスワードを入力することは可能であり、tvOS対応でも同様の認証方式が利用できないかという要望もあげられました。

認可プロトコルであるOAuth 2.0のRFCにはパスワードをつかったフローが定義されています。

• Resource Owner Password Credentials Grant（RFC 6749）

しかし、IDとパスワードによるアクセストークン発行APIの提供には注意が必要です。
OAuth 2.0では、基本的にAuthorization Code GrantやImplicit Grantを利用します。RFCにも記載されているようにResource Owner Password Credentials Grantはそれらが利用できないときに限り提供することになっています。

サーバーサイドではClient IDとClient Secretによるクライアント認証によって利用を制限できますが、デバイスにインストールされるアプリではProxyをはさんで通信をのぞいたり、アプリをデコンパイルすることでClient ID, Client Secretを取得されてしまう可能性があります。
Client ID, Client Secretが漏れると悪意あるユーザーからID・パスワードを繰り返しリクエストすることができてしまいます。繰り返しパスワードのチェックができてしまうと、不正ログインにもちいるID・パスワードをまとめたリストのクレンジング（不要なデータを取り除きリストの質を高めること）に利用される可能性がでてきてしまいます。

これらを防ぐためには不正なリクエストやAbuseのブロックを行うなど適切なセキュリティ対策が必要になります。
このようにID・パスワードよるアクセストークン発行APIの提供は慎重に検討しないといけません。

そのため、Android・iOSではOpenID Connect（Yahoo! JAPANではYahoo! ID連携でサポート）を推奨しています。tvOSでもOpenID Connectを利用したいところですが、ヤフーのOpenID Connectでの認証はブラウザー・WebView経由のログイン画面の表示が必須になるため利用できません。

では、tvOSでの認証はどうすればよいのでしょうか。

OAuth 2.0 Device Flow

2015年11月に横浜でIETF94が開催されました。IETFはインターネット技術の標準化を推進する団体です。セキュリティ関連の標準化を行うSEC（Security）エリアのoauth WG（Working Group）にはMicrosoftやGoogleといった技術者が参加し仕様を策定しています。Yahoo! ID連携で採用しているOAuth 2.0もこのWGで標準化されたものです。

oauth WGで策定されている仕様のひとつに「OAuth 2.0 Devive Flow」があります。これはブラウザーやWebViewが使えないデバイスを別デバイス（スマホなど）と連携させて認可する仕様です。

• OAuth 2.0 Device Flow (draft-denniss-oauth-device-flow)

IETF94ではこの仕様をチャータリングする（仕様の策定を取り上げる）かどうかの多数決がとられました。多数決の結果継続して策定がされそうです。

OAuth 2.0 Device Flowは以下のような流れになっています。

1. Device（tvOSの画面上）でログインボタンが押され、認可サーバーへアプリケーションを識別するためのClient IDを送信する。
   
2. 認可サーバーからデバイス検証用のVerification Code、ユーザー検証用のUser CodeとVerification URIが返却される。
   

3. 取得したUser CodeとVerification URIをDevice上に表示し、別のデバイス（スマホ）のブラウザーでURIを表示する。
   
4. ユーザーがVerification URIで処理をしている間、DeviceはClient IDとVerification Codeを含めた認可サーバーへのリクエストをPollingで実行して処理の完了を待つ。
   

5. スマホのブラウザーでVerification URIにアクセスするとユーザー認証（ログイン）が求められる。認証後、Device上のアプリとの連携に対する同意が求められる。同意する場合にはUser Codeを入力する。
   
6. 5.の認証、同意が完了すると4.のPolling状態が解放され、アクセストークンが返却される。
   

tvOSでブラウザー・WebViewが利用できないという課題も、AndroidやiPhoneなどの別のデバイスのブラウザーを利用して認証することで解決できます。tvOSの他にもブラウザーが利用できないがディスプレイのついているデバイスであればこの方法は利用できると思います。

この仕様は策定を開始したところですが、GoogleやFacebook、TwitterもOAuth 2.0 Device Flowをベースとした認可フローの提供を開始しています。Yahoo! JAPANでもYahoo! ID連携の拡張機能として提供を検討していこうと考えています。

まとめ

今回はブラウザー・WebViewが利用できないデバイスの課題とその解決策となるOAuth 2.0 Device Flowについてご紹介しました。

• tvOSなどブラウザー・WebViewが利用できないデバイスで認可する方法が必要
• OAuth 2.0やOpenID Connectの利用はWebViewではなくSFSafariViewControllerやChrome Custom Tabsを利用するとよい
• アプリでResource Owner Password Credentials GrantはID・パスワードリストのクレンジングに悪用される可能性があるためおすすめできない
• ブラウザー・WebViewが利用できないデバイスはブラウザーが利用できる別のデバイス（スマホなど）を利用したOAuth 2.0 Device Flowによって認可することが可能。Yahoo! ID連携の拡張機能として提供を検討中

Yahoo! JAPANではOAuth 2.0 Device Flowの他にもIoT向けの認証技術についても調査、提供の検討を行っています。PC、スマホ以外のデバイスにおける認証技術、ID連携技術はこれからのYahoo! JAPANを支える技術となっていくと思われます。

今後もイベントやTech Blog等で認証、ID連携を中心に新しい技術についてご紹介していきますのでよろしくお願いします。