[go: nahoru, domu]

この記事はテクニカル ライター、Peter Jacobsen による Google Developers Blog の記事 "Use OAuth 2.0 tokens on your website, app, and servers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

OAuth 2.0 は、インターネットでトークンベースの認可を行うためのオープンな標準認可フレームワークです。OAuth 2.0 のアクセス トークンは、OAuth 2.0 クライアントがリソース サーバーにリクエストをする際に使用する文字列で、ユーザー ID などの情報を OAuth 2.0 クライアントから隠蔽します。リソース サーバーにリクエストをする際には、アクセス トークンのみを使用します。

オフライン リフレッシュ トークン

アクセス トークンは一定時間で有効期限が切れ、関連する API リクエストに利用できない無効な認証情報になります。トークンに関連付けられたスコープに対してオフライン アクセスをリクエストする場合、アクセス トークンを更新することができます。このとき、ユーザーにパーミッションを要求するプロンプトを表示する必要はなく、ユーザーがそこにいる必要もありません。

リフレッシュ トークンの有効期限は、アクセス トークンよりも少し長くするというのがベスト プラクティスです。たとえば、アクセス トークンの有効期限を 30 分に設定する場合、リフレッシュ トークンの有効期限は 24 時間またはそれ以上にします。

詳しくは、アクセス トークンの更新（オフライン アクセス）をご覧ください。

オンライン アクセス

アプリによっては、短い間隔でユーザーを再認証するリクエストをする可能性があります。その場合は、リフレッシュ トークンではなくアクセス トークンのみを使います。こういったアプリは、リフレッシュ トークンを使ったオフライン アクセスと見なされるアプリとは違い、オンライン アクセスとなります。

詳しくは、アクセス トークンの更新（オフライン アクセス）とトークンを更新するをご覧ください。

JSON Web Token（JWT）とトークンの有効期限

Cloud IoT の認証をするには、各デバイスで JWT を作成する必要があります。JWT は、デバイスと MQTT または HTTP ブリッジとの間の、短時間だけ有効な認証に使われます。

JWT は、ヘッダー部、ペイロード部、署名部という 3 つのセクションで構成され、ペイロード部には一連のクレームが含まれています。ヘッダー部とペイロード部は、JSON オブジェクトを UTF-8 のバイト列にシリアライズして Base64 URL エンコーディングでエンコードしたものです。

JWT のヘッダー部、ペイロード部、署名部は、ピリオドで連結されます。その結果、通常の JWT は次のような形式になります。 

{Base64url encoded header}.{Base64url encoded payload}.{Base64url encoded signature}

詳細については、JSON Web Token（JWT）の使用と JWT トークンの有効期限を管理するをご覧ください。

一般的なトークンの有効期限のパラダイム

トークンの有効期限の管理には、さまざまなポリシーや戦略を利用できます。以下のような方式が考えられます。

  • HTTP レスポンスをモニタリングして 401 HTTP レスポンスを検出し、適切に対応する
  • リソース サーバーに HTTP リクエストを行う前に、先回りでトークンの有効期限を確認し、有効性を判断する
  • リクエストの際に有効なトークンが期限切れして 401 HTTP レスポンスが発生する可能性がある場合に、上記 2 つの戦略を組み合わせて期限切れに対処する

Reviewed by Eiji Kitamura - Developer Relations Team

この記事はプロダクト ソリューション エンジニア、Brian Daugherty による Google Developers Blog の記事 "Discontinuing authorization support for the Google Sign-In JavaScript Platform Library" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年、ウェブ アプリケーション用の Google ログイン JavaScript プラットフォーム ライブラリのサポート終了予定についてお知らせしました。

Google ログイン JavaScript プラットフォーム ライブラリは、2023 年 3 月 31 日に完全に提供を終了します。ウェブ アプリケーションへの影響を確認し、必要に応じて移行計画を立てていただくよう、改めてお願いします。

2022 年 4 月 30 日より、新規アプリケーションは Google Identity Services ライブラリを使う必要があります。既存のアプリケーションは、サポート終了日までプラットフォーム ライブラリを使い続けることができます。

対応すべき内容
  • サポートの終了による影響の有無と、Google Identity Services に移行する必要性を評価してください。
  • 移行は 2023 年 3 月 31 日までに終えてください。この日をすぎると、プラットフォーム ライブラリはダウンロードできなくなり、非推奨の認可機能から Google API を呼び出すためにアクセス トークンを取得しているウェブ アプリケーションは、意図したとおりに動作しなくなります。
影響の有無

Google は、ウェブでユーザーの個人情報を守るために、アプリやサービスへのログインをデフォルトで安全なものにする取り組みを続けています。その実現に向けて、Identity API ファミリーの一員である Google Identity Services についてお知らせしました。これは、複数の ID サービスを 1 つのソフトウェア開発キット（SDK）にまとめたものです。先日、Google Identity Services ライブラリのアップデートをリリースし、OAuth 2.0 に基づいたユーザー認可とデータ共有の機能を追加しました。新しい Identity Services ライブラリでは、さまざまなセキュリティやプライバシーの改善が行われているため、古いプラットフォーム ライブラリのすべての機能との間に完全な下位互換性があるわけではありません。そのため、新しいライブラリへの移行とコードの変更が必要になります。

サポートの終了は、Google ログイン JavaScript プラットフォーム ライブラリを読み込んでいるウェブ アプリケーションと、JavaScript 用 Google API クライアント ライブラリでアクセス トークンを扱っているアプリケーションに影響します。

ウェブページで JavaScript モジュール apis.google.com/js/api.js または apis.google.com/js/client.js を使ってプラットフォーム ライブラリを読み込んでいる場合は、影響を受けますので、新しい Identity Services クライアント ライブラリを使うように既存の実装を更新する必要があります。

