Google の OAuth 2.0 API は、認証と認可の両方に使用できます。このドキュメントでは、OpenID Connect 仕様に準拠し、OpenID Certified として認証を行う OAuth 2.0 実装について説明します。このサービスには、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 認証情報が必要です。
To view the client ID and client secret for a given OAuth 2.0 credential, click the following text: Select credential. In the window that opens, choose your project and the credential you want, then click View.
Or, view your client ID and client secret from the Credentials page in API Console:
- Go to the Credentials page.
- Click the name of your credential or the pencil (create) icon. Your client ID and secret are at the top of the page.
リダイレクト URI を設定する
API Console で設定したリダイレクト URI によって、Google が認証リクエストに応答する場所が決まります。
特定のOAuth 2.0認証情報のリダイレクトURIを作成、表示、または編集するには、次の手順を実行します。
- Go to the Credentials page.
- ページのOAuth 2.0クライアントIDセクションで、認証情報をクリックします。
- リダイレクトURIを表示または編集します。
[認証情報]ページにOAuth 2.0クライアントIDセクションがない場合、プロジェクトにはOAuth認証情報がありません。 アカウントを作成するには、[ 認証情報を作成]をクリックします 。
ユーザーの同意画面をカスタマイズする
ユーザー向けに、OAuth 2.0 認証エクスペリエンスには、ユーザーがリリースする情報と適用される規約を説明する同意画面が含まれています。たとえば、ユーザーがログインすると、アプリにメールアドレスと基本的なアカウント情報へのアクセスを許可するように求められる場合があります。この情報へのアクセス権をリクエストするには、scope パラメータを使用します。このパラメータは、アプリの認証リクエストに含まれます。スコープを使用して、他の Google API へのアクセスをリクエストすることもできます。
ユーザーの同意画面には、商品名、ロゴ、ホームページの URL などのブランディング情報も表示されます。ブランディング情報は API Consoleで管理します。
プロジェクトの同意画面を有効にするには：
- Consent Screen pageでGoogle API Consoleます。
- If prompted, select a project, or create a new one.
- フォームに入力して[ 保存 ]をクリックします 。
次の同意ダイアログは、リクエストに 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 トークンの取得でよく使用される方法は、「サーバー」フローと「暗黙的」フローです。サーバー フローでは、アプリケーションのバックエンド サーバーでブラウザまたはモバイル デバイスを使用して、ユーザーの本人確認を行うことができます。暗黙的フローは、クライアントサイド アプリケーション（通常はブラウザで実行される JavaScript アプリ）がバックエンド サーバーではなく API に直接アクセスする必要がある場合に使用されます。
このドキュメントでは、ユーザーを認証するためのサーバーフローを実行する方法について説明します。暗黙的フローは、クライアント側でトークンを処理して使用する場合のセキュリティ リスクのため、かなり複雑になります。暗黙的フローを実装する必要がある場合は、Google Identity Services を使用することを強くおすすめします。
サーバーフロー
API Consoleでアプリを設定して、これらのプロトコルを使用し、ユーザーを認証できるようにしてください。ユーザーが Google でログインしようとする際に、管理者は次のことを行う必要があります。
- 偽造防止状態トークンを作成する
- Google に認証リクエストを送信する
- 偽造防止状態トークンを確認する
codeをアクセス トークンおよび ID トークンと交換する- ID トークンからユーザー情報を取得する
- ユーザーを認証する
1. 偽造防止状態トークンを作成する
リクエスト フォージェリ攻撃を防ぐことで、ユーザーのセキュリティを保護する必要があります。まず、アプリとユーザーのクライアントとの間の状態を保持する一意のセッション トークンを作成します。この一意のセッション トークンを後で Google OAuth ログイン サービスから返された認証レスポンスと照合し、悪意のあるリクエストではなく、ユーザーがリクエストを送信していることを確認します。これらのトークンは多くの場合、クロスサイト リクエスト フォージェリ（CSRF）トークンと呼ばれます。
状態トークンの選択肢としては、30 個ほどの文字列と、高品質の乱数ジェネレータを使用して構築した文字列が適しています。もう一つは、バックエンドでシークレットを保持するキーでセッション状態変数の一部に署名することで生成されるハッシュです。
次のコードは、一意のセッション トークンを生成する方法を示しています。
PHP
このサンプルを使用するには、PHP 用の Google API クライアント ライブラリをダウンロードする必要があります。
// 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
));
Java
このサンプルを使用するには、Java 用の Google API クライアント ライブラリをダウンロードする必要があります。
// 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);
Python
このサンプルを使用するには、Python 用 Google API クライアント ライブラリをダウンロードする必要があります。
# 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 Console Credentials pageから取得します。response_type。基本認証コードフロー リクエストでは、codeにする必要があります。（詳しくはresponse_typeをご覧ください）。scope。基本的なリクエストではopenid emailにする必要があります。（詳しくは、scopeをご覧ください）。redirect_uriは、Google からのレスポンスを受信するサーバーの HTTP エンドポイントにする必要があります。この値は、 Credentials pageで構成した OAuth 2.0 クライアントの承認済みリダイレクト URI のいずれかと完全に一致する必要があります。 API Consoleこの値が承認済み 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 で作成したセッション トークンを確認する方法を示しています。
PHP
このサンプルを使用するには、PHP 用の Google API クライアント ライブラリをダウンロードする必要があります。
// 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);
}
Java
このサンプルを使用するには、Java 用の Google API クライアント ライブラリをダウンロードする必要があります。
// 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.");
}
Python
このサンプルを使用するには、Python 用 Google API クライアント ライブラリをダウンロードする必要があります。
# 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 本文には、次のパラメータを含める必要があります。
| フィールド | |
|---|---|
code |
最初のリクエストから返される認証コード。 |
client_id |
API Console Credentials pageから取得したクライアント ID。OAuth 2.0 認証情報を取得するをご覧ください。 |
client_secret |
API Console Credentials pageから取得したクライアント シークレット。OAuth 2.0 認証情報を取得するをご覧ください。 |
redirect_uri |
リダイレクト URI を設定するで説明しているように、 API Console
Credentials pageで指定された特定の client_id の承認済みリダイレクト URI。 |
grant_type |
このフィールドには、
OAuth 2.0 仕様で定義されている、authorization_code の値が含まれている必要があります。 |
実際のリクエストは次の例のようになります。
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 配列に次のフィールドが含まれます。
| フィールド | |
|---|---|
access_token |
Google API に送信できるトークン。 |
expires_in |
アクセス トークンの残りの有効期間（秒）。 |
id_token |
Google によってデジタル署名されたユーザーの ID 情報を含む JWT。 |
scope |
access_token によって付与されるアクセス スコープ。スペース区切りの大文字と小文字が区別される文字列のリストとして表されます。 |
token_type |
返されたトークンのタイプを示します。この時点では、このフィールドは常に値 Bearer です。 |
refresh_token |
（省略可）
このフィールドは、認証リクエストで |
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 トークンには、次のフィールド（クレーム）が含まれる場合があります。
| 申し立て | 指定のクレジット カード | 説明 |
|---|---|---|
aud |
常に | この ID トークンの対象オーディエンス。アプリケーションの OAuth 2.0 クライアント ID のいずれかにする必要があります。 |
exp |
常に | 有効期限は、この日付以降は ID トークンを受け入れられません。Unix 時間（整数秒）で表されます。 |
iat |
常に | ID トークンが発行された時刻。Unix 時間（整数秒）で表されます。 |
iss |
常に | レスポンスの発行者 ID。Google ID トークンの場合は、常に https://accounts.google.com または accounts.google.com です。 |
sub |
常に | ユーザー ID。すべての Google アカウントの中で一意であり、再利用されることはありません。Google アカウントには、それぞれ異なる時点で複数のメールアドレスを設定できますが、sub の値は変更されません。アプリケーション内で、ユーザーの一意の識別子キーとして sub を使用します。大文字と小文字を区別する 255 文字までの ASCII 文字。 |
at_hash |
アクセス トークンのハッシュ。アクセス トークンが ID トークンに関連付けられていることの確認を提供します。サーバーフローで access_token トークンを使用して ID トークンを発行する場合、このクレームが常に含まれます。このクレームは、クロスサイト リクエスト フォージェリ攻撃から保護するための代替メカニズムとして使用できますが、ステップ 1 とステップ 3 に従っている場合、アクセス トークンの検証は必要ありません。 |
|
azp |
承認されたプレゼンターの client_id。このクレームは、ID トークンをリクエストする当事者が ID トークンのオーディエンスと同じでない場合にのみ必要です。Google では、ウェブアプリと Android アプリの OAuth 2.0 が異なるclient_idが、同じ Google API プロジェクトを共有するハイブリッド アプリの場合がこれに該当します。 |
|
email |
ユーザーのメールアドレス。この値はこのユーザーに固有ではないため、主キーとしての使用には適していません。スコープに email スコープ値が含まれている場合にのみ提供されます。 |
|
email_verified |
ユーザーのメールアドレスが確認済みであれば true、そうでない場合は false です。 | |
family_name |
ユーザーの姓（ラストネーム）。name クレームが存在する場合は、提供される可能性があります。 |
|
given_name |
ユーザーの名（ファースト ネーム）。name クレームが存在する場合は、提供される可能性があります。 |
|
hd |
ユーザーの Google Cloud 組織に関連付けられているドメイン。ユーザーが Google Cloud 組織に属している場合にのみ提供されます。 | |
locale |
ユーザーの言語 / 地域。BCP 47 言語タグで表されます。
name クレームが存在する場合は、提供される可能性があります。 |
|
name |
ユーザーの氏名（表示可能な形式）。以下の場合、指定が行われることがあります。
|
|
nonce |
認証リクエストでアプリから提供された nonce の値。リプレイ攻撃は、1 回限り提示する必要があります。 |
|
picture |
ユーザーのプロフィール写真の URL。以下の場合、指定が行われることがあります。
|
|
profile |
ユーザーのプロフィール ページの URL。以下の場合、指定が行われることがあります。
|
6. ユーザーを認証する
ID トークンからユーザー情報を取得したら、アプリのユーザー データベースに対してクエリを実行します。データベース内にすでにユーザーが存在し、Google API のレスポンスですべてのログイン要件が満たされている場合は、そのユーザーのアプリケーション セッションを開始する必要があります。
ユーザーがユーザー データベースに存在しない場合は、ユーザーを新しいユーザー登録フローにリダイレクトする必要があります。Google から受け取った情報に基づいてユーザーを自動登録できる場合もあれば、少なくとも登録フォームに必要なフィールドの多くを事前入力できる場合もあります。ID トークンの情報に加えて、追加のユーザー プロフィール情報もユーザー プロフィール エンドポイントで取得できます。
高度なトピック
以下のセクションでは、Google OAuth 2.0 API について詳しく説明します。この情報は、認証と認可に関する高度な要件を持つデベロッパーを対象としています。
他の Google API へのアクセス
認証に OAuth 2.0 を使用するメリットの 1 つは、ユーザーの認証と同時に、アプリケーションが他の Google API（YouTube、Google ドライブ、カレンダー、コンタクトなど）を使用する権限を取得できることです。これを行うには、Google に送信する認証リクエストに必要な他のスコープを含めます。たとえば、ユーザーの年齢層を認証リクエストに追加するには、scope パラメータの openid email https://www.googleapis.com/auth/profile.agerange.read を渡します。同意画面に適切なプロンプトが表示される。Google から返されるアクセス トークンを使用して、リクエストしたアクセス スコープに関連するすべての API にアクセスできます。
更新トークン
API アクセスのリクエストでは、code の交換時に更新トークンを返すようにリクエストできます。更新トークンを使用すると、ユーザーがアプリケーション内にいないときに、アプリから Google API に継続的にアクセスできます。更新トークンをリクエストするには、認証リクエストで access_type パラメータを offline に設定します。
考慮事項:
- 更新トークンはコード交換フローの初回実行時にのみ取得できるため、更新トークンは安全かつ永続的に保存してください。
- 発行される更新トークンの数には上限があります。1 つのクライアントとユーザーの組み合わせごとに 1 つの上限、およびすべてのクライアントで 1 つの上限があります。アプリケーションが更新トークンの数が多すぎると、これらの制限に達し、古い更新トークンが動作しなくなる可能性があります。
詳細については、アクセス トークンの更新（オフライン アクセス）をご覧ください。
再同意を促す
認証リクエストで prompt パラメータを consent に設定すると、ユーザーにアプリを再承認するよう促すことができます。prompt=consent を含めると、すべてのスコープが以前に Google API プロジェクトに付与されていた場合でも、アプリがアクセスのスコープの承認をリクエストするたびに同意画面が表示されます。このため、必要な場合にのみ prompt=consent を含めます。
prompt パラメータの詳細については、Authentication URI パラメータの表の prompt をご覧ください。
認証 URI パラメータ
次の表に、Google の OAuth 2.0 認証 API で使用できるパラメータの詳細を示します。
| パラメータ | 必須 | 説明 |
|---|---|---|
client_id |
（必須） | API Console Credentials pageから取得したクライアント ID の文字列。OAuth 2.0 の認証情報を取得するをご覧ください。 |
nonce |
（必須） | 再生保護を有効にする、アプリによって生成されたランダムな値。 |
response_type |
（必須） | 値が code の場合、Basic 認可コードフローを開始します。このトークンの取得には、トークン エンドポイントへの POST が必要です。値が token id_token または id_token token の場合、暗黙的フローを起動します。その場合、リダイレクト URI で JavaScript を使用して、URI #fragment の ID からトークンを取得します。 |
redirect_uri |
（必須） | レスポンスの送信先を決定します。このパラメータの値は、 API Console Credentials page （HTTP または HTTPS スキーム、ケース、末尾の「/」を含む）で設定した承認済みリダイレクト値のいずれかと完全に一致する必要があります。 |
scope |
（必須） | スコープ パラメータは
OpenID 固有のスコープに加えて、スコープ引数に他のスコープ値を含めることもできます。スコープ値はすべてスペースで区切る必要があります。たとえば、ファイルごとにユーザーの Google ドライブにアクセスする場合、scope パラメータを 使用可能なスコープについては、Google API の OAuth 2.0 スコープまたは使用する Google API のドキュメントをご覧ください。 |
state |
（省略可、強く推奨） | プロトコルでラウンドトリップされる不透明な文字列。つまり、Basic フローでは URI パラメータとして、暗黙的フローでは URI
|
access_type |
（省略可） | 指定できる値は offline および online です。影響については、オフライン アクセスに記載されています。アクセス トークンがリクエストされている場合、offline の値が指定されていなければ、クライアントは更新トークンを受信しません。 |
display |
（省略可） | 認可サーバーが認証と同意のユーザー インターフェース ページをどのように表示するかを指定する ASCII 文字列値。page、popup、touch、wap の各値は指定して Google サーバーで受け入れられますが、動作には影響しません。 |
hd |
（省略可） | Google Cloud 組織が所有するアカウントのログイン プロセスを合理化できます。Google Cloud 組織のドメイン（mycollege.edu など）を含めると、そのドメインのアカウントに対してアカウント選択 UI を最適化できます。一般に、Google Cloud 組織ドメインを 1 つではなく Google Cloud 組織アカウント向けに最適化するには、アスタリスクの値（ クライアント側リクエストは変更できるため、この UI の最適化に依存して、アプリにアクセスできるユーザーを制御しないでください。返された ID トークンが、想定される内容と一致する |
include_granted_scopes |
（省略可） | このパラメータに値 true が指定されていて、承認リクエストが許可されると、承認には、他のスコープに対してこのユーザーとアプリケーションの組み合わせに以前に付与された承認が含まれます。段階的な承認をご覧ください。インストール済みアプリのフローでは、段階的な認可を行うことはできません。 |
login_hint |
（省略可） | 認証しようとしているユーザーをアプリが把握すると、このパラメータがヒントとして認証サーバーに提供されます。このヒントを渡すと、アカウント選択ツールが非表示になり、ログイン フォームのメールボックスに情報が自動入力されます。また、ユーザーが（マルチログインを使用している場合）適切なセッションが選択されるため、アプリが間違ったユーザー アカウントにログインするときに発生する問題を回避できます。
値には、メールアドレスまたは sub 文字列（ユーザーの Google ID と同等）を指定できます。 |
prompt |
（省略可） | 認証サーバーがユーザーに再認証と同意を求めるかどうかを指定する文字列値のスペース区切りリスト。選択可能な値は次のとおりです。
値が指定されておらず、ユーザーが以前にアクセスを承認していない場合は、同意画面が表示されます。 |
ID トークンの検証
Google から直接取得された場合を除き、サーバー上のすべての ID トークンを検証する必要があります。たとえば、サーバーはクライアント アプリから受信した ID トークンを真正として検証する必要があります。
次のような状況では、ID トークンがサーバーに送信されることがあります。
- 認証が必要なリクエストを含む ID トークンの送信ID トークンは、リクエストを行っている特定のユーザーと、その ID トークンが付与されたクライアントを示します。
ID トークンは機密情報であり、傍受されると悪用される可能性があります。これらのトークンは、HTTPS 経由と POST データまたはリクエスト ヘッダー内でのみ送信し、安全に処理する必要があります。ID トークンをサーバーに保存する場合は、そのトークンも安全に保管する必要があります。
ID トークンが役に立つのは、アプリのさまざまなコンポーネントで ID トークンを渡せるという点です。これらのコンポーネントは、アプリとユーザーを認証する簡単な認証メカニズムとして ID トークンを使用できます。ただし、ID トークンの情報を使用したり、ID をユーザーが認証したことを示すアサーションとして使用する前に、それを検証する必要があります。
ID トークンを検証するには、いくつかのステップが必要です。
- ID トークンがカード発行会社によって適切に署名されていることを確認します。Google が発行するトークンは、ディスカバリ ドキュメントの
jwks_uriメタデータ値で指定された URI で見つかった証明書のいずれかを使用して署名されます。 - ID トークン内の
issクレームの値がhttps://accounts.google.comまたはaccounts.google.comと等しいことを確認します。 - ID トークン内の
audクレームの値がアプリのクライアント ID と等しいことを確認します。 - ID トークンの有効期限（
expクレーム）が経過していないことを確認します。 - リクエストで hd パラメータの値を指定した場合は、ID トークンの
hdクレームが、Google Cloud 組織に関連付けられた承認済みドメインと一致することを確認します。
ステップ 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 標準を使用します。
OpenID に準拠するには、
openid profileスコープ値を認証リクエストに含める必要があります。ユーザーのメールアドレスを含めたい場合は、追加のスコープ値
emailを指定できます。profileとemailの両方を指定するには、認証リクエスト URI に次のパラメータを含めます。scope=openid%20profile%20email
- アクセス ヘッダーにアクセス トークンを追加し、userinfo エンドポイントに HTTPS
GETリクエストを行います。このリクエストは、userinfo_endpointメタデータ値を使用してディスカバリ ドキュメントから取得する必要があります。userinfo レスポンスには、ユーザーに関する情報が含まれます。この情報は、OpenID Connect Standard Claimsとディスカバリ ドキュメントのclaims_supportedメタデータ値に説明があります。ユーザーまたは組織は、特定のフィールドを入力または保留することを選択できます。その場合、承認済みのアクセス スコープのすべてのフィールドに関する情報を取得するわけではありません。
ディスカバリ ドキュメント
OpenID Connect プロトコルでは、ユーザーの認証と、トークン、ユーザー情報、公開鍵などのリソースのリクエストのために、複数のエンドポイントを使用する必要があります。
実装を簡素化し、柔軟性を高めるために、OpenID Connect では、OpenID Connect プロバイダの構成（認可、トークン、取り消し、userinfo、公開鍵エンドポイントの URI など）に関する詳細を含む、既知の場所にある 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 を取得します。たとえば、ユーザーを認証するには、authorization_endpoint メタデータ値（次の例の https://accounts.google.com/o/oauth2/v2/auth）を、Google に送信される認証リクエストのベース URI として取得します。
そのようなドキュメントの例を以下に示します。フィールド名は 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 の実装が簡単になります。
OpenID Connect コンプライアンス
Google の OAuth 2.0 認証システムは、OpenID Connect Core 仕様の必須機能をサポートしています。OpenID Connect で動作するように設計されたクライアントは、このサービスと相互運用する必要があります（OpenID Request Object を除く）。