OAuth 2.0 para aplicaciones móviles y de escritorio

Nota: si es nuevo en OAuth 2.0, le recomendamos que lea la descripción general de OAuth 2.0 antes de comenzar. La descripción general resume los flujos de OAuth 2.0 compatibles con Google, lo que puede ayudarlo a asegurarse de haber seleccionado el flujo correcto para su aplicación.

Este documento explica cómo las aplicaciones instaladas en dispositivos como teléfonos, tabletas y computadoras usan los puntos finales de 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 manteniendo la privacidad de sus nombres de usuario, contraseñas y otra información. Por ejemplo, una aplicación puede usar OAuth 2.0 para obtener permiso de los usuarios para almacenar archivos en sus Google Drive.

Las aplicaciones instaladas se distribuyen a dispositivos individuales y se supone que estas aplicaciones no pueden guardar secretos. Pueden acceder a las API de Google mientras el usuario está presente en la aplicación o cuando la aplicación se ejecuta en segundo plano.

Este flujo de autorización es similar al utilizado para aplicaciones de servidor web . La principal diferencia es que las aplicaciones instaladas deben abrir el navegador del sistema y proporcionar un URI de redireccionamiento local para manejar las respuestas del servidor de autorización de Google.

Alternativas

Para las aplicaciones móviles, es posible que prefiera utilizar Google Sign-in para Android o iOS . Las bibliotecas de cliente de inicio de sesión de Google manejan la autenticación y la autorización del usuario, y pueden ser más sencillas de implementar que el protocolo de nivel inferior que se describe aquí.

Para las aplicaciones que se ejecutan en dispositivos que no admiten un navegador de sistema o que tienen capacidades de entrada limitadas, como televisores, consolas de juegos, cámaras o impresoras, consulte OAuth 2.0 para televisores y dispositivos o Iniciar sesión en televisores y dispositivos de entrada limitada .

Bibliotecas y muestras

Recomendamos las siguientes bibliotecas y ejemplos para ayudarlo a implementar el flujo de OAuth 2.0 descrito en este documento:

• AppAuth para la biblioteca de Android
• AppAuth para la biblioteca de iOS
• OAuth para aplicaciones: muestras de Windows

requisitos previos

Habilite las API para su proyecto

Cualquier aplicación que llame a las API de Google debe habilitar esas API en API Console.

Para habilitar una API para su proyecto:

1. Open the API Library en Google API Console.
2. If prompted, select a project, or create a new one.
3. El API Library enumera todas las API disponibles, agrupadas por familia de productos y popularidad. Si la API que desea habilitar no está visible en la lista, use la búsqueda para encontrarla o haga clic en Ver todo en la familia de productos a la que pertenece.
4. Seleccione la API que desea habilitar, luego haga clic en el botón Habilitar .
5. If prompted, enable billing.
6. If prompted, read and accept the API's Terms of Service.

Crear 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 en el servidor OAuth 2.0 de Google. Los siguientes pasos explican cómo crear credenciales para su proyecto. Luego, sus aplicaciones pueden usar las credenciales para acceder a las API que ha habilitado para ese proyecto.

1. Go to the Credentials page.
2. Haga clic en Crear credenciales > ID de cliente de OAuth .
3. Las siguientes secciones describen los tipos de clientes y los métodos de redirección que admite el servidor de autorización de Google. Elija el tipo de cliente que se recomienda para su aplicación, asigne un nombre a su cliente OAuth y configure los demás campos del formulario según corresponda.

Esquema de URI personalizado (Android, iOS, UWP)

Se recomienda un esquema de URI personalizado para las aplicaciones de Android, las aplicaciones de iOS y las aplicaciones de la Plataforma universal de Windows (UWP).

Androide

1. Seleccione el tipo de aplicación de Android .
2. Introduzca un nombre para el cliente de OAuth. Este nombre se muestra en el Credentials page de su proyecto para identificar al cliente.
3. Ingrese el nombre del paquete de su aplicación de Android. Este valor se define en el atributo del package del elemento <manifest> en el archivo de manifiesto de su aplicación.
4. Ingrese la huella digital del certificado de firma SHA-1 de la distribución de la aplicación.
   • Si su aplicación utiliza la firma de aplicaciones de Google Play , copie la huella digital SHA-1 de la página de firma de aplicaciones de Play Console.
   • Si administra su propio almacén de claves y claves de firma, use la utilidad keytool incluida con Java para imprimir la información del certificado en un formato legible por humanos. Copie el valor SHA1 en la sección Huellas Certificate fingerprints de la salida de keytool . Consulte Autenticación de su cliente en la documentación de las API de Google para Android para obtener más información.