Google API クライアント ライブラリから gapi.client を使っているウェブ アプリケーションは、Google API を呼び出すためのアクセス トークンを扱う際に、まもなく非推奨となるプラットフォーム ライブラリの gapi.auth2 モジュールを暗黙的に読み込んで使用していますそのため、ウェブ アプリケーションを更新し、新しい Identity Services ライブラリを明示的に追加する必要があります。そのうえで、アクセス トークンのリクエストを管理するようにし、auth2 モジュールへの参照を、同等の機能を持つ新メソッドで置き換えます。

一連のアプリケーションやプラットフォームで別の手法を使って Google の認証や認可を行っている方もいるでしょう。以下は、今回のサポートの終了のお知らせの影響は受けません。

  • Android や iOS のネイティブ アプリ SDK
  • Google の OAuth 2.0 または OpenID サービスを直接呼び出しているバックエンド プラットフォーム
移行

新しい Identity Services ライブラリでは、認可機能と認証機能が明確に分かれています。

移行には、次の 2 つのガイドが役立ちます。

(1) ユーザーの認可と Google API で利用するアクセス トークンの取得をするために Google Identity Services に移行する

(2) ユーザーの認証とログインをするために Google ログインから移行する

認可（Google API を呼び出すため）と認証（ユーザーのアプリへのログインを管理するため）の両方を使っているウェブ アプリケーションもあるかもしれません。その場合は、両方の移行ガイドに従い、ウェブ アプリケーションでユーザーの認可フローと認証フローを確実に分離する必要があります。

2 つの移行ガイドは、新しい Identity Services ライブラリと古いライブラリの違い、変更点の内容、認証と認可を分離する方法、その変更がユーザーやコードベースに与える影響について理解できるように記述されています。

変更点とメリット

新しい Identity Services ライブラリに移行すると、さまざまな変更によるたくさんのメリットを活用できます。

  • ポップアップが表示されるので、ユーザーはリダイレクトされたり、サイトを離れたりすることなく、わかりやすい UX で安全にウェブ アプリケーションを認可できます。
  • デフォルトでプライバシーと制御が向上します。ユーザーは必要な場合にのみ個々のスコープを承認できるので、ウェブ アプリケーションと共有する機密データの範囲やタイミングが改善されます。
  • ID トークンとアクセス トークンという認証情報が分離されるので、ユーザーの ID とアプリケーションの機能を明確に区別できます。認証情報を分ける方が、リスクのレベルに応じた分離、管理、保存がしやすくなります。ID は、その人が誰かという情報のみを表すので、ユーザーの機密データを読み書きする機能のアクセス トークンと比べると、リスクのレベルは低くなります。
  • Chromium のプライバシー サンドボックスの変更と上位互換性があります。

この記事は、新しい Identity Services ライブラリによるプライバシー、セキュリティ、ユーザビリティの変更を簡潔にまとめたものです。さらに詳しい説明は、移行ガイドに掲載されています。

サポートの利用方法

詳しい情報は、デベロッパー サイトに掲載されています。技術サポートを受けたい方は、Stack Overflow で google-oauth タグを確認してください。提案やフィードバックがある方は、gis-migration-feedback@google.com にメールをお送りください。



Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google、プロダクト マネージャー、Vikrant Rana、グループ プロダクト マネージャー、Badi Azad による Google Developers Blog の記事 "Making Google OAuth interactions safer by using more secure OAuth flows" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google は、ユーザーがログインして、Google アカウント データをサードパーティ アプリケーションと共有できる安全な方法を提供するため、常に努力しています。その理念に基づき、OAuth インタラクション中のフィッシングやアプリのなりすましによる攻撃に対する一連の保護機能をロールアウトします。

Google のログインと認可のフローは、Google OAuth プラットフォームを利用しています。アプリ デベロッパーがサポート対象の OAuth フローを組み込めるように、ここ数年の間にたくさんの方法を開発し、サポートしています。今回は、オンラインのユーザーの安全を維持するという目的のもと、2 つのレガシーフローのサポートを終了します。デベロッパーの皆さんは、保護が強化されている別の実装方式に移行する必要があります。

スムーズな移行を実現し、サービスの中断が起きないようにするため、十分な実装の時間を提供します。以下の期日に間に合うように移行をお願いいたします。このロールアウトについては、メールでさらに最新情報をお知らせする予定です。Google API コンソールのプロジェクト設定で、サポート メールアドレスが最新になっていることをご確認ください。

ネイティブの iOS、Android、Chrome OAuth クライアント タイプでループバック IP アドレスフローを禁止

ループバック IP アドレスフローは、中間者攻撃に脆弱です。この攻撃が行われると、悪意のあるアプリが一部のオペレーティング システムで同じループバック インターフェースにアクセスし、OAuth レスポンスを傍受して認可コードを入手できる可能性があります。そこで、iOS、Android、Chrome アプリの OAuth クライアント タイプでこのフローを禁止することにより、この脅威ベクターを取り除きます。既存のクライアントは、安全性が高い実装方式に移行できます。2022 年 3 月 14 日以降、新規クライアントはこのフローを使えなくなります。

必要な対応

アプリでループバック IP アドレスフローを使っているかどうかを確認する

アプリのコードか、外向きのネットワーク呼び出し（アプリで OAuth ライブラリを使っている場合）を調べ、アプリで行っている Google OAuth 認可リクエストの “redirect_uri” パラメータに次の値が含まれているかどうかを確認してください。

redirect_uri=http://127.0.0.1:port または http://[::1]:port">http://[::1]:port または

http://localhost:port

別のフローへの移行

アプリでループバック IP アドレス方式を使っている場合は、デフォルトで安全性が高い別の方式に移行する必要があります。移行する別の方式として、以下を検討してください。

重要な期日

  • 2022 年 3 月 14 日 - 新規の OAuth 利用で、ループバック IP アドレスフローがブロックされます。
  • 2022 年 8 月 1 日 - 期日の 1 か月前より、非準拠 OAuth リクエストを使うと、ユーザーに警告メッセージが表示される場合があります。
  • 2022 年 8 月 31 日 - 既存クライアントに対して、ループバック IP アドレスフローがブロックされます。

