OAuth 2.0 para apps de escritorio y dispositivos móviles

En este documento, se explica cómo las aplicaciones de escritorio (como las que se ejecutan en Windows, macOS o Linux, o las herramientas de interfaz de línea de comandos [CLI]) usan los extremos de OAuth 2.0 de Google para autorizar el acceso a la API de YouTube Data.

OAuth 2.0 permite que los usuarios compartan datos específicos con una aplicación y, al mismo tiempo, mantengan 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 y subir videos al canal de YouTube de un usuario.

Las aplicaciones de escritorio se instalan de forma local en la máquina de un usuario (como software de escritorio independiente, herramientas de CLI para desarrolladores, utilidades de sincronización en segundo plano o secuencias de comandos). Debido a que estas apps se distribuyen a dispositivos individuales, se supone que no pueden mantener secretos (son clientes públicos). Pueden acceder a las APIs de Google mientras el usuario interactúa de forma activa con la app o cuando esta 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 para computadoras deben abrir el navegador del sistema y proporcionar un URI de redireccionamiento local (como una dirección IP de bucle invertido) para controlar las respuestas del servidor de autorización de Google.

Bibliotecas y muestras

Te recomendamos que uses las bibliotecas cliente de la API de Google para tu lenguaje de programación (p.ej., Python, Java, Node.js, Go o .NET) cuando implementes OAuth 2.0 en aplicaciones para computadoras. Las bibliotecas cliente controlan la autorización de los usuarios y la administración de tokens, lo que hace que la implementación sea más sencilla y menos propensa a errores que usar directamente los extremos HTTP/REST de nivel inferior.

En el caso de las apps para dispositivos móviles, consulta las guías de autorización de Android y de iOS.

En el caso de 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 TVs y dispositivos o Acceso en TVs y dispositivos de entrada limitada.

Requisitos previos

Habilita las API para tu proyecto.

Cualquier aplicación que llame a las APIs de Google debe habilitar esas APIs en la Consola de APIs.

Para habilitar una API en tu proyecto, sigue estos pasos:

1. Abre la Biblioteca de APIs en la Consola de APIs de Google.
2. Si se te solicita, selecciona un proyecto o crea uno nuevo.
3. Usa la página Biblioteca para buscar y habilitar la API de YouTube Data. Busca cualquier otra API que usará tu aplicación y habilítala también.

Crea credenciales de autorización

Cualquier aplicación que use OAuth 2.0 para acceder a las APIs de Google debe tener credenciales de autorización que identifiquen la aplicación ante el servidor de 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 APIs que habilitaste para ese proyecto.

1. Ve a la página Clientes.
2. Haz clic en Crear cliente.
3. Selecciona el tipo de aplicación App para computadoras.
4. En el campo Nombre, ingresa un nombre para el cliente de OAuth. Este nombre se muestra en la página Clientes de tu proyecto para identificar al cliente.
5. Haz clic en Crear.

Tu ID de cliente y tu secreto de cliente se generan y se muestran en la consola de Google Cloud. Las apps para computadoras son clientes públicos y no pueden mantener los secretos confidenciales. Usa siempre PKCE (clave de prueba para el intercambio de código) cuando solicites códigos de autorización.

Identificar los permisos de acceso

Los permisos permiten que tu aplicación solo solicite acceso a los recursos que necesita y, al mismo tiempo, permiten que los usuarios controlen la cantidad de acceso que otorgan a tu aplicación. Por lo tanto, puede haber una relación inversa entre la cantidad de permisos solicitados y la probabilidad de obtener el consentimiento del usuario.

Antes de comenzar a implementar la autorización de OAuth 2.0, te recomendamos que identifiques los permisos a los que tu app necesitará acceder.

La API de YouTube Data v3 usa los siguientes permisos:

El documento Permisos de la API de OAuth 2.0 contiene una lista completa de los permisos que puedes usar para acceder a las APIs de Google.

Obtén tokens de acceso de OAuth 2.0

En los siguientes pasos, se muestra cómo interactúa tu aplicación con el servidor de OAuth 2.0 de Google para obtener el consentimiento de un usuario para realizar una solicitud a la API en su nombre. 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) para 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 cadena aleatoria 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 suficiente entropía para que sea imposible adivinar el valor.

Crea el desafío de código

Se admiten dos métodos para crear el desafío de código.

code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

