OpenID Connect

Google の OAuth 2.0 API は、認証と承認の両方で使用できます。このドキュメントでは、認証用の OAuth 2.0 実装について説明します。この実装は OpenID Connect 仕様に準拠しており、OpenID Certified を受けています。OAuth 2.0 を使用して Google API にアクセスするに記載されているドキュメントは、このサービスにも適用されます。このプロトコルをインタラクティブに試すには、Google OAuth 2.0 Playground をおすすめします。Stack Overflow でサポートを受けるには、質問に「google-oauth」タグを付けます。

OAuth 2.0 の設定

アプリケーションでユーザー ログインに Google の OAuth 2.0 認証システムを使用するには、まず でプロジェクトを設定して、OAuth 2.0 認証情報を取得し、リダイレクト URI を設定する必要があります。また、必要に応じて、ユーザーがユーザー同意画面で確認するブランディング情報をカスタマイズすることもできます。 を使用して、サービス アカウントの作成、課金の有効化、フィルタリングの設定などのタスクを行うこともできます。詳しくは、 ヘルプをご覧ください。

OAuth 2.0 認証情報を取得する

ユーザーを認証して Google の API にアクセスするには、クライアント ID やクライアント シークレットなどの OAuth 2.0 認証情報が必要です。

特定のOAuth 2.0認証情報のクライアントIDとクライアントシークレットを表示するには、次のテキストをクリックします 。 認証情報を選択 。開いたウィンドウで、プロジェクトと必要な認証情報を選択し、[ 表示 ]をクリックします 。

または、 API Console [ 認証情報]ページからクライアントIDとクライアントシークレットを表示しAPI Console 。

1. Go to the Credentials page.
2. 資格情報の名前または鉛筆（ create ）アイコンをクリックします。クライアントIDとシークレットはページの上部にあります。

リダイレクト URI を設定する

で設定したリダイレクト URI によって、Google が認証リクエストに対するレスポンスを送信する場所が決まります。

特定のOAuth 2.0認証情報のリダイレクトURIを作成、表示、または編集するには、次の手順を実行します。

1. Go to the Credentials page.
2. ページのOAuth 2.0クライアントIDセクションで、認証情報をクリックします。
3. リダイレクトURIを表示または編集します。

[認証情報]ページにOAuth 2.0クライアントIDセクションがない場合、プロジェクトにはOAuth認証情報がありません。 アカウントを作成するには、[ 認証情報を作成]をクリックします 。

ユーザーの同意画面をカスタマイズする

ユーザーにとって、OAuth 2.0 認証エクスペリエンスには、ユーザーがリリースする情報と適用される規約を説明する同意画面が含まれます。たとえば、ユーザーがログインする際に、メールアドレスや基本アカウント情報へのアクセスをアプリに許可するよう求められることがあります。この情報へのアクセスは、アプリが認証リクエストに含める scope パラメータを使用してリクエストします。スコープを使用して、他の Google API へのアクセスをリクエストすることもできます。

ユーザーの同意画面には、プロダクト名、ロゴ、ホームページの URL などのブランディング情報も表示されます。 でブランディング情報を管理します。

プロジェクトの同意画面を有効にするには：

1. Consent Screen pageでGoogle API Consoleます。
2. If prompted, select a project, or create a new one.
3. フォームに入力して[ 保存 ]をクリックします 。

次の同意ダイアログは、OAuth 2.0 と Google ドライブのスコープの組み合わせがリクエストに含まれている場合にユーザーに表示される内容を示しています。（この汎用ダイアログは Google OAuth 2.0 Playground を使用して生成されたため、 で設定されるブランド情報が含まれていません）。

サービスへのアクセス

Google とサードパーティは、ユーザーの認証と Google APIs へのアクセス権の取得に関する実装の詳細の多くを処理するために使用できるライブラリを提供しています。たとえば、Google Identity Services や、さまざまなプラットフォームで利用可能な Google クライアント ライブラリなどがあります。

ライブラリを使用しない場合は、このドキュメントの残りの部分の手順に沿って操作してください。このドキュメントでは、使用可能なライブラリの基盤となる HTTP リクエスト フローについて説明します。