OAuth アウトオブバンド（OOB）フローが非推奨に

OAuth のアウトオブバンド（OOB）は、レガシーフローです。ウェブアプリの場合、ユーザーが OAuth 同意リクエストを承認した後、リダイレクト URI で資格情報を受け取ることができます。このフローは、リダイレクト URI を持たないネイティブ クライアントをサポートするために開発されました。OOB フローにはリモート フィッシングのリスクがあるので、クライアントはこの脆弱性に対する保護策として、別の方式に移行する必要があります。2022 年 2 月 28 日以降、新規クライアントはこのフローを使えなくなります。

必要な対応

アプリで OOB フローを使っているかどうかを確認する

アプリのコードか、外向きのネットワーク呼び出し（アプリで OAuth ライブラリを使っている場合）を調べ、アプリで行っている Google OAuth 認可リクエストの “redirect_uri” パラメータに次の値が含まれているかどうかを確認してください。

redirect_uri=urn:ietf:wg:oauth:2.0:oob または urn:ietf:wg:oauth:2.0:oob:auto または oob

別のフローへの移行

アプリで OOB 方式を使っている場合は、デフォルトで安全性が高い別の方式に移行する必要があります。移行する別の方式として、以下を検討してください。

重要な期日

  • 2022 年 2 月 28 日 - 新規の OAuth 利用で、OOB フローがブロックされます。
  • 2022 年 9 月 5 日 - 非準拠 OAuth リクエストを使うと、ユーザーに警告メッセージが表示される場合があります。
  • 2022 年 10 月 3 日 - 既存クライアントで OOB フローが非推奨となります。

ユーザーに表示される警告メッセージ

前述の OAuth 方式がブロックされる 1 か月前から、非準拠リクエストを使うユーザーに対して警告メッセージが表示される場合があります。このメッセージは、近日中にアプリがブロックされる可能性があることをユーザーに伝えるものになります。Google API Console の OAuth 同意画面で登録されたサポートメールも表示されます。

【ユーザーに表示される警告の例】

デベロッパーは、ユーザーに表示される警告メッセージを確認したうえで、認可呼び出しの際に次のようにしてクエリ パラメータを渡すことで、メッセージを抑制することができます。

  • Google の OAuth 2.0 認可エンドポイントにリクエストを送るアプリのコードを開きます。
  • 期日を値としたパラメータを追加します。
    • OOB の場合 : ack_oob_shutdown パラメータを追加し、値として期日 2022-10-03 を指定します。例 : ack_oob_shutdown=2022-10-03
    • ループバック IP アドレスの場合 : ack_loopback_shutdown パラメータを追加し、値として期日 2022-08-31 を指定します。例 : ack_loopback_shutdown=2022-08-31

ユーザーに表示されるエラー メッセージ

期日までに基準を満たすようにアップデートされないアプリでは、認可リクエストがブロックされ、無効なリクエストを示すエラー画面がユーザーに表示される場合があります（次に例を示します）。

【ユーザーに表示されるエラーの例】


Reviewed by Eiji Kitamura - Developer Relations Team

この記事はプロダクト マネージャー、Rohey Livne による Google Developers Blog の記事 "Announcing authorization support for Google Identity Services APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Google Identity Services（GIS）

Google が最優先しているのは、オンラインのユーザーの安全を守ることです。そのため、私たちは個人情報を安全に保つための新しいツールや機能の開発に継続的に取り組んでいます。

2021 年 8 月に、新しい Identity API ファミリーとして、Google Identity Services（GIS）をリリースしました。これは、複数の ID サービスを 1 つのウェブ ソフトウェア開発キット（SDK）にまとめたものです。この SDK には、Google でログインするためのボタンや、簡単に利用できる認証プロンプトである One Tap が含まれています。Google でログインと One Tap では、パスワードではなく、セキュア トークンを利用してサイトやアプリにログインします。

今回は、このひとつに統合された Google Identity Services SDK に認可機能が追加されたことをお知らせします。これにより、この ID ソリューション スイートの価値はさらに高まり、デベロッパーもこれまで以上にシンプルに実装できるようになります。

キャプション : 個々の同意オプションが表示された認可画面

新機能

アップデート版のライブラリでは、認証と認可の両方が「ワンストップ ショップ」としてデベロッパーに提供されます。認証では、新規ユーザーが登録をしたり、登録済みのユーザーがログインしたりできます。もう一方の認可では、ユーザーの同意のもと、デベロッパーが Google API を呼び出すアクセス トークンを受け取ることができます。

デベロッパーによる細かな制御を実現するため、新しい SDK では、認証と認可のタイミングを明確に分けることがサポートされています。そのため、サイトやアプリのニーズに応じて、認証と認可の呼び出しを 2 つの独立した別々のフローとして行うことができます。

メリット

新しい SDK には、ブラウザベースのポップアップ ダイアログが使われています。そのため、サイトやアプリを利用するユーザーの手間が減り、認証や認可のフローが効率化されて、ユーザー エンゲージメントが向上します。

加えて、期限切れアクセス トークンの自動更新を削除することにより、エンドユーザーが明示的にセッションを更新しなければならなくなるため、長時間持続するトークンが意図しない目的に使われることを防ぐことができ、フロー全般のセキュリティが向上します。

さらに、新しいライブラリを使うことで、複雑な組み込み作業が軽減され、開発にかかる時間や労力を最小限にとどめることができます。組み込み作業を一層シンプルにするため、簡単に使える記述済みのスクリプトも提供します。このコード スニペットは、コピーしてパートナー サイトに直接貼り付けて使うことができます。

Google の認証や認可のフローを利用するユーザーは、2 要素認証、パスワード回復フローなどの Google が誇る最先端のセキュリティ インフラストラクチャによるメリットを活用できます。また、認可機能が有効になっているすべてのサイトやアプリで、Google が検証済みであるという安心を得ることができます。

