OpenID Connect

Las API de OAuth 2.0 de Google se pueden usar para la autenticación y la autorización. En este documento, se describe nuestra implementación de OAuth 2.0 para la autenticación, que cumple con la especificación OpenID Connect y cuenta con la certificación de OpenID. La documentación que se encuentra en Usa OAuth 2.0 para acceder a las API de Google también se aplica a este servicio. Si deseas explorar este protocolo de forma interactiva, te recomendamos Google OAuth 2.0 Playground. Para obtener ayuda sobre Stack Overflow, etiqueta tus preguntas con "google-oauth".

Configuración de OAuth 2.0

Antes de que tu aplicación pueda usar el sistema de autenticación OAuth 2.0 de Google para el acceso del usuario, debes configurar un proyecto en Google API Console a fin de obtener credenciales de OAuth 2.0, establecer un URI de redireccionamiento y (opcionalmente) personalizar la información de desarrollo de la marca que ven tus usuarios en la pantalla de consentimiento del usuario. También puedes usar API Console para crear una cuenta de servicio, habilitar la facturación, configurar el filtrado y realizar otras tareas. Para obtener más detalles, consulta la Ayuda deGoogle API Console.

Obtén credenciales de OAuth 2.0

Necesitas credenciales de OAuth 2.0, incluidos un ID de cliente y un secreto del cliente, para autenticar a los usuarios y obtener acceso a las API de Google.

Para ver la ID del cliente y el secreto del cliente para una credencial OAuth 2.0 dada, haga clic en el siguiente texto: Seleccionar credencial . En la ventana que se abre, elija su proyecto y la credencial que desea, luego haga clic en Ver .

O vea su ID de cliente y el secreto del cliente desde la página de Credenciales en API Console :

1. Go to the Credentials page.
2. Haga clic en el nombre de su credencial o en el ícono de lápiz ( create ). Su ID de cliente y secreto están en la parte superior de la página.

Cómo establecer un URI de redireccionamiento

El URI de redireccionamiento que estableces en API Console determina el lugar al que Google envía las respuestas a tus solicitudes de autenticación.

Para crear, ver o editar los URI de redireccionamiento para una credencial de OAuth 2.0 dada, haga lo siguiente:

1. Go to the Credentials page.
2. En la sección de ID de cliente OAuth 2.0 de la página, haga clic en una credencial.
3. Ver o editar los URI de redireccionamiento.

Si no hay una sección de ID de cliente OAuth 2.0 en la página Credenciales, entonces su proyecto no tiene credenciales OAuth. Para crear uno, haga clic en Crear credenciales .

Cómo personalizar la pantalla de consentimiento del usuario

Para los usuarios, la experiencia de autenticación de OAuth 2.0 incluye una pantalla de consentimiento que describe la información que lanza y los términos que se aplican. Por ejemplo, cuando el usuario acceda, es posible que se le solicite que otorgue a tu app acceso a su dirección de correo electrónico y a la información básica de la cuenta. Solicitas acceso a esta información con el parámetro scope, que tu app incluye en su solicitud de autenticación. También puedes usar permisos para solicitar acceso a otras API de Google.

En la pantalla de consentimiento del usuario, también se muestra información de marca, como el nombre del producto, el logotipo y la URL de la página principal. Tú controlas la información de marca en el API Console.

Para habilitar la pantalla de consentimiento de su proyecto:

1. Abra el Consent Screen page en el Google API Console .
2. If prompted, select a project, or create a new one.
3. Rellene el formulario y haga clic en Guardar .

En el siguiente diálogo de consentimiento, se muestra lo que vería un usuario cuando una combinación de permisos de OAuth 2.0 y Google Drive estuviera presente en la solicitud. (Este diálogo genérico se generó con Google OAuth 2.0 Playground, por lo que no incluye información de desarrollo de la marca que se establecería en API Console).

Accede al servicio

Google y terceros proporcionan bibliotecas que puedes usar para encargarte de muchos de los detalles de implementación de la autenticación de usuarios y el acceso a las API de Google. Los ejemplos incluyen los Servicios de identidad de Google y las bibliotecas cliente de Google, que están disponibles para una variedad de plataformas.

Si eliges no usar una biblioteca, sigue las instrucciones que aparecen en el resto de este documento, en el que se describen los flujos de solicitudes HTTP que subyacen a las bibliotecas disponibles.

