[go: nahoru, domu]

この記事は ID チーム、Naveen Agarwal による Google Developers Blog の記事 "Updating developer identity guidelines and registration processes to protect users " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

先週（*原文公開当時）Google は、OAuth 認可インフラストラクチャを不正使用しようとしたフィッシング攻撃からユーザー保護するための緊急措置を実施しました。

このような問題が今後は起こらないように、本日（*原文公開当時）、この取り組みを強化しました。これらの変更により、いくつかの作業が追加され、ウェブ アプリケーションを公開するまでの所要時間が長くなる可能性があります。状況に応じて作業を計画することをお勧めします。

アプリ ID ガイドラインのアップデート

Google API のユーザー データ ポリシーで述べられているように、アプリはユーザーの誤解を招かないようにする必要があります。たとえば、アプリには固有の名前を付ける必要があり、他のアプリケーションの名前をコピーしてはいけません。

このポリシーを強化するために、Google はアプリ公開プロセス、リスク評価システムおよびユーザーに表示する同意ページをアップデートして、アプリケーション ID のなりすましや誤解の発生を検出する機能を改善しています。この変更により、Google API コンソール、Firebase コンソール、または Apps Script エディタで新しいアプリケーションを登録するときや既存のアプリケーション属性を変更するときに、エラー メッセージが表示されることがあります。

ユーザーのデータを要求するウェブアプリの新しいレビュー プロセスと制限

Google は、ユーザーのデータを要求する新規ウェブ アプリケーションのリスク評価を強化しました。

このリスク評価に基づくと、一部のウェブ アプリケーションは手動によるレビューが必要となります。レビューが完了するまで、ユーザーはデータ使用権限を承認できません。権限に同意するページの代わりに、エラー メッセージが表示されます。アプリを公開するために、テスト段階でレビューを要求できます。Google は、これらのレビューの処理に 3 ～ 7 営業日を見込んでいます。将来、レビューの要求は登録段階でも可能にする予定です。

アプリが承認されるまで、Google API コンソールで該当プロジェクトの所有者または編集者として登録されているアカウントでログインして、テスト目的で引き続きアプリを使用できます。こうすれば、テスターを追加し、レビュー プロセスを開始できます。

デベロッパーは、アプリケーションからユーザーのデータへのアクセスを要求するときのデベロッパーの責任について説明している Google の過去の投稿を再確認することをお勧めします。私たちのチームは引き続き、ユーザーとそのデータを安全に保つ強力で便利なデベロッパー エコシステムのサポートに取り組んでゆきます。


Posted by Eiji Kitamura - Developer Relations Team

この記事はプロダクト マネージャー Rodrigo Paiva、ソフトウェア エンジニア Nicholas Watson、デベロッパー アドボケート Wesley Chun による G Suite Developers Blog の記事 "Updates to end user consent for 3rd-party apps and Single Sign-on providers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google は、ユーザーのデータやアカウント情報を安全に保つことに細心の注意を払っています。皆さんが作成しているアプリで、ユーザーデータへのアクセスが必要だったり、ユーザーのパスワード変更を支援することがあるため、Google は引き続き、ポリシー変更に関する最新情報をお届けしてまいります。本日（*原文公開当時）は、同意画面とサードパーティ アプリに関連する変更についてご案内します。2017 年 4 月 10 日より、アプリのデベロッパーまたはサードパーティのシングル サインオン（SSO）プロバイダが提供している G Suite 機能のユーザーは、ID サービスで認証認可を行った際にリダイレクトされる場合があります。通常ユーザーは認証認可時に、どのアカウントで認証しようとしているのか、どのパーミッションをアプリに与えようとしているのかを理解します。

この変更は、以下のプラットフォームで実施されます。
  • iOS 向けの Google およびサードパーティ製のアプリ
  • iOS および Android のモバイル ブラウザ
  • ウェブブラウザ（Chrome、Firefox などの最新ブラウザ）
標準認証ライブラリを使用する Android アプリでは、すでに適切なアカウント情報の選択が求められるようになっているため、ユーザーは今回の変更による影響を受けません。

わかりやすくなったアプリでの新しいパーミッションのリクエスト

アプリでは、ユーザーに対してアカウント情報と認証情報に関する同意画面を表示し、単純明快なプロセスにすることが重要になります。新たな変更点の 1 つは、非標準のパーミッションがリクエストされた場合、そのパーミッションのみがアプリのサブ同意画面で表示される点です。 

現在は、アプリがパーミッションをリクエストすると、すべてのパーミッションが一括で表示されます。しかし、ユーザーは標準の「メールアドレス」や「プロフィール」に同意するだけでなく、リクエストされるパーミッションについてさらに詳しい情報を確認できる方が望ましいでしょう。アカウントをクリックして選択することによって、主要なパーミッションに同意します。サブ同意画面は、アプリが追加パーミッションをリクエストした場合のみ表示されます。

ユーザーの同意が必要になるのは、サブ同意画面に表示される非標準パーミッションのみです。 
この変更に合わせて、アプリ名もわかりやすく表示されるようになります。また、ユーザーは連絡先情報をクリックしてデベロッパーに連絡することもできます。ユーザーがすばやくサポートや補助を受けることができるように、アプリのデベロッパーの皆さんは公開用のメールアドレスを掲載するようにしてください。詳しくは、デベロッパー ガイドをご覧ください。