5. Haz clic en Crear .

iOS

1. Seleccione el tipo de aplicación de iOS .
2. Introduzca un nombre para el cliente de OAuth. Este nombre se muestra en el Credentials page de su proyecto para identificar al cliente.
3. Ingrese el identificador de paquete para su aplicación. 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 su aplicación ( info.plist ). El valor suele mostrarse en el panel General o en el panel Firma y capacidades 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 aplicación para la aplicación en el sitio App Store Connect de Apple .
4. (Opcional)

   Ingrese la ID de la tienda de aplicaciones de su aplicación si la aplicación está publicada en la tienda de aplicaciones de Apple. El ID de la tienda es una cadena numérica incluida en cada URL de la tienda de aplicaciones de Apple.

   1. Abra la aplicación Apple App Store en su dispositivo iOS o iPadOS.
   2. Busca tu aplicación.
   3. Seleccione el botón Compartir (cuadrado y símbolo de flecha hacia arriba).
   4. Seleccione Copiar enlace .
   5. Pegue el enlace en un editor de texto. El ID de la App Store es la parte final de la URL.

      Ejemplo: https://apps.apple.com/app/google/id 284815942

5. (Opcional)

   Ingrese su ID de equipo. Consulte Localice su ID de equipo en la documentación de la cuenta de desarrollador de Apple para obtener más información.

6. Haz clic en Crear .

UWP

1. Seleccione el tipo de aplicación Plataforma universal de Windows .
2. Introduzca un nombre para el cliente de OAuth. Este nombre se muestra en el Credentials page de su proyecto para identificar al cliente.
3. Ingrese el ID de Microsoft Store de 12 caracteres de su aplicación. Puede encontrar este valor en el Centro de socios de Microsoft en la página de identidad de la aplicación en la sección Administración de la aplicación.
4. Haz clic en Crear .

Para las aplicaciones para UWP, el esquema de URI personalizado no puede tener más de 39 caracteres.

Nota: Consulte la definición del parámetro redirect_uri para obtener detalles sobre el formato del valor del esquema URI personalizado. Además, las bibliotecas y los ejemplos demuestran algunas implementaciones específicas de la plataforma de redireccionamientos de esquemas URI personalizados.

Dirección IP de bucle invertido (macOS, Linux, escritorio de Windows)

Para recibir el código de autorización mediante esta URL, su aplicación debe estar escuchando en el servidor web local. Eso es posible en muchas plataformas, pero no en todas. Sin embargo, si su plataforma lo admite, este es el mecanismo recomendado para obtener el código de autorización.

Cuando su aplicación recibe la respuesta de autorización, para una mejor usabilidad, debe responder mostrando una página HTML que le indica al usuario que cierre el navegador y regrese a su aplicación.

Uso recomendado	Aplicaciones de escritorio macOS, Linux y Windows (pero no Universal Windows Platform)
Valores de formulario	Establezca el tipo de aplicación en Aplicación de escritorio .

Nota: Consulte la definición del parámetro redirect_uri para obtener más información sobre la dirección IP de loopback. También es posible usar localhost en lugar de la IP de loopback, pero esta configuración puede causar problemas con los firewalls de los clientes. La mayoría de los cortafuegos, pero no todos, permiten la comunicación de bucle invertido.

Copiar/pegar manualmente

Importante: La opción de copiar/pegar manualmente, también conocida como método de redirección fuera de banda (OOB), está DESAPROBADA . Puede considerar un esquema de URI personalizado o una dirección IP de bucle invertido como formas más confiables, seguras y fáciles de usar para obtener la autorización del usuario.

Identificar ámbitos de acceso

Los ámbitos permiten que su aplicación solo solicite acceso a los recursos que necesita, al mismo tiempo que permite a los usuarios controlar la cantidad de acceso que otorgan a su aplicación. Por lo tanto, puede haber una relación inversa entre el número de alcances solicitados y la probabilidad de obtener el consentimiento del usuario.