ユーザーの認証

ユーザーの認証には、ID トークンの取得と検証が含まれます。ID トークンは、インターネット上で ID アサーションを共有するために設計された OpenID Connect の標準化された機能です。

ユーザーを認証して ID トークンを取得する最も一般的な方法は、「サーバー」フローと「暗黙的」フローと呼ばれます。サーバーフローを使用すると、アプリケーションのバックエンド サーバーは、ブラウザまたはモバイル デバイスを使用しているユーザーの ID を検証できます。暗黙的なフローは、クライアントサイド アプリケーション（通常はブラウザで実行される JavaScript アプリ）がバックエンド サーバーを使用する代わりに API に直接アクセスする必要がある場合に使用されます。

このドキュメントでは、ユーザーを認証するためのサーバーフローを実行する方法について説明します。暗黙的フローは、クライアントサイドでのトークンの処理と使用におけるセキュリティ リスクがあるため、はるかに複雑になります。暗黙的なフローを実装する必要がある場合は、Google Identity Services を使用することを強くおすすめします。

サーバーフロー

これらのプロトコルを使用してユーザーを認証できるように、 でアプリをセットアップしてください。ユーザーが Google でログインしようとした場合は、次の処理を行う必要があります。

1. 偽造防止状態トークンを作成する
2. Google に認証リクエストを送信する
3. 偽造防止状態トークンを確認する
4. code をアクセス トークンと ID トークンと交換する
5. ID トークンからユーザー情報を取得する
6. ユーザーを認証する

1. 偽造防止状態トークンを作成する

リクエスト偽造攻撃を防ぎ、ユーザーのセキュリティを保護する必要があります。最初の手順は、アプリとユーザーのクライアント間の状態を保持する一意のセッション トークンを作成することです。この一意のセッション トークンは、後で Google OAuth ログイン サービスから返される認証レスポンスと照合され、リクエストを行っているのがユーザーであり、悪意のある攻撃者ではないことを確認します。これらのトークンは、クロスサイト リクエスト フォージェリ（CSRF）トークンと呼ばれることがよくあります。

状態トークンとして適しているのは、高品質の乱数ジェネレータを使用して作成された 30 文字程度の文字列です。もう 1 つは、バックエンドで秘密に保持されている鍵を使用して、セッション状態変数の一部に署名することで生成されるハッシュです。

次のコードは、一意のセッション トークンを生成する方法を示しています。

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
$state = bin2hex(random_bytes(128/8));
$app['session']->set('state', $state);
// Set the client ID, token state, and application name in the HTML while
// serving it.
return $app['twig']->render('index.html', array(
    'CLIENT_ID' => CLIENT_ID,
    'STATE' => $state,
    'APPLICATION_NAME' => APPLICATION_NAME
));

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
String state = new BigInteger(130, new SecureRandom()).toString(32);
request.session().attribute("state", state);
// Read index.html into memory, and set the client ID,
// token state, and application name in the HTML before serving it.
return new Scanner(new File("index.html"), "UTF-8")
    .useDelimiter("\\A").next()
    .replaceAll("[{]{2}\\s*CLIENT_ID\\s*[}]{2}", CLIENT_ID)
    .replaceAll("[{]{2}\\s*STATE\\s*[}]{2}", state)
    .replaceAll("[{]{2}\\s*APPLICATION_NAME\\s*[}]{2}",
    APPLICATION_NAME);

# Create a state token to prevent request forgery.
# Store it in the session for later validation.
state = hashlib.sha256(os.urandom(1024)).hexdigest()
session['state'] = state
# Set the client ID, token state, and application name in the HTML while
# serving it.
response = make_response(
    render_template('index.html',
                    CLIENT_ID=CLIENT_ID,
                    STATE=state,
                    APPLICATION_NAME=APPLICATION_NAME))

2. Google に認証リクエストを送信する

次のステップでは、適切な URI パラメータを使用して HTTPS GET リクエストを作成します。このプロセスのすべての手順で HTTP ではなく HTTPS が使用されていることに注意してください。HTTP 接続は拒否されます。authorization_endpoint メタデータ値を使用して、ディスカバリ ドキュメントからベース URI を取得する必要があります。以下の説明では、ベース URI が https://accounts.google.com/o/oauth2/v2/auth であることを前提としています。

