はじめに
こんにちは、hachi8833です。
Google Developers Blogに先週公開された記事「Modernizing OAuth interactions in Native Apps for Better Usability and Security」で､WebViewからのOAuthで行うGoogleアカウントの認証を今後廃止するとの記述がありました｡記事の中でも特にシビれるのが「web-viewには、AndroidのWebView UI 要素、iOSのUIWebViewやWKWebViewのほか、WindowsやOS X上の同等の機能も含まれます」という一文です｡ふわぁっとやさしく触れているのですが､どんなアプリが影響を受けるのか｡((((oﾟ▽ﾟ)o))) ﾄﾞｷﾄﾞｷ♪
以下に取り急ぎ訳したものを参考として掲載します｡後10日もすればGoogle Developers Japanブログに日本語版が掲載されると予想されるので､日本語版または原文を参照いただくようお願いします｡
追記: 日本語版が公開されました↓。
参考: Google Developers Japan: ネイティブ アプリの OAuth インタラクションを最新にしてユーザビリティとセキュリティを向上する
【翻訳】ネイティブアプリでのOAuth手順を現代化して、ユーザービリティとセキュリティを改善する
原文日付: 2016年8月22日（月）
原題: Modernizing OAuth interactions in Native Apps for Better Usability and Security
著者: William Denniss（ID・認証プロダクトマネージャ）IDチームは以前より、GoogleのユーザーがサードパーティのアプリケーションにGoogleアカウントで安全かつシームレスに登録できるよう、さらにGoogleのユーザーが共有を許可したカレンダーや連絡先などの情報だけが他のアプリと共有されるよう、サポートを続けています。
ID・認証の背後では、こうしたやりとりはOAuthリクエストから始まります。Googleでは多くの開発者向けに、OAuthフローを実装するさまざまな方法を提供してきました。セキュリティとユーザービリティが改善されたことに伴い、従来サポートしてきた方法のうち1つを間もなく終了します。Googleでは今後数か月のうちに、いわゆるweb-viewと呼ばれる組み込みブラウザで行うGoogleへのOAuthリクエストの受け付けを終了します。web-viewには、AndroidのWebView UI 要素、iOSのUIWebViewやWKWebViewのほか、WindowsやOS X上の同等の機能も含まれます。
OAuthリクエストには組み込みweb-viewではなく端末のブラウザを使うことで、アプリの使い勝手が大きく向上します。ユーザーは端末ごとに1回だけGoogleにログインするだけで済み、アプリの認証手順がスムーズになってログインのコンバージョン率も改善されます。OSによっては、現代的な「アプリ内ブラウザタブ」パターンを利用できます。Androidの Chrome Custom TabsやiOSのSFSafariViewControllerでは、ブラウザベースのOAuthフローがさらに使いやすくなっています。
組み込みブラウザでOAuthを行う旧来の方法では、ユーザーは端末の既存のログインセッションを使う代わりに、毎回Googleにログインしなければなりません。アプリはweb-view内のコンテンツを監視して改変することもできますが、端末のブラウザのコンテンツを触ることはできないので、セキュリティも改善できます。開発者の皆様がスムーズに移行できるよう、現代的なベストプラクティスに沿った次のライブラリとサンプルを提供いたします。
- AndroidとiOS向けのGoogleログイン（Google Sign-in）: GoogleアカウントによるログインやOAuthのための推奨SDKです。
- Android､iOSとOS X向けのAppAuth: Googleを含むOAuthプロバイダで利用できる、オープンソースのOAuthクライアントライブラリです。この他にも、iOSやOS X向けにGTMAppAuthを提供します。これにより、Objective-C向けGoogle API Client Libraryや、GTM Session Fetcherプロジェクトで、AppAuthをサポートできるようになります。
- Windows向けのGoogleログインやOAuthのサンプルとして、UWP（Universal Windows Platform）やコンソールやデスクトップアプリなどのさまざまなWindows環境でGoogleユーザーをブラウザで認証する方法のサンプルデモがあります。
Googleによるネイティブアプリ向けの標準的なOAuthサポートに関するプロトコルレベルのドキュメントや、IETFによる現時点でのOAuth向けベストプラクティスのドラフトも参照できます。
iOSのGoogleログインがバージョン3.0より古い場合、Web開発の現時点のベストプラクティスであるアプリ内ブラウザタブはサポートされておらず、それらのバージョンの提供も終了しています。Googleログインを利用する場合は最新バージョンにアップデートし、改善されたセキュリティやユーザビリティをすべて導入してください。現時点では、このポリシーによってiOS 8のWebViewのサポートが終了する予定はありません。
web-viewで行うGoogleへのOAuthリクエスト受け付けが廃止されるまでのスケジュールは次のとおりです。2016年10月20日より、代替手段を実際に利用できるプラットフォームにおいて、web-viewを使った新規OAuthクライアントはGoogleによって拒否され、既存のOAuthクライアントでもユーザーに通知が表示されるようになります。2017年4月20日以降、代替手段を実際に利用できるプラットフォームにおいて、web-viewを使ったすべてのOAuthクライアントはGoogleによってブロックされます。
移行方法について不明な点がある場合は、Stack Overflowで「google-oauth」タグを付けて投稿してください。
【補足】WebViewのOAuth受け付け廃止にどう対応するか
WebViewは､言ってみればアプリ内に自前のブラウザ一式を持っているようなもので､PCやスマホにとっては別ブラウザがあるのと変わらないことになります｡HTML/CSS/JavaScriptというブラウザ技術で画面を組み立てられるという簡便さもあって､WebViewは広く使われています｡
PCやスマホのデフォルトブラウザで既にユーザー認証を行っても､WebViewを使うアプリはまったくの別物なので別途認証しなければなりません。デフォルトブラウザ（ネイティブブラウザ）と異なり､WebViewはアプリの支配下にあるので、アプリが実はマルウェアであれば､GoogleアカウントへのOAuthのような外部認証システムのパスワードを盗み取る可能性がないとはいえません｡
明示的に利用するWebViewライブラリ以外にも､Chromiumをレンダリングエンジンとして使っているElectronやNW.jsのようなタイプのGUIアプリが近年急速に普及しており､これもWebViewの一種と考えられます｡
大事なことなので二度言います。ブログでは「WindowsやOS X上の同等の機能」もWebViewに該当するのであれば、ネイティブでないブラウザエンジンとHTML/CSS/JSで画面を作っているアプリは､この変更の影響を受ける可能性があります｡
こうしたアプリでは、ブログ内で推奨されているSDKやサンプルを利用したり､以下の「アプリ内ブラウザタブ」方式に切り替えるなどして移行する必要があるでしょう。
GoogleがOAuthリクエストをチェックする際に、ネイティブブラウザなのかWebViewなのかをどうやって区別しているのかは気になる点です。
関連記事
Google Driveのファイル共有状況を一括出力するgoogle-drive-permission-searchを作った