OAuthとリンクするGoogleアカウント

アカウントは、業界標準のOAuth2.0暗黙的および認証コードフローを使用してリンクされます。サービスは、OAuth2.0準拠の承認トークン交換エンドポイントをサポートする必要があります。

暗黙的なフローでは、Googleはユーザーのブラウザで認証エンドポイントを開きます。サインインに成功すると、長期間有効なアクセストークンをGoogleに返します。このアクセストークンは、Googleから送信されるすべてのリクエストに含まれるようになりました。

認証コードフローでは、2つのエンドポイントが必要です。

  • 既に署名されていないユーザーにサインインUIを提示認可エンドポイントは、。認可エンドポイントはまた、要求されたアクセスにレコードのユーザーの同意に短命認証コードを作成します。

  • トークン交換エンドポイント。2種類の交換を担当します。

    1. 認証コードを、有効期間の長い更新トークンと有効期間の短いアクセストークンに交換します。この交換は、ユーザーがアカウントリンクフローを通過するときに発生します。
    2. 有効期間の長い更新トークンを有効期間の短いアクセストークンと交換します。この交換は、有効期限が切れたためにGoogleが新しいアクセストークンを必要とするときに発生します。

OAuth2.0フローを選択します

暗黙的なフローの実装は簡単ですが、暗黙的なフローによって発行されたアクセストークンが期限切れにならないようにすることをお勧めします。これは、トークンが暗黙のフローで期限切れになった後、ユーザーがアカウントを再度リンクすることを強制されるためです。セキュリティ上の理由でトークンの有効期限が必要な場合は、代わりに認証コードフローを使用することを強くお勧めします。

設計ガイドライン

このセクションでは、OAuthリンクフロー用にホストするユーザー画面の設計要件と推奨事項について説明します。 Googleのアプリによって呼び出された後、プラットフォームはGoogleページへのサインインとユーザーへのアカウントリンク同意画面を表示します。ユーザーは、アカウントのリンクに同意した後、Googleのアプリに戻されます。

この図は、ユーザーが自分のGoogleアカウントを認証システムにリンクするための手順を示しています。最初のスクリーンショットは、プラットフォームからのユーザーが開始したリンクを示しています。 2番目の画像はユーザーがGoogleにサインインしていることを示し、3番目の画像はユーザーの同意とユーザーのGoogleアカウントをアプリにリンクすることの確認を示しています。最後のスクリーンショットは、Googleアプリで正常にリンクされたユーザーアカウントを示しています。
図1.ユーザーがGoogleにサインインして同意画面にリンクしているアカウント。

要件

  1. ユーザーのアカウントは、GoogleホームやGoogleアシスタントなどの特定のGoogle製品ではなく、Googleにリンクされることを伝える必要があります。

推奨事項

次のことを行うことをお勧めします。

  1. Googleのプライバシーポリシーを表示します。同意画面にGoogleのプライバシーポリシーへのリンクを含めます。

  2. 共有するデータ。明確で簡潔な言葉を使用して、Googleが必要とするデータとその理由をユーザーに伝えます。

  3. 召喚状を明確にします。 「同意してリンクする」など、同意画面に明確な召喚状を記載します。これは、ユーザーがアカウントをリンクするためにGoogleと共有する必要があるデータを理解する必要があるためです。

  4. キャンセルする機能。リンクしないことを選択した場合、ユーザーが戻るかキャンセルする方法を提供します。

  5. サインインプロセスをクリアします。ユーザーは、自分のユーザ名とパスワード、またはのためのフィールドとして、自分のGoogleアカウントにログインするための明確な方法があることを確認してくださいGoogleアカウントでサインインし

  6. リンクを解除する機能。プラットフォームのアカウント設定へのURLなど、ユーザーがリンクを解除するためのメカニズムを提供します。または、ユーザーがリンクされたアカウントを管理できるGoogleアカウントへのリンクを含めることもできます。

  7. ユーザーアカウントを変更する機能。ユーザーが自分のアカウントを切り替える方法を提案します。これは、ユーザーが複数のアカウントを持っている傾向がある場合に特に役立ちます。

    • ユーザーがアカウントを切り替えるために同意画面を閉じる必要がある場合は、回復可能なエラーをGoogleに送信して、ユーザーがOAuthリンク暗黙的なフロー使用して目的のアカウントにサインインできるようにします。
  8. あなたのロゴを含めてください。同意画面に会社のロゴを表示します。スタイルガイドラインを使用してロゴを配置します。 Googleのロゴも表示したい場合は、ロゴと商標を参照してください。