Autenticación del usuario

La autenticación del usuario implica obtener un token de ID y validarlo. Los tokens de ID son una función estandarizada de OpenID Connect diseñada para usarse en el uso compartido de aserciones de identidad en Internet.

Los enfoques más utilizados para autenticar a un usuario y obtener un token de ID se denominan flujo “servidor” y “flujo implícito”. El flujo del servidor permite que el servidor de backend de una aplicación verifique la identidad de la persona mediante un navegador o un dispositivo móvil. El flujo implícito se usa cuando una aplicación del cliente (por lo general, una app de JavaScript que se ejecuta en el navegador) necesita acceder a las APIs directamente en lugar de hacerlo a través de su servidor de backend.

En este documento, se describe cómo realizar el flujo del servidor para autenticar al usuario. El flujo implícito es mucho más complicado debido a los riesgos de seguridad en el manejo y el uso de tokens del cliente. Si necesitas implementar un flujo implícito, te recomendamos que uses los Servicios de identidad de Google.

Flujo del servidor

Asegúrate de configurar tu app en el API Console para que pueda usar estos protocolos y autenticar a tus usuarios. Cuando un usuario intenta acceder con Google, debes hacer lo siguiente:

1. Cómo crear un token de estado antifalsificación
2. Envía una solicitud de autenticación a Google.
3. Confirme el token de estado antifalsificación
4. Intercambia code por el token de acceso y del ID
5. Obtén información del usuario a partir del token de ID
6. Cómo autenticar al usuario

1. Cómo crear un token de estado antifalsificación

Debes evitar la falsificación de solicitudes para proteger la seguridad de los usuarios. El primer paso es crear un token de sesión único que mantenga el estado entre tu app y el cliente del usuario. Luego, harás coincidir este token de sesión único con la respuesta de autenticación que muestra el servicio de acceso de Google OAuth para verificar que el usuario haga la solicitud y no un atacante malicioso. Estos tokens se conocen como tokens de falsificación de solicitudes entre sitios (CSRF).

Una buena opción para un token de estado es una string de aproximadamente 30 caracteres construida con un generador de números al azar de alta calidad. Otro es un hash que se genera mediante la firma de algunas de las variables de estado de tu sesión con una clave que se mantiene en secreto en tu backend.

En el siguiente código, se demuestra la generación de tokens de sesión únicos.

// 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. Envía una solicitud de autenticación a Google

El siguiente paso es formar una solicitud GET HTTPS con los parámetros de URI adecuados. Observa el uso de HTTPS en lugar de HTTP en todos los pasos de este proceso; se rechazan las conexiones HTTP. Debes recuperar el URI base del documento de descubrimiento con el valor de metadatos authorization_endpoint. En la siguiente discusión, se da por sentado que el URI base es https://accounts.google.com/o/oauth2/v2/auth.

Para una solicitud básica, especifica los siguientes parámetros:

• client_id, que obtienes de API Console Credentials page.
• response_type, que en una solicitud básica de flujo de código de autorización debe ser code. (Obtén más información en response_type).
• scope, que en una solicitud básica debe ser openid email (Obtenga más información en scope).
• redirect_uri debe ser el extremo HTTP en tu servidor que recibirá la respuesta de Google. El valor debe coincidir exactamente con uno de los URI de redireccionamiento autorizados para el cliente de OAuth 2.0, que configuraste en el API Console Credentials page. Si este valor no coincide con un URI autorizado, la solicitud fallará y mostrará el error redirect_uri_mismatch.
• state debe incluir el valor del token de sesión único antifalsificación y cualquier otra información necesaria para recuperar el contexto cuando el usuario regresa a tu aplicación, p.ej., la URL de inicio. (Obtenga más información en state).
• nonce es un valor aleatorio que genera tu app y que habilita la protección contra la repetición cuando está presente.
• login_hint puede ser la dirección de correo electrónico del usuario o la string sub, que equivale al ID de Google del usuario. Si no proporcionas un login_hint y el usuario ya accedió, la pantalla de consentimiento incluirá una solicitud de aprobación para liberar la dirección de correo electrónico del usuario en la app. (Obtén más información en login_hint).
• Usa el parámetro hd a fin de optimizar el flujo de OpenID Connect para los usuarios de un dominio particular asociado con una organización de Google Cloud. (Obtén más información en hd).

