OAuth 2.0 para aplicaciones móviles y de escritorio

Este documento explica cómo las aplicaciones instaladas en dispositivos como teléfonos, tabletas y computadoras utilizan los puntos finales 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 mientras mantienen privados 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 Drives.

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 está ejecutando en segundo plano.

Este flujo de autorización es similar a la utilizada 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 aplicaciones móviles, es posible que prefiera utilizar acceso de Google para Android o iOS . Las bibliotecas cliente de Google Sign-in 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 aplicaciones que se ejecutan en dispositivos que no soportan un navegador de sistema o que han limitado las capacidades de entrada, tales como televisores, consolas de juegos, cámaras, impresoras o, consulta OAuth 2.0 para TV y dispositivos o acceso de Google para los dispositivos .

Bibliotecas y muestras

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

Prerrequisitos

Habilite las API para su proyecto

Cualquier aplicación que llama a las API de Google necesita para que estas APIs en la API Console.

Para habilitar una API para su proyecto:

  1. Open the API Library en el Google API Console.
  2. If prompted, select a project, or create a new one.
  3. El API Library listas de todas las APIs disponibles, agrupados por familias de productos y popularidad. Si la API desea activar no es visible en la lista, el uso de búsqueda para encontrarlo, o haga clic en Ver todos en la familia de productos al que pertenece.
  4. Seleccione la API que desea activar, a continuación, haga clic en el botón de activación.
  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 utilice 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 haya habilitado para ese proyecto.

  1. Go to the Credentials page.
  2. Haga clic en Crear credenciales> OAuth ID de cliente.
  3. Las secciones siguientes describen los tipos de clientes y los métodos de redireccionamiento 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 otros campos en el formulario según corresponda.

Esquema de URI personalizado (Android, iOS, UWP)

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

Androide
  1. Seleccione el tipo de aplicaciones para Android.
  2. Ingrese un nombre para el cliente OAuth. Este nombre se muestra en su proyecto de Credentials page para identificar al cliente.
  3. Ingrese el nombre del paquete de su aplicación de Android. Este valor se define en elpackage atributo de la <manifest> elemento en el archivo de manifiesto de la aplicación.
  4. Ingrese la huella digital del certificado de firma SHA-1 de la distribución de la aplicación.
    • Si sus usos de aplicaciones APP firmar por Google Play , copiar la huella digital SHA-1 de la página de la aplicación de firma de la Consola de Google Play.
    • Si usted maneja sus propias claves y almacén de claves de firma, utilizar la utilidad herramienta de claves incluido con Java para imprimir la información del certificado en un formato legible por humanos. Copiar el SHA1 valor en el Certificate fingerprints la sección de la salida herramienta de claves. Ver la autenticación de su cliente en el API de Google Android para la documentación para obtener más información.
  5. Haga clic en Crear.
iOS
  1. Seleccionar el tipo de aplicación iOS.
  2. Ingrese un nombre para el cliente OAuth. Este nombre se muestra en su proyecto de Credentials page para identificar al cliente.
  3. Ingrese el identificador de paquete para su aplicación. El ID de paquete es el valor de la CFBundleIdentifier clave en el archivo de lista de recursos de propiedad información de su aplicación (info.plist). El valor se muestra más comúnmente en el panel General o en el panel Firma y capacidades del editor de proyectos de Xcode. El ID de paquete también se muestra en la sección de Información General de la página Información de la aplicación para la aplicación en el sitio tienda de aplicaciones de Apple Conectar .
  4. (Opcional)

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

    1. Abra la aplicación App Store de Apple en el dispositivo iOS o iPadOS.
    2. Busque su aplicación.
    3. Seleccione el botón Compartir (símbolo cuadrado y flecha hacia arriba).
    4. Seleccione Copiar vínculo.
    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. Ver localice a su equipo de identificación en la documentación de cuenta de Apple Developer para más información.

  6. Haga clic en Crear.
UWP
  1. Seleccionar el tipo de aplicación universal plataforma Windows.
  2. Ingrese un nombre para el cliente OAuth. Este nombre se muestra en su proyecto de Credentials page para identificar al cliente.
  3. Ingrese el ID de Microsoft Store de 12 caracteres de su aplicación. Puede encontrar este valor en Microsoft Partner Center sobre la identidad de la aplicación de página en la sección Administración de aplicaciones.
  4. Haga clic en Crear.

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

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

Para recibir el código de autorización usando 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 indique al usuario que cierre el navegador y regrese a su aplicación.

Uso recomendado Aplicaciones de escritorio de macOS, Linux y Windows (pero no de la Plataforma universal de Windows)
Valores de formulario Establecer el tipo de aplicación a aplicación de escritorio.

Copiar / pegar manualmente

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 OAuth 2.0, le recomendamos que identifique los ámbitos a los que su aplicación necesitará permiso para acceder.

