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 認証システムを使用するには、 Google API Console でプロジェクトを設定して、OAuth 2.0 の認証情報を取得し、リダイレクト URI を設定して（必要に応じて）、ユーザーの同意画面でユーザーに表示されるブランディング情報をカスタマイズする必要があります。 API Console を使用して、サービス アカウントの作成、課金の有効化、フィルタの設定などのタスクを実行することもできます。詳細については、Google API Consoleヘルプをご覧ください。

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 を設定する

API Console で設定したリダイレクト 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 などのブランディング情報も表示されます。ブランド情報は API Consoleで管理します。

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

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 を使用して生成されたため、 API Consoleに設定されるブランディング情報は含まれません）。

サービスへのアクセス

Google とサードパーティには、ユーザーの認証や Google API へのアクセス権の取得に関する実装の詳細の処理に利用できるライブラリが用意されています。たとえば、Google Identity Services や Google クライアント ライブラリなど、さまざまなプラットフォームで利用できます。

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

ユーザーの認証

ユーザーの認証には、ID トークンの取得と検証が必要です。ID トークンは、OpenID Connect の標準化された機能であり、インターネットでの ID アサーションの共有を目的として設計されています。

ユーザーの認証と ID トークンの取得に最もよく使用されるアプローチは、「サーバー」フローと「暗黙的」フローです。このサーバーフローでは、アプリケーションのバックエンド サーバーが、ブラウザまたはモバイル デバイスを使用して個人の ID を確認できます。暗黙的フローは、クライアント側アプリケーション（通常はブラウザで実行される JavaScript アプリ）がバックエンド サーバーを経由せずに API に直接アクセスする必要がある場合に使用されます。

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

サーバーフロー

これらのプロトコルを使用してユーザーを認証できるように、 API Consoleでアプリを設定してください。ユーザーが 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。これは、 API ConsoleCredentials pageから取得します。
• response_type。基本認証コードフローのリクエストでは、code にする必要があります。（詳しくは response_type をご覧ください）。
• scope。基本リクエストでは openid email にする必要があります。（詳しくは scope をご覧ください）。
• redirect_uri は、Google からのレスポンスを受信する、サーバーの HTTP エンドポイントです。この値は、 API ConsoleCredentials pageで構成した OAuth 2.0 クライアントの承認済みのリダイレクト URI のいずれかと完全に一致する必要があります。この値が承認済みの URI と一致しない場合、リクエストは redirect_uri_mismatch エラーで失敗します。
• state には、偽造防止を行わない一意のセッション トークンの値と、ユーザーがアプリケーションに戻ったときにコンテキストの復元に必要なその他の情報（開始 URL など）を含めます。 （詳しくは state をご覧ください）。
• nonce は、アプリによって生成されたランダムな値です。存在する場合、リプレイ保護を有効にします。
• login_hint には、ユーザーのメールアドレスまたは sub 文字列（ユーザーの Google ID と同等）を指定できます。login_hint を指定しておらず、ユーザーが現在ログインしている場合、同意画面にはユーザーのメールアドレスをアプリにリリースするための承認リクエストが表示されます（詳しくは、login_hint をご覧ください）。
• hd パラメータを使用して、Google 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%2Foauth2-login-demo.example.com%2FmyHome&
 login_hint=jsmith@example.com&
 nonce=0394852-3190485-2490358&
 hd=example.com

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

3.偽造防止状態トークンの確認

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

https://oauth2.example.com/code?state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%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 Web Token）です。つまり、暗号的に署名された 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": "jsmith@example.com",
  "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 を使用するメリットの一つは、ユーザーの認証と同時に、アプリケーションが他の 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 API プロジェクトにすべてのスコープが付与されている場合でも、アプリがアクセス スコープの承認をリクエストするたびに同意画面が表示されます。このため、必要な場合にのみ prompt=consent を含めます。

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

認証 URI パラメータ

次の表に、Google の OAuth 2.0 認証 API で利用できるパラメータの詳細を示します。

ID トークンの検証

Google から直接取得した ID トークンでない限り、サーバー上のすべての ID トークンを検証する必要があります。たとえば、サーバーは、クライアント アプリから受信するすべての ID トークンを検証する必要があります。

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

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

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

ID トークンが役に立つ理由の 1 つは、アプリのさまざまなコンポーネントに ID トークンを渡せることです。これらのコンポーネントは、アプリとユーザーを認証するための軽量な認証メカニズムとして ID トークンを使用できます。ただし、ID トークン内の情報を使用したり、ユーザーの認証に関するアサーションを使用したりする前に、情報を認証する必要があります。

ID トークンを検証するには、いくつかのステップが必要です。

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

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

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

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

OpenID Connect を使用すると、実装を簡素化し、柔軟性を向上させることができます。「ディスカバリ ドキュメント」を使用できます。これは、認証、トークン、取り消し、userinfo、公開鍵のエンドポイントなど、OpenID Connect プロバイダの構成に関する詳細を提供する既知の場所にある JSON ドキュメントです。Google の OpenID Connect サービスのディスカバリ ドキュメントは、次の場所から取得できます。

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

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

以下にドキュメントの例を示します。フィールド名は OpenID Connect Discovery 1.0 で指定されているものです（意味についてはドキュメントをご覧ください）。 値は単に説明のためのものであり、変更される可能性があります。実際の値は、実際の Google Discovery ドキュメントの最新バージョンからコピーしたものです。

{
  "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 ライブラリ
• Mac OAuth 2.0 コントローラ用 Google ツールボックス

OpenID Connect コンプライアンス

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