建立专案

要创建您的项目以使用帐户链接:

  1. Go to the Google API Console.
  2. [ プロジェクトを作成]をクリックします
  3. 名前を入力するか、生成された提案を受け入れます。
  4. 残りのフィールドを確認または編集します。
  5. 作成をクリックします

プロジェクトIDを表示するには:

  1. Go to the Google API Console.
  2. ランディングページの表でプロジェクトを見つけます。 ID列にプロジェクトIDが表示されます。

Google帐户链接过程包括一个同意屏幕,该屏幕告诉用户请求访问其数据的应用程序,他们要求的数据类型以及适用的条款。在生成Google API客户端ID之前,您需要先配置OAuth同意屏幕。

  1. 打开Goog​​le API控制台的OAuth同意屏幕页面。
  2. 如果出现提示,请选择刚刚创建的项目。
  3. 在“ OAuth同意屏幕”页面上,填写表格,然后单击“保存”按钮。

    申请名称:要求同意的申请名称。该名称应准确反映您的应用程序,并与用户在其他地方看到的应用程序名称一致。应用程序名称将显示在“帐户链接同意”屏幕上。

    应用程序徽标:同意屏幕上的图像,可帮助用户识别您的应用程序。徽标显示在“帐户链接同意”屏幕和帐户设置上

    支持电子邮件:供用户与您联系以获取有关其同意的问题。

    Google API范围范围允许您的应用访问用户的私人Google数据。对于Google帐户关联用例,默认范围(电子邮件,个人资料,openid)就足够了,您无需添加任何敏感范围。通常,最佳做法是在需要访问时而不是预先请求增量地作用域。 了解更多

    授权域:为了保护您和您的用户,Google仅允许使用OAuth进行身份验证的应用程序使用授权域。您的应用程序的链接必须托管在授权域中。 了解更多

    应用程序主页链接:您的应用程序的主页。必须托管在授权域上。

    应用程序隐私权政策链接:显示在Google Acount Linking同意屏幕上。必须托管在授权域上。

    应用程序服务条款链接(可选):必须托管在授权域中。

    图1 。虚拟应用程序Google Tuning的Google帐户链接同意屏幕

  4. 选中“验证状态”,如果您的应用程序需要验证,则单击“提交验证”按钮以提交您的应用程序以进行验证。有关详细信息,请参阅OAuth验证要求

OAuthサーバーを実装する

認証コードフローのOAuth 2.0のサーバーの実装では、あなたのサービスは、HTTPSで利用できるように2つのエンドポイント、から構成されています。最初のエンドポイントは承認エンドポイントであり、データアクセスについてユーザーからの同意を検索または取得する責任があります。承認エンドポイントは、まだサインインしていないユーザーにサインインUIを提示し、要求されたアクセスへの同意を記録します。 2番目のエンドポイントは、トークン交換エンドポイントです。これは、トークンと呼ばれる暗号化された文字列を取得するために使用され、ユーザーにサービスへのアクセスを許可します。

GoogleアプリケーションがサービスのAPIの1つを呼び出す必要がある場合、Googleはこれらのエンドポイントを一緒に使用して、ユーザーからユーザーに代わってこれらのAPIを呼び出す許可を取得します。