Este es un ejemplo de un URI de autenticación de OpenID Connect completo, con saltos de línea y espacios para facilitar la lectura:

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

Los usuarios deben dar su consentimiento si la app solicita información nueva sobre ellos o si la app solicita acceso a la cuenta que no aprobaron anteriormente.

3. Confirmar el token de estado antifalsificación

La respuesta se envía al redirect_uri que especificaste en la solicitud. Todas las respuestas se muestran en la cadena de consulta, como se muestra a continuación:

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

En el servidor, debes confirmar que el state recibido de Google coincida con el token de sesión que creaste en el paso 1. Esta verificación de ida y vuelta ayuda a garantizar que el usuario, no una secuencia de comandos malintencionada, esté realizando la solicitud.

En el siguiente código, se muestra cómo confirmar los tokens de sesión que creaste en el paso 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. Intercambia code por el token de acceso y el token de ID

La respuesta incluye un parámetro code, un código de autorización único que tu servidor puede intercambiar por un token de ID y de acceso. Tu servidor realiza este intercambio enviando una solicitud POST HTTPS. La solicitud POST se envía al extremo del token, que debes recuperar del documento de descubrimiento con el valor de metadatos token_endpoint. En la siguiente discusión, se da por sentado que el extremo es https://oauth2.googleapis.com/token. La solicitud debe incluir los siguientes parámetros en el cuerpo de POST:

La solicitud real podría verse como el siguiente ejemplo:

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

Una respuesta correcta a esta solicitud contiene los siguientes campos en un array JSON:

5. Obtén información del usuario a partir del token de ID

Un token de ID es un JWT (token web JSON), es decir, un objeto JSON codificado en Base64 con firma criptográfica. Por lo general, es fundamental que valides un token de ID antes de usarlo, pero como te comunicas directamente con Google a través de un canal HTTPS sin intermediarios y usas tu secreto del cliente para autenticarte en Google, puedes estar seguro de que el token que recibes realmente proviene de Google y es válido. Si tu servidor pasa el token de ID a otros componentes de tu app, es muy importante que los otros componentes validen el token antes de usarlo.

Dado que la mayoría de las bibliotecas de API combinan la validación con el trabajo de decodificación de los valores codificados en Base64url y el análisis del JSON dentro, es probable que termines validando el token de todas formas cuando accedas a las reclamaciones en el token de ID.

La carga útil de un token de ID

Un token de ID es un objeto JSON que contiene un conjunto de pares nombre/valor. Este es un ejemplo con formato para facilitar la lectura:

{
  "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"
}

Los tokens de ID de Google pueden contener los siguientes campos (conocidos como reclamos):

6. Autentica al usuario

Después de obtener información del usuario a partir del token de ID, debes consultar la base de datos de usuarios de tu app. Si el usuario ya existe en tu base de datos, debes iniciar una sesión de aplicación para ese usuario si todos los requisitos de acceso se cumplen con la respuesta de la API de Google.

Si el usuario no existe en la base de datos de usuarios, debes redireccionarlo a tu flujo de registro de usuario nuevo. Es posible que puedas registrar automáticamente al usuario en función de la información que recibes de Google o, al menos, puedes prepropagar muchos de los campos que necesitas en tu formulario de registro. Además de la información del token de ID, puedes obtener información adicional del perfil del usuario en nuestros extremos del perfil de usuario.

Temas avanzados

En las siguientes secciones, se describe en detalle la API de Google OAuth 2.0. Esta información está dirigida a desarrolladores con requisitos avanzados en torno a la autenticación y autorización.

Acceso a otras API de Google

Una de las ventajas de usar OAuth 2.0 para la autenticación es que tu aplicación puede obtener permiso para usar otras API de Google en nombre del usuario (como YouTube, Google Drive, Calendario o Contactos) al mismo tiempo que autenticas al usuario. Para hacerlo, incluye los otros permisos que necesitas en la solicitud de autenticación que envías a Google. Por ejemplo, para agregar la edad del usuario a tu solicitud de autenticación, pasa un parámetro de permiso de openid email https://www.googleapis.com/auth/profile.agerange.read. El usuario recibirá un mensaje en la pantalla de consentimiento. El token de acceso que recibes de Google te permite acceder a todas las APIs relacionadas con los permisos de acceso que solicitaste y te otorgaron.

Tokens de actualización

