« All Docs
Google’s OpenID C...

Google’s OpenID Connect Service

OpenID Connect is an HTTP service based on the OAuth 2 framework.  Its purpose is to allow an application developer (“Relying Party” or RP) to:

  • Verify that the person using the app has authenticated as the owner of a Google Account, and
  • retrieve a basic package of information about that person (email address, personal name, gender, and so on).

Note: Accessing the Service

A variety of libraries, from Google and third parties, provide APIs for accessing this service, taking care of many of the implementation details, in many cases to support access to Google APIs.  Examples include the Google APIs Client Library for Java.

This document describes the HTTP request flows that underly these libraries.  While they are available for public use, developers are advised, if possible, to take advantage of a pre-written library and avoid the work of dealing with low-level network traffic.  Authenticating users properly is important to their and your safety and security, and using well-debugged code written by others is generally a best practice.

Note: Standards Conformance

Our intent is that this service implement the required features of the OpenID Connect “Basic” and “Implicit” flows.  Any client which is designed to work with those features should interoperate with this service.

Note: OAuth 2.0 and OpenID Connect

OpenID Connect is based on OAuth 2.0, and the documentation found in Using OAuth 2.0 to Access Google APIs applies.  OpenID Connect adds several concepts using OAuth 2.0 extension mechanisms; the following are used by this Google service:

  • New scope values “openid”, “email”, and “profile”
  • New response_type values “id_token token” and “token id_token”
  • The use of “ID Tokens”, implemented as JSON Web Tokens containing name/value pairs called “claims”, and accompanied by a cryptographic signature
  • A resource called the Userinfo endpoint, which may be used to retrieve a package of information about an authenticated user.

The Google OAuth 2.0 Playground is recommended for interactive exploration of this protocol.

1. Registering Your App

Any application that wants to use this service must be registered at the Google Developer Console.  You will need to create a Client ID for a Web Application; this will yield two strings, “Client ID” and “Client Secret”, which are used in accessing the service. It will also specify a “redirect URI”, used in obtaining tokens.

Registering the app also allows you to provide text and an image for branding purposes, to be presented to users when they are prompted to approve authentication with your app.

2. Obtaining an ID Token

Authenticating a user involves two steps: Obtaining an Access Token and ID Token, and validating the ID Token.  The process of obtaining tokens is a standard OAuth2 process, with two possible message flows:

  1. The RP issues an HTTPS GET request to an “Authentication URI”, which combines the base with a variety of parameters described below.
  2. Depending on the response_type parameter, two flows can ensue:
  1. Basic flow (“response_type=code”)
  1. The request redirects to the redirect URI and includes a “code” parameter.
  2. The RP issues an HTTPS POST request to the Token endpoint including the code value and the Client Secret; the endpoint returns a JSON body including the requested tokens.
  1. Implicit flow (“response_type” includes either “id_token” or “token”)
  1. The request redirects to the redirect URI, including the requested tokens in the URI #fragment, where they can be retrieved and used by JavaScript code.

Developers are referred to Using OAuth 2.0 to Access Google APIs for details on implementing these flows.

2.1 Authentication URI Parameters

The first step is an HTTPS GET request.  Note the use of HTTPS rather than HTTP in all the steps of this process; HTTP connections are refused.  The base URI is “”, and the following parameters are used:

client_id (required)

This is the Client-ID string obtained when registering your app at the Developer Console.

response_type (required)

If the value is “code”, launches a Basic flow, requiring a POST to the Token Endpoint to obtain the tokens.  If the value is “token id_token” or “id_token token”, launches an Implicit flow, requiring the use of Javascript at the redirect URI to retrieve tokens from the URI #fragment.

scope (required)

The scope value must begin with the string “openid ” and then include either or both of “profile” and “email”.  Thus, possible values are “openid email”, “openid profile”, “openid profile email” and “openid email profile”.

The presence of “email” requests that the ID Token include “email” and “email_verified” claims, and that these values be included in the information available at the Userinfo endpoint.  The presence of “profile” requests that a package of  personal information be provided at the Userinfo endpoint.

When the user is asked to approve the authorization, the selection of scopes will affect the description he or she sees of what information will be made available to your application.

redirect_uri (required)

Determines where the response is sent. The value of this parameter must exactly match one of the values registered in the Developer Console (including the http or https schemes, case, and trailing '/').

state (optional, but strongly recommended)

This is an opaque string that you can supply, which is round-tripped in the protocol; that is to say, it is returned as a URI parameter in the Basic flow, and in the URI #fragment in the Implicit flow.  This may be useful to applications in correlating requests and responses.  Since it is possible to guess your redirect_uri, using a state value can increase your assurance that an incoming connection to it is the result of an authorization request.  If you encode the hash of some client state (e.g., a cookie) in this state variable you additionally ensure that the request and response originated in the same browser (by validating the hash when processing the auth response) for protection against some attacks, such as cross-site request forgery.

