Skip to main content

OAuth 2.0 Authorization Code Flow con PKCE

Introducción

OAuth 2.0 es un protocolo de autorización estándar del sector que permite un mayor control sobre el alcance de una aplicación y flujos de autorización en múltiples dispositivos. OAuth 2.0 te permite elegir scopes específicos y granulares que te otorgan permisos específicos en nombre de un usuario. Para habilitar OAuth 2.0 en tu App, debes habilitarlo en la configuración de autenticación de tu App que se encuentra en la sección de configuración de App de la Developer Console.

¿Cuánto tiempo permanecerán válidas mis credenciales?

Por defecto, el access token que crees a través del Authorization Code Flow con PKCE solo permanecerá válido durante dos horas, a menos que hayas usado el scope offline.access.

Refresh tokens

Los refresh tokens permiten a una aplicación obtener un nuevo access token sin solicitarlo al usuario mediante el flujo de refresh token. Si se aplica el scope offline.access, se emitirá un refresh token de OAuth 2.0. Con este refresh token, obtienes un access token. Si no se pasa este scope, no generaremos un refresh token. Un ejemplo de la solicitud que harías para usar un refresh token para obtener un nuevo access token es el siguiente:

Configuración de la App

Puedes seleccionar la configuración de autenticación de tu App para que sea OAuth 1.0a o OAuth 2.0. También puedes habilitar una App para acceder tanto a OAuth 1.0a como a OAuth 2.0. OAuth 2.0 se puede usar solo con la X API v2. Si has seleccionado OAuth 2.0, podrás ver un Client ID en la sección Keys and Tokens de tu App.

Clientes confidenciales

Los clientes confidenciales pueden guardar credenciales de forma segura sin exponerlas a partes no autorizadas y autenticarse de forma segura con el servidor de autorización, manteniendo tu client secret protegido. Los clientes públicos, dado que normalmente se ejecutan en un navegador o dispositivo móvil, no pueden usar tus client secrets. Si seleccionas un tipo de App que es un cliente confidencial, se te proporcionará un client secret. Si seleccionaste un tipo de cliente que es un cliente confidencial en la Developer Console, también podrás ver un Client Secret. Tus opciones son Native App, Single page App, Web App, Automated App o bot. Native App y Single page Apps son clientes públicos y Web App y Automated App o bots son clientes confidenciales. No necesitas client id para clientes confidenciales con un encabezado Authorization válido. Aún se te requiere incluir el Client Id en el cuerpo para las solicitudes con un cliente público.

Scopes

Los scopes te permiten establecer un acceso granular para tu App, de modo que tu App solo tenga los permisos que necesita. Para saber más sobre qué scopes se corresponden con qué endpoints, consulta nuestra guía de mapeo de autenticación.

Límites de tasa

En su mayor parte, los límites de tasa son los mismos que al autenticarse con OAuth 1.0a, con la excepción de Tweets lookup y Users lookup. Estamos aumentando el límite por App de 300 a 900 solicitudes cada 15 minutos al usar OAuth 2.0 para Tweet lookup y user lookup. Para saber más, asegúrate de consultar nuestra documentación sobre límites de tasa.

Grant types

Solo proporcionamos authorization code con PKCE y refresh token como los grant types admitidos para este lanzamiento inicial. Es posible que proporcionemos más grant types en el futuro.

Flujo de OAuth 2.0

OAuth 2.0 usa un flujo similar al que utilizamos actualmente para OAuth 1.0a. Puedes consultar un diagrama y una explicación detallada en nuestra documentación sobre este tema.

Glosario

Parámetros

Para construir una URL de autorización OAuth 2.0, deberás asegurarte de tener los siguientes parámetros en la URL de autorización.

Authorize URL

Con OAuth 2.0, creas una URL de autorización, que puedes usar para permitir que un usuario se autentique a través de un flujo de autenticación, similar a “Iniciar sesión” con X. Un ejemplo de la URL que estás creando es el siguiente:
Necesitarás tener la codificación adecuada para que esta URL funcione; asegúrate de consultar nuestra documentación sobre codificación por porcentaje.