Googleによって開始されたOAuth2.0認証コードフローセッションには、次のフローがあります。

  1. Googleは、ユーザーのブラウザで認証エンドポイントを開きます。アクションの音声のみのデバイスでフローが開始された場合、Googleは実行を電話に転送します。
  2. ユーザーは、まだサインインしていない場合はサインインし、まだアクセス許可を付与していない場合は、APIを使用してデータにアクセスするためのGoogleアクセス許可を付与します。
  3. あなたのサービスは、認証コードを作成し、Googleにそれを返します。これを行うには、リクエストに認証コードを添付して、ユーザーのブラウザをGoogleにリダイレクトします。
  4. Googleは、コードの正当性を検証し、アクセストークンリフレッシュトークンを返し、あなたのトークン交換エンドポイントに認証コードを送信します。アクセストークンは、APIにアクセスするための資格情報としてサービスが受け入れる短期間のトークンです。更新トークンは、有効期限が切れたときにGoogleが保存して、新しいアクセストークンを取得するために使用できる長期間有効なトークンです。
  5. ユーザーがアカウントのリンクフローを完了すると、Googleから送信される後続のすべてのリクエストにアクセストークンが含まれます。

承認リクエストを処理する

OAuth 2.0認証コードフローを使用してアカウントのリンクを実行する必要がある場合、Googleは次のパラメータを含むリクエストを使用してユーザーを認証エンドポイントに送信します。

承認エンドポイントパラメータ
client_id Googleに割り当てたクライアントID。
redirect_uriこのリクエストへの応答を送信するURL。
stateリダイレクトURIで変更されずにGoogleに返される簿記の値。
scopeオプション:Googleがために許可を要求しているデータを指定範囲の文字列のスペース区切りのセット。
response_type応答で返す値のタイプ。 OAuth 2.0の認証コードの流れについては、応答タイプは常にあるcode
user_localeでGoogleアカウントの言語設定RFC5646のユーザーの優先言語でコンテンツをローカライズするために使用される形式、。

あなたの認可エンドポイントがで利用可能である場合たとえば、 https://myservice.example.com/auth 、要求は次のようになります。

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

承認エンドポイントがサインイン要求を処理するには、次の手順を実行します。

  1. ていることを確認しclient_id Googleに割り当てられたクライアントIDと一致すること、およびredirect_uriあなたのサービスのためにGoogleが提供するリダイレクトURLと一致します。これらのチェックは、意図しないクライアントアプリや誤って構成されたクライアントアプリへのアクセスを許可しないようにするために重要です。あなたが複数のOAuth 2.0のフローをサポートしている場合、またことを確認response_typeあるcode
  2. ユーザーがサービスにサインインしているかどうかを確認します。ユーザーがサインインしていない場合は、サービスのサインインまたはサインアップフローを完了します。
  3. GoogleがAPIへのアクセスに使用する認証コードを生成します。認証コードには任意の文字列値を指定できますが、ユーザー、トークンの対象となるクライアント、およびコードの有効期限を一意に表す必要があり、推測できないようにする必要があります。通常、約10分後に有効期限が切れる認証コードを発行します。
  4. URLがで指定されていることを確認redirect_uriパラメータは次の形式を持っている:
      https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
      https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
      
  5. で指定されたURLにユーザーのブラウザをリダイレクトredirect_uriパラメータ。あなたが追加することによってリダイレクトするときにだけ生成された認証コードとオリジナルの、無修正の状態値を含めるcodestateのパラメータを。以下は、得られたURLの例です:
    https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

トークン交換リクエストを処理する

サービスのトークン交換エンドポイントは、次の2種類のトークン交換を担当します。

  • アクセストークンと更新トークンの認証コードを交換します
  • 更新トークンをアクセストークンと交換する

トークン交換リクエストには、次のパラメータが含まれます。