El Scopes 2.0 API de OAuth documento contiene una lista completa de los alcances que puede utilizar el acceso a las API de Google.

Obtención de tokens de acceso de 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 del usuario para realizar una solicitud de API en su nombre. Su aplicación debe tener ese consentimiento antes de poder ejecutar una solicitud de API de Google que requiere la autorización del usuario.

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

Google apoya la clave de prueba para Exchange Código (PKCe) de protocolo para hacer que el flujo de aplicación instalada 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 cadena aleatoria de cifrado de alta entropía utilizando 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)))
sencillo El desafío de 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, enviar 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).

Authorization Server admite los siguientes parámetros de cadena de consulta para las aplicaciones instaladas:

Parámetros
client_id Requerido

El ID de cliente de su aplicación. Puede encontrar este valor en el 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 disponibles de redirección a las aplicaciones instaladas, y que se han establecido sus credenciales de autorización con un método de redirección en particular en mente.

El valor debe coincidir exactamente con uno de los URI de redireccionamiento de redirección autorizados para el cliente de OAuth 2.0, que configuró en el de su cliente API ConsoleCredentials page. Si este valor no coincide con una URI autorizado, obtendrá un redirect_uri_mismatch error.

La siguiente tabla muestra el apropiado redirect_uri valor de parámetro para cada método:

redirect_uri valores
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 inversa de DNS 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 de DNS inversa de la ID de cliente.
  • redirect_uri_path es un componente de la ruta opcional, tal 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 en su plataforma la dirección IP de loopback relevante e inicie un oyente HTTP en un puerto disponible aleatorio. Sustituto de port con el número de puerto real de su aplicación escucha en.

Copiar / pegar manualmente urn:ietf:wg:oauth:2.0:oob
Extracción programática urn:ietf:wg:oauth:2.0:oob:auto
response_type Requerido

Determina si el extremo de Google OAuth 2.0 devuelve un código de autorización.

Establecer el valor del parámetro de code para las aplicaciones instaladas.

scope Requerido

Una lista de ámbitos delimitada por espacios que identifica 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 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 una codificada code_verifier que se utilizará como un desafío del lado del servidor durante el intercambio de código de autorización. Ver comprobación del código de crear la sección anterior para obtener más información.

code_challenge_method Recomendado

Especifica qué método se utilizó para codificar una code_verifier que se utilizará durante el intercambio de código de autorización. Este parámetro debe ser utilizado con el code_challenge parámetro descrito anteriormente. El valor de los code_challenge_method defecto plain si no está presente en la solicitud que incluye una code_challenge . Los valores solamente soportados para este parámetro son S256 o plain .

state Recomendado