基本的なリクエストの場合は、次のパラメータを指定します。

• client_id。これは から取得します。
• response_type。基本的な認証コードフロー リクエストでは code になります。（詳しくは、response_type をご覧ください）。
• scope。基本的なリクエストでは openid email にする必要があります。（詳しくは、scope をご覧ください）。
• redirect_uri は、Google からのレスポンスを受信するサーバー上の HTTP エンドポイントにする必要があります。この値は、 Credentials pageで構成した OAuth 2.0 クライアントの承認済みリダイレクト URI のいずれかと完全に一致する必要があります。この値が承認済み URI と一致しない場合、リクエストは redirect_uri_mismatch エラーで失敗します。
• state には、不正防止の一意のセッション トークンの値と、ユーザーがアプリケーションに戻ったときにコンテキストを復元するために必要なその他の情報（開始 URL など）を含める必要があります。（詳しくは、state をご覧ください）。
• nonce は、アプリによって生成されるランダムな値です。この値が存在する場合、リプレイ保護が有効になります。
• login_hint には、ユーザーのメールアドレスまたは sub 文字列（ユーザーの Google ID に相当）を指定できます。login_hint を指定せず、ユーザーがログインしている場合、同意画面には、ユーザーのメールアドレスをアプリにリリースするための承認を求めるリクエストが含まれます。（詳しくは、login_hint をご覧ください）。
• hd パラメータを使用して、Google Workspace または Cloud 組織に関連付けられた特定のドメインのユーザー向けに OpenID Connect フローを最適化します（詳細については、hd をご覧ください）。

読みやすくするために改行とスペースを入れた OpenID Connect 認証 URI の例を次に示します。

https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=424911365001.apps.googleusercontent.com&
 scope=openid%20email&
 redirect_uri=https%3A//oauth2.example.com/code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttps%2Foauth2-login-demo.example.com%2FmyHome&
 login_hint=[email protected]&
 nonce=0394852-3190485-2490358&
 hd=example.com

アプリがユーザーに関する新しい情報をリクエストする場合、またはユーザーが以前に承認していないアカウント アクセスをアプリがリクエストする場合は、ユーザーの同意が必要です。

3. 偽造防止状態トークンを確認する

レスポンスは、リクエストで指定した redirect_uri に送信されます。すべてのレスポンスはクエリ文字列で返されます。

https://oauth2.example.com/code?state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttps%2Foa2cb.example.com%2FmyHome&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&scope=openid%20email%20https://www.googleapis.com/auth/userinfo.email

サーバーで、Google から受け取った state が、ステップ 1 で作成したセッション トークンと一致することを確認する必要があります。このラウンドトリップ検証は、悪意のあるスクリプトではなくユーザーがリクエストを行っていることを確認するのに役立ちます。

次のコードは、手順 1 で作成したセッション トークンを確認する方法を示しています。

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if ($request->get('state') != ($app['session']->get('state'))) {
  return new Response('Invalid state parameter', 401);
}

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if (!request.queryParams("state").equals(
    request.session().attribute("state"))) {
  response.status(401);
  return GSON.toJson("Invalid state parameter.");
}

# Ensure that the request is not a forgery and that the user sending
# this connect request is the expected user.
if request.args.get('state', '') != session['state']:
  response = make_response(json.dumps('Invalid state parameter.'), 401)
  response.headers['Content-Type'] = 'application/json'
  return response

4. code をアクセス トークンと ID トークンと交換する

レスポンスには、code パラメータ（サーバーがアクセス トークンと ID トークンに交換できる 1 回限りの認証コード）が含まれます。サーバーは HTTPS POST リクエストを送信することで、この交換を行います。POST リクエストはトークン エンドポイントに送信されます。トークン エンドポイントは、token_endpoint メタデータ値を使用してディスカバリ ドキュメントから取得する必要があります。以下の説明では、エンドポイントが https://oauth2.googleapis.com/token であることを前提としています。リクエストには、POST 本文に次のパラメータを含める必要があります。