code_challenge = code_verifier

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 de sesiones activas, autentica al usuario y obtiene su consentimiento. Solo se puede acceder al extremo a través de SSL y rechaza las conexiones HTTP (que no son SSL).

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

URLs de autorización de muestra

En las siguientes pestañas, se muestran URLs de autorización de ejemplo para las diferentes opciones de URI de redireccionamiento.

Las URLs son idénticas, excepto por el valor del parámetro redirect_uri. Las URLs también contienen los parámetros obligatorios response_type y client_id, así como el parámetro opcional state. Cada URL contiene saltos de línea y espacios para facilitar la lectura.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 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

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 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 otorgará a tu aplicación el acceso solicitado. En esta etapa, Google muestra una ventana de consentimiento con 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, además de un resumen de los permisos de acceso que se otorgarán. Luego, el usuario puede dar su consentimiento para otorgar acceso a uno o más permisos que solicita tu aplicación o rechazar la solicitud.

En esta etapa, tu aplicación no necesita hacer nada mientras espera la respuesta del servidor de OAuth 2.0 de Google que indica si se otorgó algún acceso. Esa respuesta se explica en el siguiente paso.

Paso 4: Controla la respuesta del servidor de OAuth 2.0

La forma en que tu aplicación recibe la respuesta de autorización depende del esquema de URI de redireccionamiento que use. 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 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 acceso y de actualización

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:

Si bien el uso de DPoP es opcional, se recomienda para aumentar la seguridad. La seguridad de DPoP se basa en que la clave privada esté restringida a un solo dispositivo. Recomendamos almacenarla de forma que no se pueda copiar fuera del dispositivo, por ejemplo, con TPM, Secure Enclaves o cualquier otro almacén de claves respaldado por hardware. Para usar DPoP, tu aplicación debe generar un JWT de prueba de DPoP nuevo y único para cada solicitud al extremo del token y agregarlo como un encabezado de la solicitud HTTP.

En el siguiente fragmento, se muestra una solicitud de ejemplo:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Crea una prueba de DPoP

En los siguientes pasos, se muestra cómo construir una prueba de DPoP con OpenSSL desde la línea de comandos:

1. Genera un par de claves EC P-256:

   openssl ecparam -name prime256v1 -genkey -noout -out dpop_private.pem
   openssl ec -in dpop_private.pem -pubout -out dpop_public.pem

2. Crea el encabezado de DPoP:

   El encabezado debe incluir las reclamaciones typ, alg y jwk (clave pública). Los valores x y y son las coordenadas codificadas en Base64Url de tu clave pública de EC. Codifica este JSON en Base64Url:

   {
     "typ":"dpop+jwt",
     "alg":"ES256",
     "jwk": {
       "kty":"EC",
       "x":"YOUR_PUBLIC_KEY_X",
       "y":"YOUR_PUBLIC_KEY_Y",
       "crv":"P-256"
     }
   }