Google Identity Services（GIS）への移行の一環として、今後もソリューションの改善を続ける予定です。今年追加される新機能にご注目ください。

新しい Google Identity Services（GIS）ライブラリを活用するには、Google のデベロッパー サイトにアクセスし、[ 始めましょう ] ボタンをクリックして技術ドキュメントをご覧ください。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事はプロダクト マネージャー、Vikrant Rana、グループ プロダクト マネージャー、Badi Azad による Google Developers Blog の記事 "Google OAuth incremental authorization improvement" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


概要

Google Identity は、データの保護において Google を信頼してくださっている Google アカウント ユーザーに充実した機能を提供すべく、日々努力を重ねています。同時に、ユーザーにすばらしい体験を提供するアプリを作るデベロッパー コミュニティにも貢献したいと考えています。Google とデベロッパーとの連携により、ユーザーは次の 3 つの重要な方法でデータの共有を管理できるようになっています。

  1. 誰が自分のアカウント データにアクセスできるかを決定する際に、ユーザーは対象を細かく制御できます。
  2. ユーザーが Google アカウントのデータをアプリと共有することにした場合、簡単かつ安全な操作で共有できます。
  3. 具体的にどんなデータをアプリと共有しているかを、ユーザーに明らかにします。

現在行っていること

以上の内容を実現するため、ユーザーが簡単にアプリとデータを共有できるようにする OAuth の同意操作についてお知らせします。この操作は、一度に 1 つのスコープしかリクエストできない段階的な認証を使っているアプリで、同意コンバージョン操作を改善するものでもあります。ユーザーは、この種のリクエストに対して、1 回のタップで簡単に共有できるようになります。
サンプルアプリがアカウント情報にアクセスする際のこれまでの画面と新しい画面のスクリーンショットの比較
これまでの画面                                           新しい画面

簡単な復習

OAuth の同意フローに対して行ってきた作業の全体像が把握できるように、これまでの改善内容を簡単にまとめておきましょう。

2019 年の中頃に、同意画面を大幅に改訂し、アプリと共有するアカウント データをユーザーが細かく制御できるようにしました。このフローでは、アプリが複数の Google リソースへのアクセスをリクエストすると、ユーザーには 1 つのスコープにつき 1 つの画面が表示されていました。

2021 年 7 月には、ユーザーが共有するデータを細かく制御できる機能は維持したまま、複数の権限リクエストを 1 つの画面にまとめました。今回の変更は、この操作の改善の延長線上にあります。
サンプルアプリがアクセスできる内容を選択する画面のスクリーンショット
Identity チームは、今後もフィードバックを集め、Google Identity サービスやアカウント データの共有に関する全般的なユーザー エクスペリエンスをさらに向上させたいと考えています。

デベロッパーが行うべきこと


アプリで必要になる変更は何もありません。ただし、段階的な認証を使って、アプリが必要とするときに一度に 1 つずつリソースをリクエストすることをお勧めします。そうすることで、アカウント データをリクエストする必要性がユーザーに伝わりやすくなるので、同意コンバージョン率が増加するはずです。段階的な認証の詳細は、デベロッパー ガイドでご確認ください。

一度に複数のリソースが必要なアプリで一部しか同意されなかった場合は、問題が起きないように処理し、OAuth 2.0 ポリシーに従って適切に機能を縮退してください。

関連コンテンツ


Reviewed by Eiji Kitamura - Developer Relations Team

この記事はプロダクト マネージャー、Lillan Marie Agerup による Google Developer Blog の記事 "Guidance to developers affected by our effort to block less secure browsers and applications" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


私たちはいつも、Google アカウントのセキュリティ保護の改善に努めています。私たちのセキュリティ システムは、さまざまなセキュリティ脅威を自動的に検知して警告し、ユーザーを保護しています。「中間者攻撃」（MITM）として知られる形態のフィッシングは、ブラウザ フレームワーク（例: Chromium Embedded Framework - CEF）に埋め込まれたり、他の自動化プラットフォームが認証に使われていたりすると、検出が難しくなります。MITM は、このようなプラットフォームの認証フローを表示し、ユーザーと Google との間の通信をインターセプトすることで、ユーザーの認証情報（場合によっては、多要素認証の 2 段階目の要素も含まれます）を集めてログインを行います。このようなタイプの攻撃からユーザーを保護するため、2021 年 1 月 4 日以降、すべての埋め込みフレームワークからの Google アカウントへのログインがブロックされます。CEF ベースのアプリやその他のサポート外ブラウザは、このブロックによって影響を受けます。

パートナーへのサービス中断を最低限にとどめるため、デベロッパーがサポート対象のユーザー エージェントで OAuth 2.0 フローを設定する際に役立ててもらえるよう、この情報を提供します。本ドキュメントでは、以下について概要を説明します。

  • 埋め込みフレームワーク ベースのアプリで、ブラウザベースの OAuth 2.0 フローを使ってログインを実現する方法
  • 互換性テストの方法

埋め込みフレームワークを使うアプリ

デバイスでの認証に CEF などのクライアントを使っているアプリのデベロッパーは、ブラウザベースの OAuth 2.0 フローを使ってください。または、対応するネイティブの完全なブラウザを使ってログインすることもできます。

ブラウザにアクセスできない場合や入力機能が限られている場合など、入力に制限のあるデバイスのアプリケーションでは、入力が制限されるデバイスの OAuth 2.0 フローを使ってください。 

ブラウザ

セキュリティ アップデートが行われているモダンブラウザは、引き続きサポートされます。

ブラウザ標準

ブラウザでは、JavaScript が有効になっている必要があります。詳細については、以前のブログ投稿をご覧ください。 

ブラウザは、ネットワーク通信のプロキシとなったり、変換を行ったりしてはいけません。ブラウザでは、以下のことを行ってはいけません。

  • サーバーサイド レンダリング
  • HTTPS プロキシ
  • リプレイ リクエスト
  • HTTP ヘッダーの書き換え