prompt  (optional)

A space-delimited list of string values that specifies whether the Authorization Server prompts the user for reauthentication and consent. The possible values are:


The Authorization Server will not display any authentication or consent pages; it will return an error if the user is not already authenticated and has not  pre-configured consent for the requested scopes. This can be used as a method to check for existing authentication and/or consent.


The Authorization Server will prompt the user for consent before returning information to the Client.


The Authorization Server will prompt the user to select a user account. This allows a user who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they may have current sessions for.

display (optional)

An ASCII string value that specifies how the Authorization Server displays the authentication and consent user interface pages. The following values are specified, and accepted by the Google servers, but do not have any effect on its behavior: “page”, “popup”, “touch”, and “wap”.

login_hint (optional)

When the RP knows which which user it is trying to authenticate, it may provide this parameter as a hint to the Authentication Server.  The value can be either an email address or user_id string.

access_type (optional)

The allowed values are “offline” and “online”.  The effect is documented in Offline Access; if an Access Token is being requested, the client will not receive a Refresh Token unless “offline” is specified.

Here is an example of a complete OpenID Connect Authorization URI, with line-breaks inserted for readability after the “?” and each of the “&” parameter separators:

3. Validating an ID Token

Before you can use the information in ID Token, or rely on it as an assertion that the user has authenticated, you must validate it.  Validation comprises two steps:

  1. Verify that the ID Token is a JWT which is properly signed with an appropriate Google public key
  2. Verify that the value of the “aud” field in the ID Token is identical to your app’s Client ID.

The second step is just a string comparison.  The first is a little more complex, and there are two strategies for accomplishing it:

  1. Use Google’s TokenInfo endpoint. Suppose your ID Token’s value is “XYZ123”. Then you would dereference the URI
    If the token is valid, the response would be its decoded JSON form.
  2. Retrieve Google’s public keys from and perform the validation locally.  

Since Google changes its public keys only infrequently (on the order of once per day), you can cache them and, in the vast majority of cases, perform local validation much more efficiently than by using the TokenInfo endpoint.  This requires retrieving and parsing certificates, and making the appropriate crypto calls to check the signature.  Fortunately, there are well-debugged libraries available in a wide variety of languages to accomplish this.

Java programmers can use the open-source GoogleIDToken and GoogleIDTokenVerifer classes.  For Rubyists using the Google API Library there’s Google::APIClient#verify_id_token! and if you don’t need the whole library, there’s a “google-id-token” gem which provides GoogleIDToken::Validator#check.

These libraries normally validate the token and return its parsed payload (if valid) in one step.

4. An ID Token’s Payload

An ID Token contains a set of name/value pairs called “claims”.  Here’s an example, formatted for readability:

"exp":1353604926 }

The fields used by Google are:

iss (required)

The Issuer Identifier for the Issuer of the response.


If the ID Token is issued with an Access Token in an Implicit flow, this is required. The value is produced by base64url encoding the leftmost half of the hash created by hashing the access_token with the SHA-2 family hash algorithm of the same length as the hash used in the alg parameter of the JWS header. For instance, if the alg is HS256, hash access_token with SHA-256, then take the leftmost 128 bits and base64url encode them.


True if the user's e-mail address has been verified; otherwise false.

sub (required)

An identifier for the user, unique among all Google accounts and never reused. A Google account can have multiple emails at different points in time, but this user_id is never changed. You should use this within your application as the unique-identifier key for the user.


The user’s email address.  This may not be unique and is not suitable for use as a primary key.  Provided only if your scope included the string “email”.

aud (required)

Identifies the audience that this ID Token is intended for. It must be the OAuth 2.0 Client ID of your application.

iat (required)

An integer giving the time the ID Token was issued, in seconds since the beginning of 1970, UTC.

exp (required)

An integer giving the time the ID Token expires, in seconds since the beginning of 1970, UTC.

5. Obtaining User Profile Information

If your scope included the value “profile”, you may dereference the URI “” to retrieve a package of information, encoded in JSON, about the user.   You will need to use the Access Token (not ID Token) you received in  the OAuth 2.0 authentication flow. It may be used either in a URI parameter or HTTP header, in the standard OAuth 2.0 fashion.

Different users may choose to supply or withhold certain of these fields.  The user’s email address will be included only if your scope also included the value “email”.

The values in a typical Google profile might include “sub”, “email”, “email_verified”, “name”, “given_name”, “family_name”, “picture”, “gender”, “birthdate”, and “locale”.  These are fairly self-explanatory, but there are a couple of things to watch out for.

  • The “gender” value is not constrained to the values “male” and “female”.
  • The “birthdate” is provided in YYYY-MM-DD format, but if the user chooses not to disclose the year, it is given as 9999”.