実際のリクエストは次のようになります。

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

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your-client-id&
client_secret=your-client-secret&
redirect_uri=https%3A//oauth2.example.com/code&
grant_type=authorization_code

このリクエストに対する成功レスポンスには、JSON 配列に次のフィールドが含まれます。

5. ID トークンからユーザー情報を取得する

ID トークンは JWT（JSON ウェブトークン）です。つまり、暗号で署名された Base64 エンコードの JSON オブジェクトです。通常、ID トークンを使用する前に検証することが重要ですが、仲介のない HTTPS チャネルを介して Google と直接通信し、クライアント シークレットを使用して Google に対して認証を行っているため、受け取ったトークンが実際に Google からのものであり、有効であることを確認できます。サーバーがアプリの他のコンポーネントに ID トークンを渡す場合は、他のコンポーネントがトークンを使用する前にトークンを検証することが非常に重要です。

ほとんどの API ライブラリは、検証と base64url でエンコードされた値のデコードおよび JSON の解析を組み合わせているため、ID トークンのクレームにアクセスする際にトークンを検証することになるでしょう。

ID トークンのペイロード

ID トークンは、名前と値のペアのセットを含む JSON オブジェクトです。読みやすくするために書式設定された例を次に示します。

{
  "iss": "https://accounts.google.com",
  "azp": "1234987819200.apps.googleusercontent.com",
  "aud": "1234987819200.apps.googleusercontent.com",
  "sub": "10769150350006150715113082367",
  "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q",
  "hd": "example.com",
  "email": "[email protected]",
  "email_verified": "true",
  "iat": 1353601026,
  "exp": 1353604926,
  "nonce": "0394852-3190485-2490358"
}

Google ID トークンには次のフィールド（クレームと呼ばれる）が含まれる場合があります。

6. お客様の認証

ID トークンからユーザー情報を取得したら、アプリのユーザー データベースをクエリする必要があります。ユーザーがすでにデータベースに存在する場合は、Google API レスポンスがすべてのログイン要件を満たしている場合に、そのユーザーのアプリケーション セッションを開始する必要があります。

ユーザーがユーザー データベースに存在しない場合は、ユーザーを新規ユーザー登録フローにリダイレクトする必要があります。Google から受け取った情報に基づいてユーザーを自動登録できる場合もあれば、少なくとも登録フォームで必要なフィールドの多くに事前入力できる場合もあります。ID トークン内の情報に加えて、ユーザー プロファイル エンドポイントで追加のユーザー プロファイル情報を取得できます。

高度なトピック

以降のセクションでは、Google OAuth 2.0 API について詳しく説明します。この情報は、認証と認可に関する高度な要件を持つデベロッパーを対象としています。

他の Google API へのアクセス

認証に OAuth 2.0 を使用するメリットの 1 つは、ユーザーの認証と同時に、ユーザーに代わって他の Google API（YouTube、Google ドライブ、カレンダー、連絡先など）を使用する権限をアプリケーションが取得できることです。これを行うには、Google に送信する認証リクエストに必要な他のスコープを含めます。たとえば、認証リクエストにユーザーの年齢層を追加するには、openid email https://www.googleapis.com/auth/profile.agerange.read のスコープ パラメータを渡します。同意画面でユーザーに適切なメッセージが表示されます。Google から返されるアクセス トークンを使用すると、リクエストして付与されたアクセス スコープに関連するすべての API にアクセスできます。

更新トークン

API アクセスのリクエストで、code 交換時に更新トークンが返されるようにリクエストできます。更新トークンを使用すると、ユーザーがアプリにいない間も、アプリは Google API に継続的にアクセスできます。更新トークンをリクエストするには、認証リクエストで access_type パラメータを offline に設定します。

考慮事項:

• 更新トークンは、コード交換フローを初めて実行したときにのみ取得できるため、安全かつ永続的に保存してください。
• 発行される更新トークンの数には上限があります。クライアントとユーザーの組み合わせごとに 1 つの上限と、すべてのクライアントのユーザーごとに 1 つの上限があります。アプリケーションが過剰な数の更新トークンをリクエストすると、これらの上限に達する可能性があります。その場合、古い更新トークンは機能しなくなります。

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