En tu solicitud de acceso a la API, puedes solicitar que se muestre un token de actualización durante el intercambio code. Un token de actualización le brinda a tu app acceso continuo a las API de Google mientras el usuario no está presente en la aplicación. Para solicitar un token de actualización, agrega el parámetro access_type como offline en tu solicitud de autenticación.

Consideraciones:

• Asegúrate de almacenar el token de actualización de forma segura y permanente, ya que solo puedes obtener un token la primera vez que realices el flujo de intercambio de código.
• Existen límites sobre la cantidad de tokens de actualización que se emiten: uno para cada cliente y otro para todos los clientes. Si tu aplicación solicita demasiados tokens de actualización, puede llegar a estos límites, en cuyo caso los tokens de actualización más antiguos dejan de funcionar.

Para obtener más información, consulta Cómo actualizar un token de acceso (acceso sin conexión).

Solicitar consentimiento

Puedes pedirle al usuario que vuelva a autorizar tu app si configuras el parámetro prompt como consent en tu solicitud de autenticación. Cuando se incluye prompt=consent, se muestra la pantalla de consentimiento cada vez que tu app solicita autorización de permisos de acceso, incluso si todos los permisos se otorgaron previamente a tu proyecto de las API de Google. Por este motivo, incluye prompt=consent solo cuando sea necesario.

Para obtener más información sobre el parámetro prompt, consulta prompt en la tabla Parámetros de URI de autenticación.

Parámetros del URI de autenticación

En la siguiente tabla, se proporcionan descripciones más completas de los parámetros que acepta la API de autenticación de OAuth 2.0 de Google.

Cómo validar un token de ID

Debes validar todos los tokens de ID en tu servidor, a menos que sepas que provienen directamente de Google. Por ejemplo, tu servidor debe verificar como auténticos los tokens de ID que recibe de tus apps cliente.

Las siguientes son situaciones comunes en las que puedes enviar tokens de ID a tu servidor:

• Enviando tokens de ID con solicitudes que se deben autenticar. Los tokens de ID te indican el usuario específico que realiza la solicitud y para qué cliente se otorgó ese token de ID.

Los tokens de ID son sensibles y se pueden usar de forma inadecuada si se interceptan. Debes asegurarte de que estos tokens se manejen de forma segura transmitiéndolos solo a través de HTTPS y solo a través de datos de POST o dentro de los encabezados de la solicitud. Si almacenas tokens de ID en tu servidor, también debes almacenarlos de forma segura.

Un aspecto que hace que los tokens de ID sean útiles es que puedes pasarlos por diferentes componentes de tu app. Estos componentes pueden usar un token de ID como un mecanismo de autenticación liviano que autentica la app y el usuario. Sin embargo, antes de que puedas usar la información en el token de ID o confiar en ella como una aserción de que el usuario se autenticó, debes validarla.

La validación de un token de ID requiere varios pasos:

1. Verifica que la entidad emisora haya firmado correctamente el token de ID. Los tokens emitidos por Google se firman con uno de los certificados que se encuentran en el URI especificado en el valor de metadatos jwks_uri del documento de descubrimiento.
2. Verifica que el valor de la reclamación iss en el token de ID sea igual a https://accounts.google.com o accounts.google.com.
3. Verifica que el valor de la reclamación aud en el token de ID sea igual al ID de cliente de tu app.
4. Verifica que no haya pasado la fecha de vencimiento (exp reclamo) del token de ID.
5. Si especificaste un valor de parámetro hd en la solicitud, verifica que el token de ID tenga una reclamación hd que coincida con un dominio aceptado asociado a una organización de Google Cloud.

Los pasos del 2 al 5 solo incluyen comparaciones de strings y fechas que son bastante sencillas, por lo que no las indicaremos aquí.

El primer paso es más complejo y, además, implica la verificación de firmas criptográficas. Para la depuración, puedes usar el extremo tokeninfo de Google a fin de comparar con el procesamiento local implementado en tu servidor o dispositivo. Supongamos que el valor del token de ID es XYZ123. Luego, debes hacer referencia al URI https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123. Si la firma del token es válida, la respuesta sería la carga útil de JWT en su formato de objeto JSON decodificado.

El extremo tokeninfo es útil para la depuración, pero para fines de producción, recupera las claves públicas de Google desde el extremo de claves y realiza la validación de manera local. Debes recuperar el URI de claves del Documento de descubrimiento con el valor de metadatos jwks_uri. Las solicitudes al extremo de depuración pueden limitarse o estar sujetas a errores intermitentes.