Antes de comenzar a implementar la autorización de OAuth 2.0, le recomendamos que identifique los ámbitos a los que su aplicación necesitará permiso para acceder.

Nota: La autorización incremental no es compatible con aplicaciones o dispositivos instalados.

El documento Ámbitos de la API de OAuth 2.0 contiene una lista completa de los ámbitos que puede utilizar para acceder a las API de Google.

Si su aplicación pública utiliza ámbitos que permiten el acceso a ciertos datos de usuario, debe completar un proceso de verificación. Si ve una aplicación no verificada en la pantalla cuando prueba su aplicación, debe enviar una solicitud de verificación para eliminarla. Obtenga más información sobre las aplicaciones no verificadas y obtenga respuestas a las preguntas frecuentes sobre la verificación de aplicaciones en el Centro de ayuda.

Obtención de tokens de acceso OAuth 2.0

Los siguientes pasos muestran cómo su aplicación interactúa con el servidor OAuth 2.0 de Google para obtener el consentimiento de un usuario para realizar una solicitud de API en su nombre. Su aplicación debe tener ese consentimiento antes de poder ejecutar una solicitud de la API de Google que requiera la autorización del usuario.

Paso 1: generar un verificador de código y un desafío

Google admite el protocolo Proof Key for Code Exchange (PKCE) para que la aplicación instalada fluya de forma más segura. 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.

Crear el verificador de código