トークン交換エンドポイントパラメーター
client_idリクエストの発信元をGoogleとして識別する文字列。この文字列は、Googleの一意の識別子としてシステム内に登録する必要があります。
client_secretサービスのためにGoogleに登録した秘密の文字列。
grant_type交換されるトークンのタイプ。それはどちらかだauthorization_codeまたはrefresh_token
codeときgrant_type=authorization_code 、このパラメータは、Googleがあなたのサインインまたはトークン交換エンドポイントのいずれかから受信したコードです。
redirect_uriときgrant_type=authorization_code 、このパラメータは、最初の認証要求で使用されるURLです。
refresh_tokenときgrant_type=refresh_token Googleがあなたのトークン交換エンドポイントから受信したトークンは、このパラメータは、リフレッシュです。
アクセストークンと更新トークンの認証コードを交換します

ユーザーがログインし、認証エンドポイントが短期間の認証コードをGoogleに返すと、Googleはトークン交換エンドポイントにリクエストを送信して、認証コードをアクセストークンと更新トークンに交換します。

これらの要求のために、の値grant_typeありauthorization_code 、との値code以前にGoogleに付与された認証コードの値です。次に、認証コードをアクセストークンと更新トークンに交換するリクエストの例を示します。

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

アクセストークンとリフレッシュトークン、トークン交換エンドポイントの応答のための交換認証コードへPOSTは、次の手順を実行して要求:

  1. ことを確認しclient_id認可原点として要求元を識別し、そのclient_secret期待値と一致します。
  2. 認証コードが有効で有効期限が切れていないこと、および要求で指定されたクライアントIDが認証コードに関連付けられたクライアントIDと一致することを確認してください。
  3. URLがで指定されていることを確認redirect_uriパラメータは、最初の認証要求で使用される値と同じです。
  4. あなたが上記の基準のすべてを確認できない場合は、とHTTP 400不正な要求エラーを返す{"error": "invalid_grant"}ボディとして。
  5. それ以外の場合は、認証コードのユーザーIDを使用して、更新トークンとアクセストークンを生成します。これらのトークンは任意の文字列値にすることができますが、トークンの対象となるユーザーとクライアントを一意に表す必要があり、推測可能であってはなりません。アクセストークンの場合は、トークンの有効期限も記録します。これは通常、トークンを発行してから1時間後です。更新トークンは期限切れになりません。
  6. HTTPS応答の本文に以下のJSONオブジェクトを返します:
    {
    "token_type": "Bearer",
    "access_token": "ACCESS_TOKEN",
    "refresh_token": "REFRESH_TOKEN",
    "expires_in": SECONDS_TO_EXPIRATION
    }
    

Googleは、ユーザーのアクセストークンと更新トークンを保存し、アクセストークンの有効期限を記録します。アクセストークンの有効期限が切れると、Googleは更新トークンを使用してトークン交換エンドポイントから新しいアクセストークンを取得します。

更新トークンをアクセストークンと交換する

アクセストークンの有効期限が切れると、Googleはトークン交換エンドポイントにリクエストを送信して、更新トークンを新しいアクセストークンと交換します。

これらの要求のために、の値grant_typeされrefresh_token 、との値refresh_token以前にGoogleに付与されたリフレッシュトークンの値です。以下は、更新トークンをアクセストークンと交換するリクエストの例です。

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

アクセストークンのリフレッシュトークン、トークン交換エンドポイントの応答を交換するにはPOST次のステップを実行することにより、要求:

  1. ていることを確認しclient_idグーグルとして要求元に識別し、そのclient_secret期待値と一致しました。
  2. 更新トークンが有効であること、および要求で指定されたクライアントIDが更新トークンに関連付けられたクライアントIDと一致することを確認します。
  3. あなたが上記の基準のすべてを確認できない場合は、とHTTP 400不正な要求エラーを返す{"error": "invalid_grant"}ボディとして。
  4. それ以外の場合は、更新トークンのユーザーIDを使用してアクセストークンを生成します。これらのトークンは任意の文字列値にすることができますが、トークンの対象となるユーザーとクライアントを一意に表す必要があり、推測可能であってはなりません。アクセストークンの場合は、トークンの有効期限も記録します。通常は、トークンを発行してから1時間後です。
  5. HTTPS応答の本文で次のJSONオブジェクトを返します。
    {
    "token_type": "Bearer",
    "access_token": " ACCESS_TOKEN ",
    "expires_in": SECONDS_TO_EXPIRATION
    }