再同意を求めるメッセージを表示する

認証リクエストで prompt パラメータを consent に設定すると、ユーザーにアプリの再認証を求めることができます。prompt=consent が含まれている場合、すべてのスコープが以前に Google APIs プロジェクトに付与されている場合でも、アプリがアクセスのスコープの承認をリクエストするたびに同意画面が表示されます。そのため、prompt=consent は必要な場合にのみ含めてください。

prompt パラメータの詳細については、認証 URI パラメータの表の prompt をご覧ください。

認証 URI パラメータ

次の表に、Google の OAuth 2.0 認証 API で受け入れられるパラメータの詳細な説明を示します。

ID トークンを検証する

ID トークンが Google から直接送信されたことがわかっている場合を除き、サーバー上のすべての ID トークンを検証する必要があります。たとえば、サーバーはクライアント アプリから受け取った ID トークンが本物であることを確認する必要があります。

サーバーに ID トークンを送信する一般的な状況は次のとおりです。

• 認証が必要なリクエストとともに ID トークンを送信します。ID トークンは、リクエストを行っている特定のユーザーと、その ID トークンが付与されたクライアントを示します。

ID トークンは機密情報であり、傍受されると悪用される可能性があります。これらのトークンは、HTTPS 経由でのみ送信し、POST データまたはリクエスト ヘッダー内でのみ使用することで、安全に処理する必要があります。ID トークンをサーバーに保存する場合は、安全に保存する必要があります。

ID トークンが便利な理由の一つは、アプリのさまざまなコンポーネント間で受け渡しできることです。これらのコンポーネントは、アプリとユーザーを認証する軽量な認証メカニズムとして ID トークンを使用できます。ただし、ID トークンの情報を使用したり、ユーザーが認証されたというアサーションとして信頼したりする前に、ID トークンを検証する必要があります。

ID トークンの検証には、いくつかの手順が必要です。

1. ID トークンが発行者によって適切に署名されていることを確認します。Google が発行したトークンは、ディスカバリ ドキュメントの jwks_uri メタデータ値で指定された URI にある証明書のいずれかを使用して署名されます。
2. ID トークンの iss クレームの値が https://accounts.google.com または accounts.google.com と等しいことを確認します。
3. ID トークンの aud クレームの値がアプリのクライアント ID と等しいことを確認します。
4. ID トークンの有効期限（exp クレーム）が切れていないことを確認します。
5. リクエストで hd パラメータの値を指定した場合は、ID トークンに、Google Cloud 組織に関連付けられている承認済みドメインと一致する hd クレームが含まれていることを確認します。

ステップ 2 ～ 5 では、文字列と日付の比較のみが行われます。これは非常に単純なため、ここでは詳しく説明しません。

最初のステップはより複雑で、暗号署名のチェックが含まれます。デバッグの目的で、Google の tokeninfo エンドポイントを使用して、サーバーまたはデバイスに実装されたローカル処理と比較できます。ID トークンの値が XYZ123 であるとします。次に、URI https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123 の参照を解除します。トークン署名が有効な場合、レスポンスはデコードされた JSON オブジェクト形式の JWT ペイロードになります。

tokeninfo エンドポイントはデバッグに便利ですが、本番環境では、鍵エンドポイントから Google の公開鍵を取得し、ローカルで検証を行います。jwks_uri メタデータ値を使用して、ディスカバリ ドキュメントから鍵 URI を取得する必要があります。デバッグ エンドポイントへのリクエストは、スロットリングされるか、断続的なエラーが発生する可能性があります。

Google が公開鍵を変更することはめったにないため、HTTP レスポンスのキャッシュ ディレクティブを使用して公開鍵をキャッシュに保存できます。ほとんどの場合、tokeninfo エンドポイントを使用するよりもローカル検証をはるかに効率的に実行できます。この検証では、証明書を取得して解析し、適切な暗号呼び出しを行って署名を確認する必要があります。幸いなことに、この処理を行うために、さまざまな言語で十分にデバッグされたライブラリが用意されています（jwt.io を参照）。

ユーザー プロフィール情報の取得