Especifica cualquier valor de cadena que utiliza 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 se envía como un name=value par en el identificador de fragmento de URL ( # ) de la redirect_uri después el usuario consiente o deniega la solicitud de acceso de la 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. Debido a que su redirect_uri se puede adivinar, utilizando un state valor 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 asegurarse adicionalmente de que la solicitud y la respuesta se originaron en el mismo navegador, brindando protección contra ataques como sitios cruzados. Solicitar falsificación. Ver el OpenID Conectar la documentación para un ejemplo de cómo crear y confirmar un state token.

login_hint Opcional

Si su aplicación sabe qué usuario está intentando autenticarse, puede utilizar 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.

Establecer el valor del parámetro a una dirección de correo electrónico o sub identificador, lo que equivale a del usuario ID de Google.

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 redireccionamiento.

Las direcciones URL son idénticos excepto por el valor de la redirect_uri parámetro. Las direcciones URL también contienen la requerida response_type y client_id parámetros así como el opcional state parámetro. 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

Copiar pegar

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=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&
 client_id=client_id

Extracción programática

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=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
 client_id=client_id

Paso 3: Google solicita el consentimiento del usuario

En este paso, el usuario decide si concede 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 la 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 le 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 de cara al 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 alcances solicitados debido a las políticas de su administrador de Google Workspace. Ver el artículo de ayuda de Google espacio de trabajo de administración de control, que terceros y aplicaciones acceder a los datos internos Google espacio de trabajo para obtener más información acerca de cómo un administrador puede restringir el acceso a todos los ámbitos o ámbitos sensibles y restringidas hasta que el acceso se concede explícitamente a su ID de cliente de OAuth.

disallowed_useragent

El criterio de valoración de autorización se muestra dentro de un agente de usuario incrustado anulado por el de Google OAuth 2.0 Políticas .

Androide

Los desarrolladores de Android pueden encontrarse con este mensaje de error al abrir solicitudes de autorización enandroid.webkit.WebView . Los desarrolladores deben utilizar en lugar bibliotecas Android, tales como acceso de Google para Android o de OpenID Fundación AppAuth 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 extremo de autorización OAuth 2.0 de Google desde su sitio. Los desarrolladores deben permitir enlaces generales se abran en el controlador de enlace por defecto del sistema operativo, que incluye tanto Android App Links manipuladores o la aplicación del navegador por defecto. El androide de encargo aquí biblioteca es también una opción compatible.

iOS

IOS y MacOS desarrolladores pueden encontrar este error al abrir solicitudes de autorización enWKWebView . Los desarrolladores deben utilizar en lugar bibliotecas iOS tales como acceso de Google para iOS o de OpenID Fundación AppAuth para iOS .

Los desarrolladores web pueden encontrar este error cuando una aplicación iOS o macOS abre un enlace web general en un agente de usuario integrado y un usuario navega al extremo de autorización OAuth 2.0 de Google desde su sitio. Los desarrolladores deben permitir enlaces generales se abran en el controlador de enlace por defecto del sistema operativo, que incluye tanto universal Enlaces manipuladores o la aplicación del navegador por defecto. ElSFSafariViewController biblioteca es también una opción compatible.

org_internal

El ID de cliente de OAuth en la petición es parte de un proyecto que limita el acceso a las cuentas de Google en una determinada organización de Google Cloud . Para obtener más información acerca de esta opción de configuración ver el tipo de usuario sección en el Puesta a punto del consentimiento de OAuth artículo de ayuda de la pantalla.

redirect_uri_mismatch

El redirect_uri aprobada en la solicitud de autorización no coincide con una redirección autorizado URI para el ID de cliente de OAuth. Opinión autorizada URI de redirección en el Google API Console Credentials page.

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

Paso 4: Manejar la respuesta del servidor OAuth 2.0

La manera en que su aplicación recibe la respuesta de autorización depende del esquema URI de redireccionamiento que utiliza. Independientemente del esquema, la respuesta contendrá ya sea un código de autorización ( code ) o un error ( error ). Por ejemplo, error=access_denied indica que el usuario se negó la solicitud.

Si el usuario otorga acceso a su aplicación, puede cambiar 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: Código de autorización de intercambio para tokens de acceso y actualización

Para cambiar un código de autorización para un token de acceso, llame al https://oauth2.googleapis.com/token punto final y ajustar los siguientes parámetros:

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

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=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
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 envía su aplicación 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 sólo se devuelve si su solicitud incluye un alcance de identidad, tales como openid , profile , o email . El valor es un JSON Web Token (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 revoca el acceso. Tenga en cuenta que los tokens de actualización siempre se devuelven para las aplicaciones instaladas.
scope Los alcances de acceso concedidos por el access_token expresada como una lista de cadenas delimitados por espacios, 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 .

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

Llamar a las API de Google

Una vez que su aplicación obtiene un token de acceso, puede usar 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 ello, incluya el acceso de ficha en una solicitud a la API mediante la inclusión de un bien access_token parámetro de consulta o un Authorization cabecera HTTP Bearer valor. Cuando es 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 se puede utilizar una biblioteca de cliente para configurar sus llamadas a las API de Google (por ejemplo, al llamar a la API de archivos de la unidad ).

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

Ejemplos de HTTP GET

Una llamada a la drive.files punto final (la API de archivos de la unidad) utilizando la Authorization: Bearer cabecera HTTP podría parecerse a lo siguiente. 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í es una llamada a la misma API para el usuario autenticado mediante el access_token parámetro de cadena de consulta:

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

curl ejemplos

Puede probar estos comandos con el curl la aplicación de línea de comandos. 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 pedir 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, la aplicación envía un HTTPS POST petición 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 obtiene de la API Console.
client_secret El secreto del cliente obtenida de la API Console. (El client_secret no es aplicable a las solicitudes de los clientes registrados como Android, iOS o aplicaciones de Chrome.)
grant_type Como se define en la especificación OAuth 2.0 , el valor de este campo se debe establecer en refresh_token .
refresh_token El token de actualización devuelto por el intercambio de códigos 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 existen 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 los tokens de actualización en un almacenamiento a largo plazo y continuar usándolos mientras sigan siendo válidos. Si su aplicación solicita demasiados tokens de actualización, puede encontrarse con estos límites, en cuyo caso los tokens de actualización más antiguos dejarán de funcionar.

Revocar una ficha

En algunos casos, un usuario puede desear revocar el acceso otorgado a una aplicación. Un usuario puede revocar el acceso al visitar Configuración de la cuenta . Vea la sección de acceso Retire el sitio o aplicación de los Sitios y aplicaciones de terceros con acceso a su cuenta documento de soporte para 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 mediante programación una ficha, la aplicación realiza una solicitud al 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, también se revocará el token de actualización.

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

Otras lecturas

El IETF Mejor práctica actual de OAuth 2.0 para aplicaciones nativas establece muchas de las mejores prácticas documentadas aquí.