ブラウザは、妥当な範囲のウェブ標準とブラウザ機能の実装を完了している必要があります。ブラウザには、以下が含まれていないことを確認する必要があります。

  • ヘッドレス ブラウザ
  • Node.js
  • テキストベースのブラウザ

ブラウザは、User-Agent で自身を明確に識別できる必要があります。ブラウザは、Chrome や Firefox などの別のブラウザになりすまそうとしてはいけません。

ブラウザは、自動化機能を提供してはいけません。これには、キー入力やクリックを自動化するスクリプト（特に自動ログイン）を含みます。CEF や Embedded Internet Explorer などのフレームワークに基づいたブラウザからのログインは許可されません。

互換性テスト

現在 CEF を使ってログインを行っているデベロッパーは、このタイプの認証のサポートが 2021 年 1 月 4 日で終了することに注意してください。変更によって影響を受けるかどうかを確認するには、アプリケーションで互換性テストを行います。アプリケーションをテストするには、特殊な HTTP ヘッダーと値を追加して許可リストを無効にします。以下の手順で、許可リストを無効にする方法を説明します。

  1. accounts.google.com にリクエストを送信する場所に移動します。
  2. HTTP リクエスト ヘッダーに Google-Accounts-Check-OAuth-Login:true を追加します。

次の例は、CEF で許可リストを無効にする方法を説明しています。

注: カスタム ヘッダーは、CefRequestHandler#OnBeforeResourceLoad で追加できます。

 CefRequest::HeaderMap hdrMap;
 request->GetHeaderMap(hdrMap);
 hdrMap.insert(std::make_pair("Google-Accounts-Check-OAuth-Login", "true"));

Chrome で手動テストを行うには、 ModHeader を使ってヘッダーを設定します。このヘッダーを使うと、特定のリクエストに対して変更が有効になります。

ModHeader を使ったヘッダーの設定

Posted by Eiji Kitamura - Developer Relations Team

この記事は 不正使用対策テクノロジー ディレクター、Mark Risher による Google Online Security Blog の記事 "Protecting You Against Phishing" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

大多数のメールユーザーが認識しているように、フィッシング攻撃（信頼されている送信元を装い、ユーザーを欺いて情報を共有させるメール）は広く蔓延している問題です。Gmail では、毎日何百万通ものフィッシング メールが受信トレイに届く前にブロックされるので、安心できます。

今週（*原文公開当時）は、あるメール フィッシング攻撃を防ぐことができました。これは、フィッシング メールを広めるために、意図せずに連絡先情報へのアクセスを許可させようとするものでした。私たちは、早急なアクションによって、攻撃者に付与されたアクセス権を無効にし、今後、このタイプの攻撃の亜種による被害を防ぐための対策を実施することができました。

本投稿では、この攻撃の仕組みや対処方法、そして攻撃から身を守る方法を理解していただくために、その背景について説明します。

攻撃の仕組みと対処方法 

この攻撃の被害者は、連絡先のいずれかから Google Doc への招待のように見えるメールを受信しています。ユーザーが攻撃者からのメールにあるリンクをクリックすると、攻撃者のアプリケーションが開きます。その際に、Google Doc へのアクセス権付与を装ってユーザー アカウントへのアクセスがリクエストされます。ユーザーがアプリケーションによるアクセスを許可（これは、OAuth と呼ばれているメカニズムによります）すると、ユーザーの連絡先リストに対して同じメッセージが送信されます。

この問題が検知された際に、即座に自動と手動を組み合わせた対策を行いました。その結果、この攻撃は 1 時間以内に収束することになりました。私たちは、偽のページとアプリケーションを削除し、セーフ ブラウジング、Gmail、Google Cloud Platform、その他の不正使用対策システムでユーザーを保護するためのアップデートをプッシュしました。この攻撃の影響を受けたユーザーは 0.1% 未満であり、影響を受けたアカウントのセキュリティも復旧されています。

私たちは、以下を始めとするさまざまな方法でユーザーをフィッシング攻撃から守っています。
  • 機械学習ベースでスパムやフィッシング メッセージを検出します。スパム検知の正確性は、99.9% です。 
  • Gmail や 20 億以上のブラウザで、危険なリンクに対してセーフ ブラウジング警告を行います。 
  • 動的なリスクベースの方式により、疑わしいアカウントへのログインをブロックします。 
  • メールの添付ファイルに対して、不正なソフトウェアなどの危険なペイロードをスキャンします。 

さらに、今後もこのタイプの攻撃に備えるため、ポリシーや OAuth 適用の強制に関するアップデート、今回のような攻撃を防ぐためのアンチスパム システムのアップデート、ユーザーの情報をリクエストする疑わしいサードパーティ製アプリの監視強化など、複数の対策を行っていきます。

ユーザーが自分自身を守るためにできること 

私たちは Google アカウントを安全に保つための努力を続けています。また、私たちには、異常な動作を検知するハイジャック対策システムから、悪意のあるコンテンツをブロックする機械学習モデル、Chrome の保護機能、疑わしいサイトへのアクセスをブロックするセーフ ブラウジングまで、あらゆる種類の高度な攻撃から身を守るための保護レイヤーがあります。加えて、ユーザーが自分自身を守るために行えることがいくつかあります。

ユーザーを守るために G Suite 管理者ができること 

OAuth アクセスを付与してしまったユーザーがいる G Suite ユーザーには、個別に通知しています。この件で管理者やユーザーが追加で操作を行う必要はありませんが、G Suite 管理者の方は、全般的なセキュリティを向上させる以下のベスト プラクティスについて検討してください。
 ウェブ上で安全に過ごすためのおすすめの方法やツールのリストは、こちらからご覧ください。



Posted by Eiji Kitamura - Developer Relations Team

この記事は 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