ユーザーに関する追加のプロファイル情報を入手するには、アクセス トークン（アプリケーションが認証フローで受け取る）と OpenID Connect 標準を使用することができます。

1. OpenID に準拠するには、認証リクエストに openid profile スコープ値を含める必要があります。

   ユーザーのメールアドレスを含めたい場合は、追加のスコープ値 email を指定できます。profile と email の両方を指定したい場合は、以下のパラメータを認証リクエスト URI に含めることができます。

   scope=openid%20profile%20email

2. アクセス トークンを承認ヘッダーに追加し、HTTPS GET リクエストをユーザー情報エンドポイントに行います。ユーザー情報エンドポイントは、userinfo_endpoint メタデータ値を使用してディスカバリ ドキュメントから取得する必要があります。ユーザー情報のレスポンスには、OpenID Connect Standard Claims とディスカバリ ドキュメントの claims_supported メタデータ値に記述されているとおり、ユーザーに関する情報が含まれます。ユーザーまたはユーザーの組織は、特定の項目に情報を提供したり、しなかったりするため、パートナー様がアクセスを許可されているスコープのすべての項目に対する情報を得られるとは限りません。

ディスカバリ ドキュメント

OpenID Connect プロトコルでは、ユーザーの認証と、トークン、ユーザー情報、公開鍵などのリソースのリクエストに複数のエンドポイントを使用する必要があります。

実装を簡素化し、柔軟性を高めるため、OpenID Connect では「ディスカバリ ドキュメント」の使用が認められています。これは、既知の場所にある JSON ドキュメントで、OpenID Connect プロバイダの構成に関する詳細情報（認可、トークン、取り消し、ユーザー情報、公開鍵のエンドポイントの URI など）を提供するキーと値のペアが含まれています。Google の OpenID Connect サービスのディスカバリ ドキュメントは、次の場所から取得できます。

https://accounts.google.com/.well-known/openid-configuration

Google の OpenID Connect サービスを使用するには、ディスカバリ ドキュメント URI（https://accounts.google.com/.well-known/openid-configuration）をアプリケーションにハードコードする必要があります。アプリケーションはドキュメントを取得し、レスポンスでキャッシュ保存ルールを適用して、必要に応じてエンドポイント URI を取得します。たとえば、ユーザーを認証する場合、コードは authorization_endpoint メタデータ値（下の例では https://accounts.google.com/o/oauth2/v2/auth）を、Google に送信される認証リクエストのベース URI として取得します。

このようなドキュメントの例を次に示します。フィールド名は OpenID Connect Discovery 1.0 で指定されたものです（意味については、そのドキュメントを参照してください）。値は単なる例であり、変更される可能性があります。ただし、実際の Google ディスカバリ ドキュメントの最新バージョンからコピーされています。

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "code token",
    "code id_token",
    "token id_token",
    "code token id_token",
    "none"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "claims_supported": [
    "aud",
    "email",
    "email_verified",
    "exp",
    "family_name",
    "given_name",
    "iat",
    "iss",
    "locale",
    "name",
    "picture",
    "sub"
  ],
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ]
}

ディスカバリ ドキュメントの値をキャッシュに保存することで、HTTP ラウンド トリップを回避できる場合があります。標準の HTTP キャッシュ保存ヘッダーが使用され、尊重される必要があります。

クライアント ライブラリ

次のクライアント ライブラリは、一般的なフレームワークと統合することで、OAuth 2.0 の実装を簡素化します。

• Java 用の Google API クライアント ライブラリ
• Python 用の Google API クライアント ライブラリ
• .NET 用 Google API クライアント ライブラリ
• Ruby 用 Google API クライアント ライブラリ
• PHP 用 Google API クライアント ライブラリ
• Google Web Toolkit 用 OAuth 2.0 ライブラリ
• Google Toolbox for Mac OAuth 2.0 コントローラ

OpenID Connect 準拠

Google の OAuth 2.0 認証システムは、OpenID Connect Core 仕様の必須機能をサポートしています。OpenID Connect で動作するように設計されたクライアントは、このサービスと相互運用する必要があります（OpenID リクエスト オブジェクトを除く）。