userinfoリクエストを処理する

ユーザー情報エンドポイントは、リンクされたユーザについての戻り主張OAuth 2.0の保護されたリソースです。次のユースケースを除いて、userinfoエンドポイントの実装とホスティングはオプションです。

トークンエンドポイントからアクセストークンが正常に取得されると、Googleはuserinfoエンドポイントにリクエストを送信して、リンクされたユーザーに関する基本的なプロファイル情報を取得します。

userinfoエンドポイントリクエストヘッダー
Authorization headerタイプBearerのアクセストークン。

たとえば、あなたのuserinfoエンドポイントがで利用可能な場合https://myservice.example.com/userinfo 、要求は次のようになります。

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

userinfoエンドポイントでリクエストを処理するには、次の手順を実行します。

  1. Authorizationヘッダーからアクセストークンを抽出し、アクセストークンに関連付けられているユーザーの情報を返します。
  2. アクセストークンが無効である場合は、使用してHTTP 401不正なエラーを返すWWW-Authenticate応答ヘッダを。以下のユーザー情報のエラー応答の例である:
    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: error="invalid_token",
    error_description="The Access Token expired"
    
    401不正な、または他の任意の失敗エラー応答をリンク処理中に返された場合、エラーが回復不能、検索されたトークンは廃棄されることになり、ユーザが持っているであろうリンクプロセスを再開します。
  3. アクセストークンが有効であれば、リターンおよびHTTPS応答の本文に以下のJSONオブジェクトとHTTP 200応答:

    {
    "sub": "USER_UUID",
    "email": "EMAIL_ADDRESS",
    "given_name": "FIRST_NAME",
    "family_name": "LAST_NAME",
    "name": "FULL_NAME",
    "picture": "PROFILE_PICTURE",
    }
    
    あなたのuserinfoエンドポイントがHTTP 200の成功応答を返した場合、トークン取得し、クレームはユーザーのGoogleに対して登録されていますアカウント。

    userinfoエンドポイント応答
    subシステム内のユーザーを識別する一意のID。
    emailユーザーのメールアドレス。
    given_nameオプション:ユーザーのファーストネーム。
    family_nameオプション:ユーザーの姓。
    nameオプション:ユーザーのフルネーム。
    pictureオプション:ユーザーのプロフィール画像。

実装の検証

あなたは使用して実装を検証することができOAuth 2.0の遊び場のツールを。

ツールで、次の手順を実行します。

  1. 設定をクリックし OAuth 2.0の設定]ウィンドウを開きます。
  2. OAuthの流れ場では、クライアント側を選択します。
  3. OAuthのエンドポイント]フィールドで、[カスタム]を選択します。
  4. OAuth2.0エンドポイントとGoogleに割り当てたクライアントIDを対応するフィールドに指定します。
  5. ステップ1セクションでは、すべてのGoogleサービスのスコープを選択しないでください。代わりに、このフィールドを空白のままにするか、サーバーに有効なスコープ(または、OAuthスコープを使用しない場合は任意の文字列)を入力してください。設定が完了したら、承認のAPIをクリックします。
  6. ステップ2ステップ3のセクションでは、OAuth 2.0のフローを通過し、意図したように各ステップが動作することを確認。

あなたは使用して実装を検証することができ、Googleアカウントのリンクデモツールを。

ツールで、次の手順を実行します。

  1. Googleのボタンでサインインしをクリックしてください。
  2. リンクするアカウントを選択してください。
  3. サービスIDを入力します。
  4. オプションで、アクセスを要求する1つ以上のスコープを入力します。
  5. スタートデモをクリックしてください。
  6. プロンプトが表示されたら、リンク要求に同意して拒否できることを確認します。
  7. プラットフォームにリダイレクトされていることを確認します。