Dado que Google cambia sus claves públicas solo con poca frecuencia, puedes almacenarlas en caché mediante las directivas de caché de la respuesta HTTP y, en la gran mayoría de los casos, realizar la validación local de manera mucho más eficiente que con el extremo tokeninfo. Esta validación requiere recuperar y analizar certificados, y realizar las llamadas criptográficas correspondientes para verificar la firma. Afortunadamente, existen bibliotecas bien depuradas disponibles en una amplia variedad de lenguajes para lograrlo (consulta jwt.io).

Cómo obtener la información del perfil del usuario

Para obtener información de perfil adicional sobre el usuario, puedes usar el token de acceso (que tu aplicación recibe durante el flujo de autenticación) y el estándar OpenID Connect:

1. Para cumplir con OpenID, debes incluir los valores de alcance openid profile en tu solicitud de autenticación.

   Si deseas que se incluya la dirección de correo electrónico del usuario, puedes especificar un valor de alcance adicional de email. Para especificar profile y email, puedes incluir el siguiente parámetro en el URI de la solicitud de autenticación:

   scope=openid%20profile%20email

2. Agrega el token de acceso al encabezado de autorización y realiza una solicitud GET de HTTPS al extremo userinfo, que debes recuperar del documento de descubrimiento con el valor de metadatos userinfo_endpoint. La respuesta de información del usuario incluye información sobre el usuario, como se describe en OpenID Connect Standard Claims y el valor de metadatos claims_supported del documento de descubrimiento. Los usuarios o sus organizaciones pueden optar por proporcionar o retener ciertos campos, por lo que es posible que no obtengas información de todos los campos para los permisos de acceso autorizados.

El documento de descubrimiento

El protocolo de OpenID Connect requiere el uso de múltiples extremos para autenticar usuarios y solicitar recursos, incluidos tokens, información del usuario y claves públicas.

Para simplificar las implementaciones y aumentar la flexibilidad, OpenID Connect permite el uso de un “documento de descubrimiento”, un documento JSON que se encuentra en una ubicación conocida que contiene pares clave-valor que proporcionan detalles sobre la configuración del proveedor de OpenID Connect, incluidos los URI de los extremos de autorización, token, revocación, información del usuario y claves públicas. El documento de descubrimiento para el servicio OpenID Connect de Google se puede recuperar de las siguientes formas:

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

Para usar los servicios de OpenID Connect de Google, debes codificar el URI de documento de descubrimiento (https://accounts.google.com/.well-known/openid-configuration) en tu aplicación. Tu aplicación recupera el documento, aplica reglas de almacenamiento en caché en la respuesta y, luego, recupera los URI de extremo según sea necesario. Por ejemplo, para autenticar un usuario, tu código recuperará el valor de metadatos authorization_endpoint (https://accounts.google.com/o/oauth2/v2/auth en el siguiente ejemplo) como el URI base para las solicitudes de autenticación que se envían a Google.

Aquí hay un ejemplo de un documento como este; los nombres de los campos son los especificados en OpenID Connect Discovery 1.0 (consulta sus significados en ese documento). Los valores son meramente ilustrativos y pueden cambiar, aunque se copiaron de una versión reciente del documento real de 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"
  ]
}

Para evitar una ida y vuelta HTTP, almacena en caché los valores del documento de descubrimiento. Se usan encabezados de almacenamiento en caché HTTP estándar que deben respetarse.

Bibliotecas cliente

Las siguientes bibliotecas cliente facilitan la implementación de OAuth 2.0 mediante la integración en frameworks populares:

• Biblioteca cliente de las API de Google para Java
• Biblioteca cliente de las API de Google para Python
• Biblioteca cliente de las API de Google para .NET
• Biblioteca cliente de las API de Google para Ruby
• Biblioteca cliente de las API de Google para PHP
• Biblioteca OAuth 2.0 para Google Web Toolkit
• Google Box Box para controladores de OAuth 2.0 para Mac

Cumplimiento de OpenID Connect

El sistema de autenticación de OAuth 2.0 de Google es compatible con las funciones requeridas de la especificación OpenID Connect Core. Cualquier cliente diseñado para funcionar con OpenID Connect debe interoperar con este servicio (a excepción del Objeto de solicitud de OpenID).