この記事は Michael Winser、 Google Apps プロダクト リード、Wesley Chun、Google Apps デベロッパー アドボケートによる Google Apps Developer Blog の記事 "Google Apps Developer Blog: Increased account security via OAuth 2.0 token revocation" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


先週（*原文公開当時）、OAuth 2.0 から Google のユーザーデータにアクセスする際の想定事項と責任を明確化しました。本日は、ユーザーの保護を強化するため、エンタープライズ Gmail ユーザーのアカウント セキュリティを強化することをお知らせいたします。これは、2016 年 10 月 5 日から有効になります。現在、新しいポリシーが反映される予定になっていますが、Google Apps ドメインのユーザーが この日以降にパスワードを変更すると、Gmail ベースの認証スコープを使ってメールボックスにアクセスするアプリの OAuth 2.0 トークンが取り消されることになります。ユーザーはこの日に変更が行われることを意識する必要はなく、アプリケーションは動作を続けます。これ以降にユーザーがパスワードを変更した場合のみ、Gmail 関連のトークンが無効になります。

デベロッパーは、トークンが取り消されたことによる HTTP 400 または 401 エラーコードを処理するようにアプリケーションを変更し、その際、アプリが再びメールボックスにアクセスできるよう、ユーザーが再度 OAuth フローを実行してアプリを再認証することをうながす必要があります（詳細は後述）。昨年後半にも、幅広い認証スコープに影響する同じようなセキュリティ ポリシーの変更計画についてお知らせしました。その後、Apps ユーザーに対してはこの変更を行わないことを決定し、上記のような影響が少ないアップデートについて作業を進めてきました。


取り消されたトークンとは

取り消された OAuth 2.0 トークンでは、ユーザーのリソースにはアクセスできません。API 呼び出しで取り消されたトークンを使うとエラーになります。既存のトークン文字列に値はなくなり、破棄されます。Google API にアクセスするアプリケーションは、API 呼び出しの失敗に対応するように変更する必要があります。

トークンの取り消し自体は、新しい機能ではありません。今までも、ユーザーはアプリケーションへのアクセスをアカウント情報から取り消すことができました。また、Google Apps 管理者も管理コンソールから同じことを行うことができます。さらに、長期間使われなかったトークンも、期限切れや取り消しの対象になっています。今回のセキュリティ ポリシーの変更によって、この処理が自動的に行われるようになるため、アプリケーションが取り消されたトークンを目にする比率が高まることが考えられます。


影響を受ける API とスコープ

できるだけ管理者を困らせたりエンドユーザーを混乱させたりせずに、今回のポリシー変更によるセキュリティ的なメリットを実現するため、変更の適用範囲をメールスコープのみに限定し、Apps スクリプト トークンは除外することにしました。Google Apps Marketplace からインストールしたアプリも、トークンの取り消しの対象にはなりません。この変更が行われると、Apple Mail や Thunderbird などのサードパーティのメールアプリや、少なくとも 1 つのメールスコープを含む複数のスコープを使用するアプリケーションは、パスワードの再設定を行ってから新しい OAuth 2.0 トークンが付与されるまで、データにアクセスできなくなります。アプリケーションでは、このシナリオを検知し、アプリケーションからアカウント データにアクセスできなくなったことをユーザーに通知し、ユーザーに再度 OAuth 2.0 フローを行ってもらう必要があります。

モバイル メールアプリもこのポリシー変更に含まれます。たとえば、iOS のネイティブ メールアプリのユーザーは、パスワードを変更した際に Google アカウントの認証情報を使って再認証する必要があります。モバイルでのサードパーティ メールアプリの新しい動作は、iOS と Android の Gmail アプリの現在の動作と一致しています。Gmail アプリも、パスワードの再設定時に再認証が必要になります。


取り消されたトークンの判定方法

ユーザーがパスワードを変更すると、一時的なアクセス トークンと長期間のリフレッシュ トークンの両方が取り消されます。API アクセスに取り消されたトークンを使ったり、新しいアクセス トークンを生成したりすると、HTTP 400 または 401 エラーが発生します。アプリケーションで API にアクセスしたり OAuth フローを処理するライブラリを使用している場合、エラーが例外としてスローされる可能性もあります。例外をキャッチする方法については、ライブラリのドキュメントをご確認ください。注: HTTP 400 エラーはさまざまな理由で発生する可能性があります。取り消されたトークンが原因で発生する 400 エラーのペイロードは次のようになります。 
{
  "error_description": "Token has been revoked.", 
  "error": "invalid_grant"
}


アプリケーションでの取り消されたトークンの扱い方

この変更に関する重要な点は、トークンの取り消しはエラー シナリオではなく、通常の状態を想定すべきであるということです。アプリケーションでは、この状態を予期して検知し、トークンの復元に最適な UI を提供する必要があります。

アプリケーションが正常に動作するよう、以下を行うことを推奨いたします。
  • 取り消されたトークンを検知する可能性がある API 呼び出しやトークンのリフレッシュ処理の周辺にエラー処理コードを追加します。
  • 取り消されたトークンを検知した際は、ユーザーがアプリケーションを再認証するまで、Google API アクセスを利用するすべてのアプリケーション機能を無効化します。たとえば、影響を受ける可能性がある Google API とデータを同期するバックグラウンド ジョブの実行を停止します。
  • アクセスが取り消されたユーザーに通知し、リソースへのアクセスを再認証してもらうよう要求します。
    • アプリが 直接 ユーザーとインタラクションする場合は、ユーザーに再認証を要求する必要があります（ユーザーに電子メールを送信、次回アプリケーションを開いた際にアラートを表示）。
    • ただし、アプリがユーザーから 独立 して実行されている場合、たとえば Gmail API を利用するバックグラウンド アプリの場合は、電子メールやその他の仕組みを利用してユーザーに通知する必要があります。
    • 再認証のアクセス用に効率的な UI を提供し、ユーザーがアプリケーションで元の設定を探し回ることがないようにします。
    • トークンが取り消されると、どのように取り消されたのかにはよらず、同じエラー メッセージになります。パスワード変更によってトークンが取り消されたことを前提としたメッセージにはしないでください。

