En este documento, se explica cómo las aplicaciones instaladas en dispositivos como teléfonos, tablets y computadoras usan los extremos OAuth 2.0 de Google para autorizar el acceso a las API de Google.
OAuth 2.0 permite a los usuarios compartir datos específicos con una aplicación y, a la vez, mantener la privacidad de sus nombres de usuario, contraseñas y otros datos. Por ejemplo, una aplicación puede usar OAuth 2.0 a fin de obtener permiso de los usuarios para almacenar archivos en sus unidades de Google Drive.
Las apps instaladas se distribuyen a dispositivos individuales, y se supone que estas apps no pueden guardar secretos. Pueden acceder a las API de Google mientras el usuario está presente en la app o cuando la app se ejecuta en segundo plano.
Este flujo de autorización es similar al que se usa para las aplicaciones de servidor web. La principal diferencia es que las apps instaladas deben abrir el navegador del sistema y proporcionar un URI de redireccionamiento local para administrar las respuestas del servidor de autorización de Google.
Alternativas:
En el caso de las apps para dispositivos móviles, es posible que prefieras usar el Acceso con Google en Android o iOS. Las bibliotecas cliente de Acceso con Google manejan la autenticación y la autorización del usuario, y es posible que su implementación sea más sencilla que la del protocolo de nivel inferior descrito aquí.
Para las apps que se ejecutan en dispositivos que no admiten un navegador del sistema o que tienen capacidades de entrada limitadas, como TVs, consolas de juegos, cámaras o impresoras, consulta OAuth 2.0 para TV y dispositivos o Acceso en TVs y dispositivos de entrada limitados.
Bibliotecas y muestras
Recomendamos las siguientes bibliotecas y muestras para ayudarte a implementar el flujo de OAuth 2.0 que se describe en este documento:
- Biblioteca AppAuth para Android
- Biblioteca AppAuth para iOS
- OAuth para apps: muestras de Windows
Requisitos previos
Habilita las API para tu proyecto.
Cualquier aplicación que llame a las API de Google debe habilitar esas API en el API Console.
Para habilitar una API en tu proyecto, sigue estos pasos:
- Open the API Library en Google API Console.
- If prompted, select a project, or create a new one.
- API Library enumera todas las API disponibles, agrupadas por familia de productos y popularidad. Si la API que quieres habilitar no está visible en la lista, usa la búsqueda para encontrarla o haz clic en Ver todo en la familia de productos a la que pertenece.
- Selecciona la API que deseas habilitar y, luego, haz clic en el botón Habilitar.
- If prompted, enable billing.
- If prompted, read and accept the API's Terms of Service.
Crea credenciales de autorización
Cualquier aplicación que use OAuth 2.0 para acceder a las API de Google debe tener credenciales de autorización que identifiquen la aplicación al servidor OAuth 2.0 de Google. En los siguientes pasos, se explica cómo crear credenciales para tu proyecto. Luego, tus aplicaciones pueden usar las credenciales para acceder a las API que hayas habilitado en ese proyecto.
- Go to the Credentials page.
- Haz clic en Crear credenciales > ID de cliente de OAuth.
- En las siguientes secciones, se describen los tipos de clientes y los métodos de redireccionamiento que admite el servidor de autorización de Google. Elige el tipo de cliente que se recomienda para tu aplicación, asigna un nombre a tu cliente de OAuth y establece los otros campos en el formulario según corresponda.
Esquema de URI personalizado (Android, iOS, UWP)
Se recomienda un esquema de URI personalizado para las apps de Android, las apps para iOS y las apps de Universal Windows Platform (UWP).
Android
- Selecciona el tipo de aplicación Android.
- Ingresa un nombre para el cliente OAuth. Este nombre se muestra en el Credentials page de tu proyecto para identificar al cliente.
- Ingresa el nombre del paquete de tu app para Android. Este valor se define en el
atributo
package
del elemento<manifest>
en el archivo de manifiesto de tu app. - Ingresa la huella digital del certificado de firma SHA-1 de la distribución de la app.
- Si tu app usa la firma de apps de Google Play, copia la huella digital SHA-1 de la página de firma de apps de Play Console.
- Si administras tu keystore propio y las claves de firma, usa la utilidad keytool incluida con Java para imprimir información de certificados en un formato legible. Copia el valor
SHA1
en la secciónCertificate fingerprints
del resultado de keytool. Consulta Cómo autenticar tu cliente en la documentación de las API de Google para Android para obtener más información.
- Haz clic en Crear.
iOS
- Selecciona el tipo de aplicación iOS.
- Ingresa un nombre para el cliente OAuth. Este nombre se muestra en el Credentials page de tu proyecto para identificar al cliente.
- Ingresa el identificador de paquete para tu app. El ID del paquete es el valor de la clave CFBundleIdentifier en el archivo de recursos de la lista de propiedades de información de tu app (info.plist). Por lo general, el valor se muestra en el panel General o en el panel Signing & Capabilities del editor de proyectos de Xcode. El ID del paquete también se muestra en la sección Información general de la página Información de la app de App Store Connect en el sitio de Apple.
- (opcional)
Ingrese el ID de App Store de su aplicación si la aplicación está publicada en App Store de Apple. El ID de tienda es una string numérica incluida en cada URL de la App Store de Apple.
- Abre la app de Apple App Store en tu dispositivo iOS o iPadOS.
- Busca tu app.
- Selecciona el botón Compartir (cuadrado y flecha hacia arriba).
- Selecciona Copiar vínculo.
- Pega el vínculo en un editor de texto. El ID de App Store es la parte final de la URL.
Ejemplo:
https://apps.apple.com/app/google/id284815942
- (opcional)
Ingresa tu ID de equipo. Consulta Encuentra el ID de tu equipo en la documentación de la cuenta de desarrollador de Apple para obtener más información.
- Haz clic en Crear.
UWP
- Selecciona el tipo de aplicación Plataforma universal de Windows.
- Ingresa un nombre para el cliente OAuth. Este nombre se muestra en el Credentials page de tu proyecto para identificar al cliente.
- Ingresa el ID de Microsoft Store de 12 caracteres de tu app. Puedes encontrar este valor en el Centro de socios de Microsoft, en la página Identidad de la app, en la sección Administración de apps.
- Haz clic en Crear.
Para las apps de UWP, el esquema de URI personalizado no puede tener más de 39 caracteres.
Dirección IP de bucle invertido (macOS, Linux, computadora de escritorio de Windows)
Para recibir el código de autorización con esta URL, tu aplicación debe escuchar en el servidor web local. Esto es posible en muchas plataformas, pero no en todas. Sin embargo, si tu plataforma lo admite, este es el mecanismo recomendado para obtener el código de autorización.
Cuando tu app recibe la respuesta de autorización, para obtener la mejor usabilidad, debe responder mostrando una página HTML que le indique al usuario cerrar el navegador y regresar a tu app.
Uso recomendado | Apps para computadoras de escritorio de macOS, Linux y Windows (pero no las plataformas universales de Windows) |
Valores de formulario | Configure el tipo de aplicación como Aplicación para computadoras de escritorio. |
Copiar y pegar manualmente
Identifica permisos de acceso
Los alcances permiten que la aplicación solo solicite acceso a los recursos que necesita, al mismo tiempo que permiten que los usuarios controlen la cantidad de acceso que otorgan a la aplicación. Por lo tanto, puede haber una relación inversa entre la cantidad de alcances solicitados y la probabilidad de obtener el consentimiento del usuario.
Antes de comenzar a implementar la autorización OAuth 2.0, te recomendamos que identifiques los permisos para los que tu app necesitará permiso de acceso.
El documento Alcances de la API de OAuth 2.0 contiene una lista completa de los permisos que puedes usar para acceder a las API de Google.
Obtén tokens de acceso de OAuth 2.0
En los siguientes pasos, se muestra cómo tu aplicación interactúa con el servidor de OAuth 2.0 de Google a fin de obtener el consentimiento de un usuario para realizar una solicitud a la API en nombre del usuario. Tu aplicación debe tener ese consentimiento antes de poder ejecutar una solicitud a la API de Google que requiera la autorización del usuario.
Paso 1: Genera un verificador de código y un desafío
Google admite el protocolo de clave de prueba para el intercambio de código (PKCE) a fin de que el flujo de la app instalada sea más seguro. Se crea un verificador de código único para cada solicitud de autorización, y su valor transformado, llamado "code_challenge", se envía al servidor de autorización para obtener el código de autorización.
Crea el verificador de código
Un code_verifier
es una string criptográfica criptográfica de alta entropía que usa los caracteres no reservados [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", con una longitud mínima de 43 caracteres y una longitud máxima de 128 caracteres.
El verificador de código debe tener la entropía suficiente para que no sea práctico adivinar el valor.
Crea el desafío del código
Se admiten dos métodos para crear el desafío de código.
Métodos de generación de desafíos de código | |
---|---|
S256 (recomendado) | El desafío de código es el hash SHA256 codificado en Base64URL del verificador del código.
|
sin formato | El desafío de código tiene el mismo valor que el verificador de código que se generó anteriormente.
|
Paso 2: Envía una solicitud al servidor de OAuth 2.0 de Google
Para obtener la autorización del usuario, envía una solicitud al servidor de autorización de Google en https://accounts.google.com/o/oauth2/v2/auth
. Este extremo controla la búsqueda activa de sesiones, autentica al usuario y obtiene su consentimiento. Solo se puede acceder al extremo mediante SSL, y rechaza las conexiones HTTP (no SSL).
El servidor de autorización admite los siguientes parámetros de string de consulta para aplicaciones instaladas:
Parámetros | |||||||
---|---|---|---|---|---|---|---|
client_id |
Obligatorio
El ID de cliente para tu aplicación. Puedes encontrar este valor en la Credentials pagede API Console. |
||||||
redirect_uri |
Obligatorio
Determina cómo el servidor de autorización de Google envía una respuesta a tu app. Existen varias opciones de redireccionamiento disponibles para las apps instaladas, y tendrás que configurar tus credenciales de autorización con un método de redireccionamiento en particular. El valor debe coincidir exactamente con uno de los URI de redireccionamiento autorizados para el cliente OAuth 2.0, que configuraste en el API Console
Credentials pagede tu cliente. Si este valor no coincide con un URI autorizado, recibirás un error En la siguiente tabla, se muestra el valor del parámetro
|
||||||
response_type |
Obligatorio
Determina si el extremo de Google OAuth 2.0 muestra un código de autorización. Establece el valor del parámetro en |
||||||
scope |
Obligatorio
Una lista delimitada por espacios de los alcances que identifican los recursos a los que tu aplicación podría acceder en nombre del usuario. Estos valores informan la pantalla de consentimiento que Google le muestra al usuario. Los alcances permiten que la aplicación solo solicite acceso a los recursos que necesita, al mismo tiempo que permiten que los usuarios controlen la cantidad de acceso que otorgan a la aplicación. Por lo tanto, existe una relación inversa entre la cantidad de alcances solicitados y la probabilidad de obtener el consentimiento del usuario. |
||||||
code_challenge |
Se recomienda
Especifica un |
||||||
code_challenge_method |
Se recomienda
Especifica qué método se usó para codificar un |
||||||
state |
Se recomienda
Especifica cualquier valor de string que use tu aplicación para mantener el estado entre tu solicitud de autorización y la respuesta del servidor de autorización.
El servidor muestra el valor exacto que envías como un par Puedes usar este parámetro para varios propósitos, como dirigir al usuario al recurso correcto en tu aplicación, enviar nonces y mitigar la falsificación de solicitudes entre sitios. Como se puede adivinar tu |
||||||
login_hint |
Optional
Si tu aplicación sabe qué usuario intenta autenticarse, puede usar este parámetro para proporcionar una sugerencia al servidor de autenticación de Google. El servidor usa la sugerencia para simplificar el flujo de acceso, ya sea completando el campo de correo electrónico en el formulario de acceso o seleccionando la sesión de acceso múltiple adecuada. Establece el valor del parámetro en una dirección de correo electrónico o en un identificador |
URL de autorización de muestra
Las pestañas a continuación muestran ejemplos de URL de autorización para las diferentes opciones de URI de redireccionamiento.
Las URLs son idénticas, excepto por el valor del parámetro redirect_uri
. Las URL también contienen los parámetros response_type
y client_id
obligatorios, así como el parámetro opcional state
. Cada URL contiene saltos de línea y espacios para facilitar la lectura.
Esquema de URI personalizado
https://accounts.google.com/o/oauth2/v2/auth? scope=& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=com.example.app%3A/oauth2redirect& client_id=client_id
Dirección IP de bucle invertido
https://accounts.google.com/o/oauth2/v2/auth? scope=& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=http%3A//127.0.0.1%3A9004& client_id=client_id
Paso 3: Google solicita el consentimiento del usuario
En este paso, el usuario decide si concede a tu aplicación el acceso solicitado. En esta etapa, Google muestra una ventana de consentimiento en la que aparece el nombre de tu aplicación y los servicios de la API de Google a los que solicita permiso para acceder con las credenciales de autorización del usuario y un resumen de los permisos de acceso que se otorgarán. Luego, el usuario puede aceptar otorgar acceso a uno o más alcances solicitados por la aplicación o rechazar la solicitud.
Tu aplicación no necesita hacer nada en esta etapa mientras espera la respuesta del servidor de OAuth 2.0 de Google que indica si se otorgó acceso. Esa respuesta se explica en el siguiente paso.
Errores
Las solicitudes al extremo de autorización de OAuth 2.0 de Google pueden mostrar mensajes de error orientados al usuario en lugar de los flujos de autenticación y autorización esperados. A continuación, se indican los códigos de error comunes y las resoluciones sugeridas.
admin_policy_enforced
La Cuenta de Google no puede autorizar uno o más permisos solicitados debido a las políticas de su administrador de Google Workspace. Consulta el artículo de ayuda para administradores de Google Workspace Controla qué apps internas y de terceros acceden a los datos de Google Workspace para obtener más información sobre cómo un administrador puede restringir el acceso a todos los permisos o a los permisos sensibles y restringidos hasta que se otorgue acceso de forma explícita a tu ID de cliente de OAuth.
disallowed_useragent
El extremo de autorización se muestra dentro de un usuario-agente incorporado que no está permitido en las Políticas de OAuth 2.0 de Google.
Android
Es posible que los desarrolladores de Android vean este mensaje de error cuando abran solicitudes de autorización en android.webkit.WebView
.
En su lugar, los desarrolladores deben usar bibliotecas de Android, como Acceso con Google para Android o AppAuth para Android de OpenID Foundation.
Los desarrolladores web pueden encontrar este error cuando una app para Android abre un vínculo web general en un usuario-agente incorporado y un usuario navega al extremo de autorización de OAuth 2.0 de Google desde tu sitio. Los desarrolladores deben permitir que se abran vínculos generales en el controlador de vínculos predeterminado del sistema operativo, que incluye los controladores de Android App Links o la app de navegador predeterminada. También se admite la biblioteca de pestañas personalizadas de Android.
iOS
Los desarrolladores de iOS y macOS pueden encontrar este error cuando abren solicitudes de autorización en WKWebView
.
En su lugar, los desarrolladores deben usar bibliotecas para iOS, como el Acceso con Google para iOS o AppAuth para iOS de OpenID Foundation.
Los desarrolladores web pueden encontrar este error cuando una app para iOS o macOS abre un vínculo web general en un usuario-agente incorporado y un usuario navega al extremo de autorización de OAuth 2.0 de Google desde tu sitio. Los desarrolladores deben permitir que se abran vínculos generales en el controlador de vínculos predeterminado del sistema operativo, que incluye los controladores de Universal Links o la app de navegador predeterminada. La biblioteca SFSafariViewController
también es una opción compatible.
org_internal
El ID de cliente de OAuth de la solicitud forma parte de un proyecto que limita el acceso a las Cuentas de Google en una organización de Google Cloud específica. Para obtener más información sobre esta opción de configuración, consulta la sección Tipo de usuario en el artículo de ayuda Configura tu pantalla de consentimiento de OAuth.
invalid_grant
Si usas un verificador de códigos y una verificación, el parámetro code_callenge
no es válido o no está presente. Asegúrate de que el parámetro code_challenge
esté configurado de forma correcta.
Al actualizar un token de acceso, es posible que este haya caducado o se haya invalidado. Vuelve a autenticar al usuario y pídele su consentimiento para obtener nuevos tokens. Si continúas viendo este error, asegúrate de que tu aplicación se haya configurado correctamente y de que estés usando los tokens y parámetros correctos en tu solicitud. De lo contrario, es posible que la cuenta de usuario se haya borrado o inhabilitado.
redirect_uri_mismatch
El redirect_uri
que se pasa en la solicitud de autorización no coincide con un URI de redireccionamiento autorizado para el ID de cliente de OAuth. Revisa los URI de redireccionamiento autorizados en Google API Console Credentials page.
Es posible que el redirect_uri
que se pasó no sea válido para el tipo de cliente.
El parámetro redirect_uri
puede referirse al flujo de OAuth fuera de banda (OOB) que dejó de estar disponible y ya no es compatible. Consulta la guía de migración para actualizar tu integración.
Paso 4: Controla la respuesta del servidor de OAuth 2.0
El modo en que tu aplicación recibe la respuesta de autorización depende del esquema de URI de redireccionamiento que utiliza. Sin importar el esquema, la respuesta contendrá un código de autorización (code
) o un error (error
). Por ejemplo, error=access_denied
indica que el usuario rechazó la solicitud.
Si el usuario otorga acceso a tu aplicación, puedes intercambiar el código de autorización por un token de acceso y un token de actualización como se describe en el siguiente paso.
Paso 5: Intercambia el código de autorización por tokens de actualización y de acceso
Para intercambiar un código de autorización por un token de acceso, llama al extremo https://oauth2.googleapis.com/token
y establece los siguientes parámetros:
Campos | |
---|---|
client_id |
Es el ID de cliente obtenido de API Console Credentials page. |
client_secret |
El secreto del cliente obtenido de API Console Credentials page. |
code |
El código de autorización que muestra la solicitud inicial. |
code_verifier |
El verificador de código que creaste en el Paso 1 |
grant_type |
Según se define en la especificación OAuth 2.0, el valor de este campo debe establecerse en authorization_code . |
redirect_uri |
Uno de los URI de redireccionamiento enumerados para tu proyecto en el API Console
Credentials page para la client_id determinada. |
En el siguiente fragmento, se muestra una solicitud de muestra:
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=http://127.0.0.1:9004& grant_type=authorization_code
Para responder a esta solicitud, Google muestra un objeto JSON que contiene un token de acceso de corta duración y un token de actualización.
La respuesta contiene los siguientes campos:
Campos | |
---|---|
access_token |
El token que envía la aplicación para autorizar una solicitud de la API de Google. |
expires_in |
La vida útil restante del token de acceso en segundos. |
id_token |
Nota: Esta propiedad solo se muestra si tu solicitud incluía un permiso de identidad, como openid , profile o email . El valor es un token web JSON (JWT) que contiene información de identidad con firma digital del usuario. |
refresh_token |
Un token que puedes usar para obtener un nuevo token de acceso. Los tokens de actualización son válidos hasta que el usuario revoque el acceso. Ten en cuenta que los tokens de actualización siempre se muestran en las aplicaciones instaladas. |
scope |
Los permisos de acceso que otorga access_token se expresan como una lista de strings delimitadas por mayúsculas y minúsculas, y que distinguen entre mayúsculas y minúsculas. |
token_type |
El tipo de token mostrado. En este momento, el valor de este campo siempre es Bearer . |
En el siguiente fragmento, se muestra una respuesta de muestra:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/drive.metadata.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
Llamar a las API de Google
Una vez que tu aplicación obtenga un token de acceso, puedes usarlo para realizar llamadas a una API de Google en nombre de una cuenta de usuario determinada si se otorgaron los permisos de acceso que requiere la API. Para ello, incluye el token de acceso en una solicitud a la API mediante la inclusión de un parámetro de consulta access_token
o un valor de encabezado HTTP Bearer
de Authorization
. Siempre que sea posible, es preferible usar el encabezado HTTP, ya que las strings de consulta suelen ser visibles en los registros del servidor. En la mayoría de los casos, puedes usar una biblioteca cliente para configurar tus llamadas a las API de Google (por ejemplo, cuando llamas a la API de archivos de Drive).
Puedes probar todas las API de Google y ver sus permisos en OAuth 2.0 Playground.
Ejemplos de HTTP GET
Una llamada al extremo
drive.files
(la API de archivos de Drive) que usa el encabezado HTTP Authorization: Bearer
podría verse de la siguiente manera. Ten en cuenta que debes especificar tu propio token de acceso:
GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Esta es una llamada a la misma API para el usuario autenticado que usa el parámetro de string de consulta access_token
:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
curl
ejemplos
Puedes probar estos comandos con la aplicación de línea de comandos de curl
. A continuación, te mostramos un ejemplo en el que se usa la opción de encabezado HTTP (opción preferida):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Como alternativa, la opción de parámetro de string de consulta:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
Actualización de un token de acceso
Los tokens de acceso caducan periódicamente y se convierten en credenciales no válidas para una solicitud de API relacionada. Puedes actualizar un token de acceso sin solicitarle permiso al usuario (incluso cuando no está presente) si solicitaste acceso sin conexión a los permisos asociados con el token.
Para actualizar un token de acceso, la aplicación envía una solicitud POST
de HTTPS al servidor de autorización de Google (https://oauth2.googleapis.com/token
) que incluye los siguientes parámetros:
Campos | |
---|---|
client_id |
El ID de cliente obtenido de API Console. |
client_secret |
El secreto de cliente obtenido de API Console.
client_secret no se aplica a solicitudes de clientes registrados como aplicaciones para Android, iOS o Chrome.
|
grant_type |
Como se define en la especificación OAuth 2.0, el valor de este campo debe establecerse en refresh_token . |
refresh_token |
El token de actualización que muestra el intercambio de códigos de autorización. |
En el siguiente fragmento, se muestra una solicitud de muestra:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=your_client_id& client_secret=your_client_secret& refresh_token=refresh_token& grant_type=refresh_token
Siempre que el usuario no haya revocado el acceso otorgado a la aplicación, el servidor de tokens muestra un objeto JSON que contiene un token de acceso nuevo. En el siguiente fragmento, se muestra una respuesta de muestra:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "scope": "https://www.googleapis.com/auth/drive.metadata.readonly", "token_type": "Bearer" }
Ten en cuenta que hay límites en la cantidad de tokens de actualización que se emitirán: uno por cada cliente y otro por cada usuario. Debes guardar los tokens de actualización en un almacenamiento a largo plazo y seguir usándolos mientras sean válidos. Si tu aplicación solicita demasiados tokens de actualización, podría llegar a estos límites, en cuyo caso los tokens de actualización más antiguos dejarán de funcionar.
Revoca un token
En algunos casos, es posible que un usuario quiera revocar el acceso a una aplicación. Para revocar el acceso, el usuario debe ir a la Configuración de la cuenta. Consulta la sección Cómo quitar el acceso a sitios o apps de los sitios y apps de terceros con acceso a tu cuenta para obtener más información.
También es posible que una aplicación revoque de manera programática el acceso que se le otorgó. La revocación programática es importante en las instancias en las que un usuario anula la suscripción, quita una aplicación o los recursos de la API que una app cambió de manera significativa. En otras palabras, una parte del proceso de eliminación puede incluir una solicitud a la API para garantizar que se quiten los permisos otorgados anteriormente a la aplicación.
Para revocar un token de manera programática, la aplicación realiza una solicitud a https://oauth2.googleapis.com/revoke
y, también, incluye el token como parámetro:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \ https://oauth2.googleapis.com/revoke?token={token}
El token puede ser un token de acceso o un token de actualización. Si el token es de acceso y tiene un token de actualización correspondiente, este también se revocará.
Si la revocación se procesa correctamente, el código de estado HTTP de la respuesta es 200
. Para las condiciones de error, se muestra un código de estado HTTP 400
junto con un código de error.
Material de lectura adicional
La IE 2.0 para las aplicaciones nativas de la práctica recomendada actual de IETF establece muchas de las prácticas recomendadas que se documentan aquí.