サードパーティのシングル サインオン（SSO）サービスも使っている G Suite ユーザーがアプリを使う場合は、必要に応じて hd や login_hint パラメータを使うことをおすすめします。サードパーティ SSO 認証フローが変更された場合でも、パラメータが提供されていれば考慮されます。詳しくは、ドキュメントの OpenID Connect ページをご覧ください。

サードパーティ SSO リダイレクト関連の変更点

G Suite ユーザーは、サードパーティ SSO プロバイダにログインする際にリダイレクトされることに気づくかもしれません。どのアカウントでもログインしていない場合、ユーザーはサードパーティ SSO プロバイダにログインした後にアカウントを確認する必要があります。これは、ユーザーが正しい G Suite アカウントでログインしていることを確認するためのものです。
エンドユーザーは、Google アカウントにログインした直後に、確認のためにアカウントを選択する必要があります。 
前述のように、クリックしてアカウントを選択すると、ユーザーは「メールアドレス」と「プロフィール」に同意したことになります。非標準の追加パーミッションがリクエストされた場合、ユーザーがそれに同意すると、リダイレクトされてアプリに戻ります。

ユーザーが hd ヒントに一致する 1 つまたは複数のアカウントにすでにログインしている場合、すべてのアカウントが Account Chooser に表示されます。ユーザーは適切な G Suite アカウントを選択する必要があります。その選択後にサードパーティ SSO プロバイダにリダイレクトされ、アプリに戻ります。
複数の Google アカウントにログインしているユーザーは、適切なアカウントを選択する必要があります。

アップデートは 2017 年 4 月より

以上の変更によって、すべてのプラットフォームでユーザーがパーミッションについて細かく把握できるようになります。認証に Google を使用している場合も、サードパーティ SSO プロバイダを利用している場合も同様です。iOS 端末では、すでに新たなページが挿入されるようになっています。各ブラウザでの変更は、2017 年 4 月 10 日より実施される予定です。


Posted by Eiji Kitamura - Developer Relations Team

[この記事は プロダクト マネージャー、William Denniss による Google Developers Blog の記事 "A final farewell to ClientLogin, OAuth 1.0 (3LO), AuthSub, and OpenID 2.0" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

いよいよ ClientLogin、OAuth 1.0 （3LO）、AuthSub、OpenID 2.0 のサポートを終了し、シャットダウンのプロセスを開始したことをお知らせします。まだこれらのサービスを使用している場合、今後正常に動作しなくなりますので、OAuth 2.0 か OpenID Connect にすみやかに移行していただく必要があります。

サインイン システムを移行するもっとも簡単な方法は、Google Sign-in SDK を使うことです（移行についてはこちらのドキュメントをご覧ください）。Google Sign-in は Google が標準として使用している OAuth 2.0 と OpenID Connect のインフラストラクチャをベースに構築され、ウェブ、Android、iOS での認証・認可フローを、1 つのインターフェースで提供します。サーバー API を移行する場合は、OAuth 2.0 クライアント ライブラリの使用をおすすめします。

Google は今後、従来の認証プロトコルをサポート外とすることで、OpenID Connect と OAuth 2.0 のサポートに注力していきます。これら最新のオープン スタンダードは、Google アカウントのセキュリティをさらに強固なものとし、開発者のみなさまにとっても、従来より簡単に実装できるものとなっています。

※ 3LO とは、承認を行うエンドユーザーを伴った 3-legged OAuth を意味します。対照的に、2-legged OAuth（2LO）は、組織規模でのポリシーによるアクセスコントロールのような、企業ごとの認可シナリオを意味します。OAuth1 3LO と 2LO フローはどちらもサポートが終了しますが、今回のアナウンスは OAuth1 の 3LO についてのみです。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は William Denniss, Product Manager, Identity and Authentication による Google Developers Blog の記事 "Reminder to migrate to OAuth 2.0 or OpenID Connect" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google は過去数年間に渡って、ClientLogin、OAuth 1.0 (3LO)、AuthSub、OpenID 2.0 のサポートが 2015 年 4 月 20 日をもって終了することをお知らせしてきました。こうした従来の古いプロトコルから脱却し、最新のインターネット標準である OAuth 2.0 や OpenID Connect のサポートに集中することで、セキュリティを向上し、開発上の煩雑さ減らすことができます。

これらの新しい標準規格に移行するもっとも簡単な方法は、Google Sign-in SDK を使うことです（移行についてのドキュメントをご覧ください）。Google Sign-in は OAuth 2.0 や OpenID Connect をインフラストラクチャの基盤とし、インターフェース 1 つでウェブ、Android、iOS に対して認証と認可のフローを行うことができます。

古い仕様を使っているアプリケーションはサポート終了日までに移行を行わない場合、Google に接続できなくなります（ログインもできなくなる可能性があります）。サービスが問題なく継続できるよう、サポート終了までに移行を完了してください。

移行を行うにあたっては、以下をご確認ください。
アプリケーションの移行に関する技術的なご質問は、Stack Overflow のgoogle-oauth か google-openid タグで投稿してください。

3LO とは 3-legged OAuth を意味します。3LO では、同意を行うエンドユーザーが存在します。これとは異なり、2-legged (2LO) は組織規模でのポリシー コントロール アクセスとしてエンタープライズの認証プロセスに対応しています。OAuth1 の 3LO と 2LO フローはどちらもサポートが終了します。

Posted by Eiji Kitamura - Developer Relations Team