アプリケーションで同じトークンに複数のスコープを一括して段階的に認証している場合、ユーザーが有効にしている機能やスコープをトラッキングする必要があります。最終的に、アプリが複数のスコープの認証をリクエストして取得しており、少なくともその 1 つがトークンの取り消されたメールスコープである場合、もともと付与されている すべての スコープを再認証するようユーザーに要求する必要があります。

多くのアプリケーションで、トークンを利用したバックグラウンドまたはサーバー対サーバーの API 呼び出しが行われています。ユーザーは、バックグラウンド動作が確実に継続することを期待しています。今回のポリシー変更は、 そのような アプリにも影響するため、即座に再認証のリクエストを通知することがさらに重要になります。


今回の変更のタイムライン

まとめると、適切に設定されたアプリケーションには、期限切れ、存在なし、取り消しなどによる無効なトークンを通常の状態と同様に汎用的に処理することが求められます。ユーザーにできる限り最高の体験をしていただけるよう、デベロッパーの皆様には必要な変更を行うことをお勧めします。ポリシーの変更は、2016 年 10 月 5 日に実施される予定です。

詳細およびメールスコープの完全なリストについては、ヘルプセンターのよくある質問の記事をご覧ください。今後、このポリシーに他のスコープが追加される際には、事前にお知らせいたします。詳細は、わかり次第お伝えします。


Posted by Eiji Kitamura - Developer Relations Team

