WebViewでGoogleアカウントのOAuth認証が使えなくなる問題

はじめに

こんにちは、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ブログに日本語版が掲載されると予想されるので、日本語版または原文を参照いただくようお願いします。

【翻訳】ネイティブアプリでの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内のコンテンツを監視して改変することもできますが、端末のブラウザのコンテンツを触ることはできないので、セキュリティも改善できます。

開発者の皆様がスムーズに移行できるよう、現代的なベストプラクティスに沿った次のライブラリとサンプルを提供いたします。

  • AndroidiOS向けのGoogleログイン(Google Sign-in): GoogleアカウントによるログインやOAuthのための推奨SDKです。
  • AndroidiOSと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をレンダリングエンジンとして使っているElectronNW.jsのようなタイプのGUIアプリが近年急速に普及しており、これもWebViewの一種と考えられます。

大事なことなので二度言います。ブログでは「WindowsやOS X上の同等の機能」もWebViewに該当するのであれば、ネイティブでないブラウザエンジンとHTML/CSS/JSで画面を作っているアプリは、この変更の影響を受ける可能性があります。

こうしたアプリでは、ブログ内で推奨されているSDKやサンプルを利用したり、以下の「アプリ内ブラウザタブ」方式に切り替えるなどして移行する必要があるでしょう。

GoogleがOAuthリクエストをチェックする際に、ネイティブブラウザなのかWebViewなのかをどうやって区別しているのかは気になる点です。

関連記事

Ruby on RailsによるWEBシステム開発、Android/iPhoneアプリ開発、電子書籍配信のことならお任せください この記事を書いた人と働こう! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好き。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

週刊Railsウォッチ

インフラ

BigBinary記事より

ActiveSupport探訪シリーズ