3. Crea la carga útil de DPoP:

   La carga útil debe incluir jti (un identificador único para la solicitud), htm (método HTTP, p.ej., POST), htu (URI HTTP, p.ej., https://oauth2.googleapis.com/token) y iat (hora de emisión). Si recibiste un nonce del servidor en un encabezado DPoP-Nonce en la respuesta a una solicitud anterior, debes incluir ese valor de nonce en una reclamación nonce. La reclamación nonce es opcional para los intercambios de código de autorización y solo se usa cuando se recibió previamente el encabezado DPoP-Nonce. Codifica este JSON en Base64Url:

   {
     "jti":"JTI_VALUE",
     "htm":"POST",
     "htu":"https://oauth2.googleapis.com/token",
     "iat":YOUR_JWT_ISSUED_TIME,
     "nonce":"SERVER_PROVIDED_NONCE"
   }

   El valor de jti depende del tipo de intercambio:

   • Para los intercambios de códigos de autorización, el jti debe ser el hash SHA256 codificado en Base64Url del código de autorización: "jti":"BASE64URL(SHA256(AUTHORIZATION_CODE))".
   • Para los intercambios de tokens de actualización, el jti debe ser un identificador único por solicitud: "jti":"YOUR_UNIQUE_PER_REQUEST_IDENTIFIER".
4. Firma la prueba:

   Concatena el encabezado y la carga útil codificados con un punto (.) y, luego, firma el resultado con tu clave privada usando ES256. Ten en cuenta que JWS requiere que la firma esté en un formato sin procesar concatenado R | S (64 bytes para P-256). Si usas OpenSSL directamente, debes convertir la firma predeterminada codificada en DER ASN.1 a este formato sin procesar.

Un intercambio exitoso se indica con una respuesta 200 OK que contiene los tokens. Si se usa una prueba de DPoP válida durante el intercambio, el token de actualización que devuelve Google estará vinculado a tu clave con DPoP, pero los tokens de acceso no estarán vinculados con DPoP. Los tokens de acceso conservarán el token_type de Bearer en lugar de DPoP. Además, Google devuelve un encabezado HTTP DPoP-Nonce en la respuesta. Tu cliente debe almacenar en caché este nonce y, luego, incluirlo en la reclamación nonce de la prueba de DPoP en las solicitudes posteriores (como cuando se intercambia un token de actualización por un token de acceso nuevo o cuando se llaman a las APIs protegidas por DPoP). Si usas este nonce emitido con anticipación, puedes evitar una falla adicional de ida y vuelta (use_dpop_nonce) en tu próxima solicitud.

Se deben incluir pruebas de DPoP para las solicitudes de intercambio de tokens que se realicen con tokens de actualización vinculados a DPoP.

Se produce un intercambio fallido si falta el encabezado DPoP cuando se espera, no es válido o si la prueba usa una clave diferente de la vinculada al token. En estos casos, el servidor devuelve un error 400 Bad Request. Si la prueba de DPoP tiene reclamaciones htm o htu que no coinciden, un iat vencido, un jti reutilizado o una firma no válida, Google devuelve un código de error invalid_dpop_proof. Si se requiere un nonce de DPoP, como durante un intercambio de tokens de actualización, y a la prueba de DPoP le falta una reclamación de nonce, o el valor del nonce no es aceptable para el servidor (p.ej., venció, ya se usó o es incorrecto), Google devuelve un código de error use_dpop_nonce junto con un encabezado HTTP DPoP-Nonce que contiene un nonce nuevo que puedes usar en una solicitud posterior. Otras fallas podrían mostrar invalid_grant.

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

En el siguiente fragmento, se muestran ejemplos de encabezados de respuesta y cuerpo de respuesta correctos cuando se usa DPoP:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/youtube.force-ssl",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Paso 6: Verifica qué permisos otorgaron los usuarios

Cuando solicites múltiples permisos (alcances), es posible que los usuarios no otorguen acceso a tu app a todos ellos. Tu app debe verificar qué permisos se otorgaron realmente y controlar de forma correcta las situaciones en las que se deniegan algunos permisos, por lo general, inhabilitando las funciones que dependen de esos permisos denegados.

Sin embargo, hay algunas excepciones. Las apps de Google Workspace Enterprise con delegación de autoridad en todo el dominio o las apps marcadas como De confianza omiten la pantalla de consentimiento de permisos detallados. En estas apps, los usuarios no verán la pantalla de consentimiento de permisos detallados. En cambio, tu app recibirá todos los permisos solicitados o ninguno.

Para obtener información más detallada, consulta Cómo controlar los permisos detallados.

Para verificar si el usuario otorgó acceso a tu aplicación a un permiso en particular, examina el campo scope en la respuesta del token de acceso. Son los permisos de acceso que otorga el token de acceso, expresados como una lista de cadenas delimitadas por espacios que distinguen mayúsculas de minúsculas.

Por ejemplo, la siguiente respuesta de token de acceso de ejemplo indica que el usuario otorgó permiso a tu aplicación para ver, editar y borrar de forma permanente los videos de YouTube, las calificaciones, los comentarios y los subtítulos del usuario:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/youtube.force-ssl",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

Llama a las API de Google

Después de 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 con un parámetro de consulta access_token o un valor de encabezado HTTP Authorization Bearer. Cuando sea posible, es preferible el encabezado HTTP, ya que las cadenas 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 APIs de Google (por ejemplo, cuando llamas a la API de YouTube Data).

Ten en cuenta que la API de YouTube Data solo admite cuentas de servicio para los propietarios de contenido de YouTube que poseen y administran varios canales de YouTube, como sellos discográficos y estudios cinematográficos.

Puedes probar todas las APIs de Google y ver sus permisos en OAuth 2.0 Playground.

Ejemplos de HTTP GET

Una llamada al extremo youtube.channels (la API de YouTube Data) con el encabezado HTTP Authorization: Bearer podría verse de la siguiente manera. Ten en cuenta que debes especificar tu propio token de acceso:

GET /youtube/v3/channels?part=snippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

Ejemplos de curl

Puedes probar estos comandos con la aplicación de línea de comandos de curl. A continuación, se muestra un ejemplo en el que se usa la opción de encabezado HTTP (preferida):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true

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

curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

Cómo actualizar un token de acceso

Los tokens de acceso vencen periódicamente y se convierten en credenciales no válidas para una solicitud a la 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, tu 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 en el cuerpo de la solicitud:

Si bien el uso de DPoP es opcional, se recomienda para aumentar la seguridad. Para usar DPoP con un token de actualización, tu aplicación debe generar un JWT de prueba de DPoP nuevo y único para cada solicitud al extremo del token. Esta prueba debe estar firmada con la misma clave privada que se usó durante el intercambio inicial del código de autorización. Tu aplicación agrega la prueba como un encabezado de la solicitud HTTP.

En el siguiente fragmento, se muestra una solicitud de ejemplo:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: DPOP_PROOF_JWT

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

Para usar DPoP con un token de actualización, debes generar un JWT de prueba de DPoP nuevo y único para la solicitud. Consulta Crea una prueba de DPoP para obtener instrucciones paso a paso sobre cómo generar el par de claves y crear el JWT.

Un intercambio exitoso se indica con una respuesta 200 OK que contiene un token de acceso nuevo. Cuando se usa DPoP, el token_type es Bearer. Una respuesta correcta confirma que se aceptó la prueba de DPoP para el token de actualización. Google también puede devolver un nuevo encabezado HTTP DPoP-Nonce en la respuesta. Si se devuelve, tu cliente debe almacenar en caché este nonce y, luego, incluirlo en la reclamación nonce de la prueba de DPoP en las solicitudes posteriores.

Se produce un intercambio fallido si falta el encabezado DPoP, no es válido o usa una clave incorrecta. Para obtener detalles sobre códigos de error específicos de DPoP y el manejo de nonces, consulta Intercambio fallido.

En el siguiente fragmento, se muestran ejemplos de encabezados de respuesta y cuerpo de respuesta correctos cuando se usa DPoP:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

{
  "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: un límite por combinación de cliente y usuario, y otro por usuario en todos los clientes. Debes guardar los tokens de actualización en un almacenamiento a largo plazo y seguir usándolos mientras sigan siendo válidos. Si tu 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 tokens

En algunos casos, es posible que un usuario quiera revocar el acceso otorgado a una aplicación. Un usuario puede revocar el acceso visitando la configuración de la cuenta. Consulta la sección Quita el acceso de un sitio o una app de terceros con acceso a tu cuenta del documento de asistencia para obtener más información.

También es posible que una aplicación revoque de forma programática el acceso que se le otorgó. La revocación programática es importante en los casos en que un usuario cancela la suscripción, quita una aplicación o los recursos de la API que requiere una app cambiaron de forma significativa. En otras palabras, 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, tu aplicación realiza una solicitud a https://oauth2.googleapis.com/revoke y, luego, incluye el token como un 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, este también se revocará.

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

Métodos de redireccionamiento de apps

Protege tus apps

Acceso basado en el tiempo

El acceso basado en el tiempo permite que un usuario otorgue a tu app acceso a sus datos durante un período limitado para completar una acción. El acceso basado en el tiempo está disponible en algunos productos de Google durante el flujo de consentimiento, lo que les permite a los usuarios otorgar acceso por un período limitado. Un ejemplo es la API de Data Portability, que permite una transferencia de datos única.

Cuando un usuario otorga a tu aplicación acceso basado en el tiempo, el token de actualización vencerá después de la duración especificada. Ten en cuenta que los tokens de actualización pueden invalidarse antes en circunstancias específicas. Consulta estos casos para obtener más detalles. El campo refresh_token_expires_in que se devuelve en la respuesta del intercambio de código de autorización representa el tiempo restante hasta que venza el token de actualización en esos casos.

Lecturas adicionales

La práctica recomendada actual de IETF OAuth 2.0 para aplicaciones nativas establece muchas de las prácticas recomendadas que se documentan aquí.