[この記事は William Denniss、ID および認証担当プロダクト マネージャーによる Google Developers Blog の記事 "Modernizing OAuth interactions in Native Apps for Better Usability and Security" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google ユーザーが Google アカウントを使って安全かつシームレスにサードパーティ アプリケーションへログインし、そのアカウントから選択したカレンダーや連絡先情報などの情報を他のアプリと自由に共有できるよう、ID チームは常に努力しています。

このようなインタラクションの背後で実行されているのが OAuth リクエストです。Google は何年もの間、デベロッパーの皆様が OAuth フローを実装するさまざまな方法をサポートしています。その方法の 1 つについて、セキュリティとユーザビリティの向上を考慮した結果、近日中にサポートを終了することになりました。数か月後、「ウェブビュー」と言われる埋め込みブラウザから Google への OAuth リクエストは許可されなくなります。ウェブビューには、Android の WebView UI 要素や iOS の UIWebView/WKWebView、Windows や OS X での同等の要素が含まれます。

埋め込みウェブビューではなく、端末のブラウザを使用して OAuth リクエストを行うことにより、アプリのユーザビリティは大幅に向上します。ユーザーは端末で 1 度だけ Google にログインすればいいため、アプリでのログインのコンバージョン率や認証フローが改善されます。Android の Chrome Custom Tab や iOS の SFSafariViewController など、いくつかのオペレーティング システムで利用できる最新の「アプリ内ブラウザタブ」パターンを使うと、ブラウザベースの OAuth フローの UX をさらに改善できます。

逆に、OAuth に埋め込みブラウザを使用する古い方式では、端末の既存のログイン済みセッションを使うことはできないため、ユーザーはその都度 Google にログインする必要があります。ウェブビューの内容はアプリが検査したり変更したりできますが、ブラウザ内に表示されるコンテンツではそれができないため、端末のブラウザの方がセキュリティが高くなります。

この移行をサポートするため、皆様が利用できる最新のベスト プラクティスに基づくライブラリとサンプルを公開しています。
  • Google Sign-In: Android と iOS 向け。Google アカウントを使ったログインと OAuth の推奨 SDK です。
  • AppAuth: Android と iOS および OS X 向け。Google などの OAuth プロバイダで使用できるオープンソース OAuth クライアント ライブラリです。さらに、Objective-C 向け Google API クライアント ライブラリで AppAuth サポートを有効にするライブラリ GTMAppAuth（iOS および OS X 向け）と、GTM Session Fetcher プロジェクトも提供しています。
  • Windows 向け Google Sign-In および OAuth サンプル: Universal Windows Platform（UWP）コンソールや PC アプリなど、さまざまな Windows 環境からブラウザを使って Google ユーザーを認証する方法を説明するサンプルです。

ネイティブ アプリの標準ベースの OAuth サポートに関するプロトコル レベルのドキュメントや、このトピックに関する現在の IETF のベスト プラクティスのドラフトもご覧ください。

バージョン 3.0 以前の iOS で使われているバージョンの Google Sign-In も、アプリ内ブラウザタブの現在の業界のベスト プラクティスに対応していないため、サポートを終了します。Google Sign-In を使用する場合は、最新のバージョンにアップデートし、セキュリティやユーザビリティを最新の状態にしてください。現在のところ、このポリシーによって iOS 8 の WebView のサポートが終了することはありませんが、今後、セキュリティ向上のために端末をアップグレードすることを促す通知がユーザーに表示される可能性があります。

ウェブビューでの Google への OAuth リクエストのサポート終了スケジュールは、次のようになっています。2016 年 10 月 20 日以降、有効な代替手段があるプラットフォームで、新しい OAuth クライアントがウェブビューを使用することを禁止し、段階的に既存の OAuth クライアントのユーザーに対して通知を表示します。2017 年 4 月 20 日に、有効な代替手段があるプラットフォーム上のすべての OAuth クライアントに対し、ウェブビューからの OAuth リクエストのブロックを開始します。

移行に関する質問がある方は、「google-oauth」タグをつけて Stack Overflow に投稿してください。



Posted by Eiji Kitamura - Developer Relations Team

[この記事は、Vartika Agarwal、アイデンティティ＆認証担当テクニカル プログラム マネージャー、Wesley Chun、Google デベロッパー アドボケートによる Google Apps Developer Blog の記事 "Saying goodbye to OAuth 1.0 (2LO)" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

2012 年にお知らせしたように、最新の OAuth 標準である OAuth 2.0 のサポートに集中するため、OAuth 1.0 プロトコルからの移行を行っています。OAuth 2.0 はセキュリティを強化し、開発の煩雑さも軽減しています。OAuth 1.0（3LO）1 のサポートは、2015 年 4 月 20 日に終了しましたが、今回の最終フェーズでは、OAuth 1.0（2LO）のサポートを 2016 年 10 月 20 日に終了する予定です。新しい標準に移行する最も簡単な方法は、ドメインレベルの委任による OAuth 2.0 サービス アカウントを使用することです。

廃止されるプロトコルを使用しているアプリケーションは、サポート終了日までに移行する必要があります。そうしないと、サポートされているプロトコルへの移行が完了するまでアプリケーションが Google に接続できなくなり、ログインもできなくなる可能性があります。エンドユーザーに対するサービス レベルが低下しないよう、サポート終了までにアプリケーションの移行を完了してください。

このステップによってGoogle は、従来の認証 / 認可プロトコルからの移行を継続し、Google アカウントのセキュリティをさらに強固にするとともにデベロッパーが容易に実装できる最新のオープン スタンダードに集中していきます。アプリケーションの移行に関する技術的なご質問は、Stack Overflow に google-oauth タグで投稿してください。

1 3LO とは 3-Legged OAuth を意味し、同意するエンドユーザーが存在します。これとは異なり、2-Legged OAuth（2LO）は組織全体へのポリシーによるアクセス制御の強制といった企業向けの認証シナリオに対応したもので、エンドユーザーが関与することはありません。

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

[本記事は、Identity and Authentication の Tech Lead である Ryan Troll が書いた"Reminder: ClientLogin Shutdown scheduled for April 20, 2015"を元に翻訳・再構成しました。-北村]

新しい Google Data API への移行についてのお知らせで以前にもお伝えしましたが、デベロッパーの皆様にもう一度お知らせいたします。ClientLogin のサポートがもうすぐ終了します。サポートの終了後は ClientLogin を使っているアプリケーションは動作しなくなりますので、ご注意ください。ユーザーの混乱を避けるため、OAuth 2.0 への切り替えをお勧めします。

Google ではユーザーのデータの保護を最優先し、リスク分析の結果から大多数のアカウント乗っ取り被害を防いでいます。Google のリスク分析システムでは、パスワード以外にも多くの兆候を考慮してユーザー データの保護に努めています。パスワードだけに頼った認証形態ではいくつもの点で不十分であることはよく知られており、Google では一歩進んだ対応を積極的に行っています。OAuth 2.0 に切り替えることで、Google の認証保護に対する取り組みの結果を、皆さんのアプリケーションから Google サービスにサインインするユーザーのために使うことができます。

Google では、パスワードだけに頼った認証から脱却するため、まずは ClientLogin を 2015 年 4 月 20 日に廃止することを 3 年前に発表し、同時に Google の API で使う認証メカニズムの標準として、 OAuth 2.0 を推奨することをお伝えしました。OAuth 2.0 を使ったアプリケーションでは、ユーザーにパスワードを求めることは一切なく、またクライアント アプリケーションからアクセスできるデータ全般をさらに厳重に管理できます。 OAuth 2.0 を使うことで、安全にアカウント データにアクセスできるクライアント アプリや Web サイトを作成できます。また、 2 段階認証プロセスなど Google の優れたセキュリティ機能を活用できるようになります。

パスワード認証については、他のプロトコルを使った別の手法も用意しています。 CalDAV API V2 は OAuth 2.0 のみサポートしています。また、 IMAP、SMTP、XMPP への OAuth 2.0 のサポート を追加しています。これらのプロトコルでのパスワード認証の廃止予定の日程はまだ発表されていませんが、デベロッパーの皆さんには OAuth 2.0 への移行を強くお勧めします。

Posted by Eiji Kitamura - Developer Relations Team

Posted by 山崎富美 / Developer Relations Team

Google Developer Day 2011 のブレイクアウトセッションのご紹介、今回は 前坂徹 による 「データアクセスと本人認証のための OAuth と OpenID」 です。



セッション内容:

ウェブアプリが Google クラウドが管理するユーザーデータにアクセスするために OAuth 2.0 をどのように使用するかを説明します。また、OAuth 2.0 と OpenID Connect を使用した、追加パスワード不要のシームレスなサイト認証についても説明します。実装の容易さとユーザーエクスペリエンスは重要なトピックであり、Google Identity Toolkit と Account Chooser との関連についても議論します。

動画はこちら:



スライドはこちら

Posted by 山崎富美 / Developer Relations Team

Google Developer Day 2011 Japan では、数々の TechTalk もご準備しております。また、講演後に Office Hour のコーナーにいけば、スピーカーと直接話をし、質問もできるのが Google Developer Day 参加のメリットの一つです。ぜひご参加ください。


13:00-13:45 AdWords API の developer advocate である前坂徹 による 「ウェブアプリにおけるデータアクセスと本人認証のための OAuth と OpenID」。ウェブアプリが、Google クラウドで管理されるユーザーデータにアクセスするために OAuth 2.0 をどのように使用するか。また、OAuth 2.0 と OpenID Connect を使用した、追加パスワード不要のシームレスなサイト認証について、そして Google Identity Toolkit と Account Chooser についてもお話します。


17:00-17:45 Web Warrior の Greg Schechter と YouTube Web Developer の Phil Harnish によるセッション 「HTML5 と Flash を比較する: YouTube 動画を高速化するテクノロジー」。HTML5 は新しく強力で素晴らしい技術ですが、動画配信での地位を確立した Flash と何が違い、動画を更に高速化できるのはどちらの技術なのでしょうか？本セッションでは、HTML5 と YouTube がウェブ上の動画配信にどのような変化をもたらすかをご紹介します。

皆様に会場でお会いできるのを楽しみにしております。