Un code_verifier de código es una cadena aleatoria criptográfica de alta entropía que utiliza los caracteres no reservados [AZ] / [az] / [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 suficiente entropía 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 del código es el hash SHA256 codificado en Base64URL (sin relleno) del verificador de código. code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
plano	El desafío del código tiene el mismo valor que el verificador de código generado anteriormente. code_challenge = code_verifier

Paso 2: envíe una solicitud al servidor OAuth 2.0 de Google

Para obtener la autorización del usuario, envíe una solicitud al servidor de autorización de Google en https://accounts.google.com/o/oauth2/v2/auth . Este punto final maneja la búsqueda de sesiones activas, autentica al usuario y obtiene el consentimiento del usuario. Solo se puede acceder al punto final a través de SSL y rechaza las conexiones HTTP (no SSL).

El servidor de autorización admite los siguientes parámetros de cadena de consulta para las aplicaciones instaladas:

Parámetros
client_id	Requerido El ID de cliente para su aplicación. Puede encontrar este valor en API ConsoleCredentials page.
redirect_uri	Requerido Determina cómo el servidor de autorización de Google envía una respuesta a su aplicación. Hay varias opciones de redirección disponibles para las aplicaciones instaladas, y habrá configurado sus credenciales de autorización con un método de redirección particular en mente. El valor debe coincidir exactamente con uno de los URI de redirección autorizados para el cliente OAuth 2.0, que configuró en el API ConsoleCredentials pagede su cliente. Si este valor no coincide con un URI autorizado, obtendrá un error redirect_uri_mismatch . La siguiente tabla muestra el valor del parámetro redirect_uri apropiado para cada método: valores redirect_uri Esquema de URI personalizado com.example.app : redirect_uri_path o com.googleusercontent.apps.123 : redirect_uri_path com.example.app es la notación DNS inversa de un dominio bajo su control. El esquema personalizado debe contener un período para ser válido. com.googleusercontent.apps.123 es la notación DNS inversa del ID de cliente. redirect_uri_path es un componente de ruta opcional, como /oauth2redirect . Tenga en cuenta que la ruta debe comenzar con una sola barra, que es diferente de las URL HTTP normales. Dirección IP de bucle invertido http://127.0.0.1: port o http://[::1]: port Consulte su plataforma para obtener la dirección IP de loopback relevante e inicie una escucha HTTP en un puerto disponible al azar. Sustituya el port con el número de puerto real en el que escucha su aplicación.
response_type	Requerido Determina si el extremo de Google OAuth 2.0 devuelve un código de autorización. Establezca el valor del parámetro en code para las aplicaciones instaladas.
scope	Requerido Una lista delimitada por espacios de ámbitos que identifican los recursos a los que su aplicación podría acceder en nombre del usuario. Estos valores informan la pantalla de consentimiento que Google muestra al usuario. Los ámbitos permiten que su aplicación solo solicite acceso a los recursos que necesita, al mismo tiempo que permite a los usuarios controlar la cantidad de acceso que otorgan a su aplicación. Por lo tanto, existe una relación inversa entre el número de alcances solicitados y la probabilidad de obtener el consentimiento del usuario.
code_challenge	Recomendado Especifica un code_verifier codificado que se usará como un desafío del lado del servidor durante el intercambio de códigos de autorización. Consulte la sección Crear desafío de código anterior para obtener más información.
code_challenge_method	Recomendado Especifica qué método se utilizó para codificar un code_verifier que se utilizará durante el intercambio de códigos de autorización. Este parámetro debe usarse con el parámetro code_challenge descrito anteriormente. El valor de code_challenge_method por defecto es plain si no está presente en la solicitud que incluye un code_challenge . Los únicos valores admitidos para este parámetro son S256 o plain .
state	Recomendado Especifica cualquier valor de cadena que use su aplicación para mantener el estado entre su solicitud de autorización y la respuesta del servidor de autorización. El servidor devuelve el valor exacto que envía como un par name=value en el identificador de fragmento de URL ( # ) de redirect_uri después de que el usuario acepta o deniega la solicitud de acceso de su aplicación. Puede usar este parámetro para varios propósitos, como dirigir al usuario al recurso correcto en su aplicación, enviar nonces y mitigar la falsificación de solicitudes entre sitios. Dado que se puede adivinar su redirect_uri , el uso de un valor de state puede aumentar su seguridad de que una conexión entrante es el resultado de una solicitud de autenticación. Si genera una cadena aleatoria o codifica el hash de una cookie u otro valor que captura el estado del cliente, puede validar la respuesta para garantizar además que la solicitud y la respuesta se originaron en el mismo navegador, brindando protección contra ataques como cross-site. solicitar falsificación. Consulte la documentación de OpenID Connect para ver un ejemplo de cómo crear y confirmar un token de state .
login_hint	Opcional Si su aplicación sabe qué usuario está tratando de autenticarse, puede usar este parámetro para proporcionar una pista al servidor de autenticación de Google. El servidor utiliza la sugerencia para simplificar el flujo de inicio de sesión, ya sea rellenando previamente el campo de correo electrónico en el formulario de inicio de sesión o seleccionando la sesión de inicio de sesión múltiple adecuada. Establezca el valor del parámetro en una dirección de correo electrónico o sub , que es equivalente al ID de Google del usuario.

Nota: no se admite la autorización incremental con aplicaciones instaladas debido a que el cliente no puede mantener la confidencialidad de client_secret .

Ejemplos de URL de autorización

Las pestañas a continuación muestran ejemplos de URL de autorización para las diferentes opciones de URI de redirección.

Las URL son idénticas excepto por el valor del parámetro redirect_uri . Las direcciones URL también contienen los parámetros de tipo de response_type y de client_id de cliente necesarios, así como el parámetro de state opcional. 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=email%20profile&
 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=email%20profile&
 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 al usuario su consentimiento

En este paso, el usuario decide si otorga a su aplicación el acceso solicitado. En esta etapa, Google muestra una ventana de consentimiento que muestra el nombre de su aplicación y los servicios de API de Google a los que solicita permiso para acceder con las credenciales de autorización del usuario y un resumen de los alcances de acceso que se otorgarán. Luego, el usuario puede dar su consentimiento para otorgar acceso a uno o más ámbitos solicitados por su aplicación o rechazar la solicitud.

Su aplicación no necesita hacer nada en esta etapa, ya que espera la respuesta del servidor OAuth 2.0 de Google que indica si se otorgó algún 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 para el usuario en lugar de los flujos de autenticación y autorización esperados. Los códigos de error comunes y las soluciones sugeridas se enumeran a continuación.

admin_policy_enforced

La cuenta de Google no puede autorizar uno o más ámbitos solicitados debido a las políticas de su administrador de Google Workspace. Consulte el artículo de ayuda para administradores de Google Workspace Controlar qué aplicaciones 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 ámbitos o ámbitos confidenciales y restringidos hasta que se otorgue acceso de forma explícita a su ID de cliente de OAuth.

disallowed_useragent

El punto final de autorización se muestra dentro de un agente de usuario incrustado no permitido por las Políticas de OAuth 2.0 de Google.

Androide

Los desarrolladores de Android pueden encontrar este mensaje de error al abrir solicitudes de autorización enandroid.webkit.WebView . En su lugar, los desarrolladores deberían usar bibliotecas de Android como Google Sign-In para Android o AppAuth de OpenID Foundation para Android .

Los desarrolladores web pueden encontrar este error cuando una aplicación de Android abre un enlace web general en un agente de usuario integrado y un usuario navega al punto final de autorización de OAuth 2.0 de Google desde su sitio. Los desarrolladores deben permitir que los enlaces generales se abran en el controlador de enlaces predeterminado del sistema operativo, que incluye los controladores de enlaces de aplicaciones de Android o la aplicación de navegador predeterminada. La biblioteca de pestañas personalizadas de Android también es una opción compatible.

iOS

Los desarrolladores de iOS y macOS pueden encontrar este error al abrir solicitudes de autorización enWKWebView . En su lugar, los desarrolladores deberían usar bibliotecas de iOS como Google Sign-In para iOS o AppAuth de OpenID Foundation para iOS .

Los desarrolladores web pueden encontrar este error cuando una aplicación de iOS o macOS abre un enlace web general en un agente de usuario integrado y un usuario navega al punto final de autorización de OAuth 2.0 de Google desde su sitio. Los desarrolladores deben permitir que los enlaces generales se abran en el controlador de enlaces predeterminado del sistema operativo, que incluye los controladores de enlaces universales o la aplicación de navegador predeterminada. La bibliotecaSFSafariViewController también es una opción admitida.

org_internal

El ID de cliente de OAuth en la solicitud es parte de un proyecto que limita el acceso a las cuentas de Google en una organización específica de Google Cloud . Para obtener más información sobre esta opción de configuración, consulte la sección Tipo de usuario en el artículo de ayuda Configuración de la pantalla de consentimiento de OAuth.

redirect_uri_mismatch

El redirect_uri pasado en la solicitud de autorización no coincide con un URI de redirección autorizado para el ID de cliente de OAuth. Revise los URI de redirección autorizados en Google API Console Credentials page.

El redirect_uri pasado puede no ser válido para el tipo de cliente.

Paso 4: manejar la respuesta del servidor OAuth 2.0

La forma en que su aplicación recibe la respuesta de autorización depende del esquema de URI de redirección que utiliza. Independientemente del 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 su aplicación, puede 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: intercambie el código de autorización para actualizar y acceder a tokens

Para intercambiar un código de autorización por un token de acceso, llame al extremo https://oauth2.googleapis.com/token y configure los siguientes parámetros:

Los campos
client_id	El ID de cliente obtenido de API ConsoleCredentials page.
client_secret	El secreto del cliente obtenido del API ConsoleCredentials page.
code	El código de autorización devuelto de la solicitud inicial.
code_verifier	El verificador de código que creó en el Paso 1 .
grant_type	Tal como se define en la especificación OAuth 2.0 , el valor de este campo debe establecerse authorization_code .
redirect_uri	Uno de los URI de redirección enumerados para su proyecto en API ConsoleCredentials page para el client_id dado.

El siguiente fragmento 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%3A//127.0.0.1%3A9004&
grant_type=authorization_code

Google responde a esta solicitud devolviendo 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:

Los campos
access_token	El token que tu aplicación envía para autorizar una solicitud de API de Google.
expires_in	La vida útil restante del token de acceso en segundos.
id_token	Nota: esta propiedad solo se devuelve si su solicitud incluye un ámbito de identidad, como openid , profile o email . El valor es un token web JSON (JWT) que contiene información de identidad firmada digitalmente sobre el usuario.
refresh_token	Un token que puede usar para obtener un nuevo token de acceso. Los tokens de actualización son válidos hasta que el usuario revoque el acceso. Tenga en cuenta que los tokens de actualización siempre se devuelven para las aplicaciones instaladas.
scope	Los ámbitos de acceso otorgados por access_token expresados ​​como una lista de cadenas delimitadas por espacios que distinguen entre mayúsculas y minúsculas.
token_type	El tipo de token devuelto. En este momento, el valor de este campo siempre se establece en Bearer .

Importante: su aplicación debe almacenar ambos tokens en una ubicación segura y de larga duración a la que se pueda acceder entre diferentes invocaciones de su aplicación. El token de actualización permite que su aplicación obtenga un nuevo token de acceso si el que tiene caduca. Como tal, si su aplicación pierde el token de actualización, el usuario deberá repetir el flujo de consentimiento de OAuth 2.0 para que su aplicación pueda obtener un nuevo token de actualización.

El siguiente fragmento 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"
}

Nota: Su aplicación debe ignorar cualquier campo no reconocido incluido en la respuesta.

Llamar a las API de Google

Después de que su aplicación obtenga un token de acceso, puede utilizar el token para realizar llamadas a una API de Google en nombre de una cuenta de usuario determinada si se han otorgado los alcances de acceso requeridos por la API. Para hacer esto, incluya el token de acceso en una solicitud a la API incluyendo un parámetro de consulta access_token o un valor de Bearer de encabezado HTTP de Authorization . Cuando sea posible, es preferible el encabezado HTTP, porque las cadenas de consulta tienden a ser visibles en los registros del servidor. En la mayoría de los casos, puede usar una biblioteca cliente para configurar sus llamadas a las API de Google (por ejemplo, al llamar a la API de archivos de Drive ).

Puede probar todas las API de Google y ver sus alcances en OAuth 2.0 Playground .

Ejemplos HTTP GET

Una llamada al extremo de drive.files (la API de Drive Files) mediante el encabezado HTTP Authorization: Bearer podría tener el siguiente aspecto. Tenga en cuenta que debe especificar su propio token de acceso:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Aquí hay una llamada a la misma API para el usuario autenticado usando el parámetro de cadena de consulta access_token :

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

ejemplos curl

Puede probar estos comandos con la aplicación de línea de comandos curl . Aquí hay un ejemplo que usa la opción de encabezado HTTP (preferido):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

O, alternativamente, la opción de parámetro de cadena de consulta:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Actualizar 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. Puede actualizar un token de acceso sin solicitar permiso al usuario (incluso cuando el usuario no está presente) si solicitó acceso sin conexión a los ámbitos asociados con el token.

Para actualizar un token de acceso, su aplicación envía una solicitud HTTPS POST al servidor de autorización de Google ( https://oauth2.googleapis.com/token ) que incluye los siguientes parámetros:

Los campos
client_id	El ID de cliente obtenido de API Console.
client_secret	El secreto del cliente obtenido del API Console. (El client_secret no se aplica a solicitudes de clientes registrados como aplicaciones de Android, iOS o Chrome).
grant_type	Tal 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 devuelto del intercambio de código de autorización.

El siguiente fragmento 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 devuelve un objeto JSON que contiene un nuevo token de acceso. El siguiente fragmento muestra una respuesta de muestra:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

Tenga en cuenta que hay límites en la cantidad de tokens de actualización que se emitirán; un límite por combinación de cliente/usuario y otro por usuario en todos los clientes. Debe guardar tokens de actualización en el almacenamiento a largo plazo y continuar usándolos mientras sigan siendo válidos. Si su aplicación solicita demasiados tokens de actualización, es posible que alcance estos límites, en cuyo caso los tokens de actualización más antiguos dejarán de funcionar.

Revocación de un token

En algunos casos, un usuario puede desear revocar el acceso otorgado a una aplicación. Un usuario puede revocar el acceso visitando Configuración de la cuenta . Consulte la sección Eliminar el acceso a sitios o aplicaciones del documento de soporte Sitios y aplicaciones de terceros con acceso a su cuenta para obtener más información.

También es posible que una aplicación revoque mediante programación el acceso que se le ha otorgado. La revocación programática es importante en los casos en que un usuario cancela su suscripción, elimina una aplicación o los recursos de API requeridos por una aplicación han cambiado significativamente. En otras palabras, parte del proceso de eliminación puede incluir una solicitud de API para garantizar que se eliminen los permisos otorgados previamente a la aplicación.

Para revocar un token mediante programación, su aplicación realiza una solicitud a https://oauth2.googleapis.com/revoke e 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 un token de acceso y tiene un token de actualización correspondiente, el token de actualización también se revocará.

Si la revocación se procesa correctamente, el código de estado HTTP de la respuesta es 200 . Para condiciones de error, se devuelve un código de estado HTTP 400 junto con un código de error.

Nota: Después de una respuesta de revocación exitosa, puede pasar algún tiempo antes de que la revocación tenga pleno efecto.

Otras lecturas

Las mejores prácticas actuales de IETF OAuth 2.0 para aplicaciones nativas establecen muchas de las mejores prácticas documentadas aquí.