Autenticación solo de la App y Bearer Token de OAuth 2.0

​

Autenticación solo de App y Bearer Token OAuth 2.0

X ofrece a las aplicaciones la capacidad de emitir solicitudes autenticadas en nombre de la propia aplicación, en lugar de hacerlo en nombre de un usuario específico. La implementación de X se basa en el flujo de Client Credentials Grant de la especificación OAuth 2.

La autenticación solo de App no incluye ningún contexto de usuario y es una forma de autenticación en la que una aplicación realiza solicitudes a la API en su propio nombre. Este método está destinado a desarrolladores que solo necesitan acceso de solo lectura a información pública. 

Puedes realizar autenticación solo de App usando las claves de API de consumidor de tu App o usando un Access Token solo de App (Bearer Token). Esto significa que las únicas solicitudes que puedes hacer a la X API no deben requerir un usuario autenticado.

Con la autenticación solo de App, puedes realizar acciones como:

• Obtener timelines de usuarios
• Acceder a amigos y seguidores de cualquier cuenta
• Acceder a recursos de Listas
• Buscar Tweets

Ten en cuenta que solo OAuth 1.0a o OAuth 2.0 Authorization Code Flow con PKCE son necesarios para emitir solicitudes en nombre de los usuarios. La página de Referencia de la API describe el método de autenticación necesario para usar una API. Necesitarás autenticación en contexto de usuario, con un access token (token de acceso) para realizar lo siguiente:

• Publicar Tweets u otros recursos
• Buscar usuarios
• Usar cualquier endpoint de geo
• Acceder a Mensajes Directos o credenciales de cuenta
• Recuperar las direcciones de correo electrónico de los usuarios

​

Flujo de autenticación

Para usar este método, debes usar un App only Access Token (también conocido como Bearer Token). Puedes generar un App only Access Token (Bearer Token) pasando tu consumer key y secret al endpoint POST oauth2/token. 

El flujo de autenticación de solo aplicación sigue estos pasos:

• Una aplicación codifica su consumer key y secret en un conjunto de credenciales con un formato de codificación específico.
• Una aplicación realiza una solicitud al endpoint POST oauth2/token para intercambiar estas credenciales por un App only Access Token.
• Al acceder a la REST API, la aplicación usa el App only Access Token para autenticarse.

Dado que no es necesario firmar una solicitud, este enfoque es mucho más sencillo que el modelo estándar OAuth 1.0a.

​

Acerca de la autenticación solo de App

Los tokens son contraseñas

Ten en cuenta que la consumer key y el consumer secret, así como el App only Access Token (Bearer Token) en sí, otorgan acceso para realizar solicitudes en nombre de una aplicación. Estos valores deben considerarse tan sensibles como las contraseñas y no deben compartirse ni distribuirse a partes que no sean de confianza.

SSL requerido

Todas las solicitudes (tanto para obtener como para usar los tokens) deben usar endpoints HTTPS. Sigue las prácticas recomendadas detalladas en Connecting to X API using TLS: los pares siempre deben verificarse.

Sin contexto de usuario

Al realizar solicitudes usando autenticación solo de App, no existe el concepto de un “usuario actual”. Por lo tanto, endpoints como POST statuses/update no funcionarán con autenticación solo de App. Consulta using OAuth para obtener más información sobre cómo realizar solicitudes en nombre de un usuario.

Límites de tasa

Las aplicaciones tienen dos tipos de grupos de límites de tasa.

Las solicitudes realizadas en nombre de usuarios con tokens de acceso, también conocidas como contexto de usuario, se consumen de un contexto de límites de tasa diferente al que se usa en la autenticación solo de App. En otras palabras, las solicitudes realizadas en nombre de usuarios no consumirán los límites de tasa disponibles mediante autenticación solo de App, y las solicitudes realizadas mediante autenticación solo de App no consumirán los límites de tasa utilizados en la autenticación basada en usuario.

Lee más sobre API Rate Limiting y revisa los límites.

​

Emisión de solicitudes solo de App

Paso 1: Codificar la consumer key y el consumer secret

Los pasos para codificar la consumer key y el consumer secret de una App en un conjunto de credenciales para obtener un Bearer Token son:

1. Codifica la consumer key y el consumer secret mediante codificación URL de acuerdo con la RFC 1738. Ten en cuenta que, en el momento de redactar esto, esto en realidad no cambiará la consumer key ni el consumer secret, pero este paso aún debe realizarse en caso de que el formato de esos valores cambie en el futuro.
2. Concatena la consumer key codificada, un carácter de dos puntos ”:” y el consumer secret codificado en una sola cadena.
3. Codifica en Base64 la cadena del paso anterior.

A continuación se muestran valores de ejemplo que ilustran el resultado de este algoritmo. Ten en cuenta que el consumer secret utilizado en esta página es solo para fines de prueba y no funcionará para solicitudes reales.

Consumer key	xvz1evFS4wEEPTGEFPHBog
Consumer secret	L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg
Consumer key codificada según RFC 1738 (no cambia)	xvz1evFS4wEEPTGEFPHBog
Consumer secret codificado según RFC 1738 (no cambia)	L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg
Credenciales de Bearer Token	xvz1evFS4wEEPTGEFPHBog:L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg
Credenciales de Bearer Token codificadas en Base64	:: eHZ6MWV2RlM0d0VFUFRHRUZQSEJvZzpMOHFxOVBaeVJnNmllS0dFS2hab2xHQzB2SldMdzhpRUo4OERSZHlPZw==

Paso 2: Obtener un App only Access Token (Bearer Token)

El valor calculado en el paso 1 debe intercambiarse por un App only Access Token emitiendo una solicitud a POST oauth2/token:

• La solicitud debe ser una solicitud HTTP POST.
• La solicitud debe incluir un encabezado Authorization con el valor Basic <base64 encoded value from step 1>.
• La solicitud debe incluir un encabezado Content-Type con el valor application/x-www-form-urlencoded;charset=UTF-8.
• El cuerpo de la solicitud debe ser grant_type=client_credentials.

Solicitud de ejemplo (el encabezado Authorization se ha dividido en varias líneas):

POST /oauth2/token HTTP/1.1
Host: api.x.com
User-Agent: My X App v1.0.23
Authorization: Basic eHZ6MWV2RlM0d0VFUFRHRUZQSEJvZzpMOHFxOVBaeVJn
                     NmllS0dFS2hab2xHQzB2SldMdzhpRUo4OERSZHlPZw==
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 29
Accept-Encoding: gzip

grant\_type=client\_credentials

Si la solicitud tiene el formato correcto, el servidor responderá con una carga útil codificada en JSON:

Respuesta de ejemplo:

HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/json; charset=utf-8
...
Content-Encoding: gzip
Content-Length: 140

{"token\_type":"bearer","access\_token":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%2FAAAAAAAAAAAAAAAAAAAA%3DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"}

Las aplicaciones deben verificar que el valor asociado a la clave token_type del objeto devuelto sea bearer. El valor asociado a la clave access_token es el Access Token de solo App (Bearer Token).

Ten en cuenta que un único Access Token de solo App es válido para una aplicación a la vez. Realizar otra solicitud con las mismas credenciales a /oauth2/token devolverá el mismo token hasta que se invalide.

Paso 3: Autenticar solicitudes a la API con el Access Token de solo App (Bearer Token)

El Access Token de solo App (Bearer Token) se puede usar para enviar solicitudes a endpoints de la API que admiten autenticación solo de aplicación. Para usar el App Access Token, construye una solicitud HTTPS normal e incluye un encabezado Authorization con el valor Bearer <base64 bearer token value from step 2>. Signing is not required.

Ejemplo de solicitud (el encabezado Authorization ha sido dividido en varias líneas):

GET /1.1/statuses/user\_timeline.json?count=100&screen\_name=twitterapi HTTP/1.1
Host: api.x.com
User-Agent: My X App v1.0.23
Authorization: Bearer AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%2FAAAAAAAAAAAA
                      AAAAAAAA%3DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Accept-Encoding: gzip

Invalidar un App only Access Token (Bearer Token)

Si un App only Access Token se ve comprometido o necesita invalidarse por cualquier motivo, realiza una llamada a POST oauth2/invalidate_token.

Ejemplo de solicitud (el encabezado Authorization se ha dividido en varias líneas):

POST /oauth2/invalidate_token HTTP/1.1
Authorization: Basic eHZ6MWV2RlM0d0VFUFRHRUZQSEJvZzpMOHFxOVBaeVJn
                     NmllS0dFS2hab2xHQzB2SldMdzhpRUo4OERSZHlPZw==
User-Agent: My X App v1.0.23
Host: api.x.com
Accept: */*
Content-Length: 119
Content-Type: application/x-www-form-urlencoded

access_token=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%2FAAAAAAAAAAAAAAAAAAAA%3DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Ejemplo de respuesta:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 127
...

{"access_token":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%2FAAAAAAAAAAAAAAAAAAAA%3DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"}

​

Casos de error comunes

Esta sección describe algunos errores comunes relacionados con la negociación y el uso de Bearer Tokens. Ten en cuenta que no todas las posibles respuestas de error se tratan aquí; presta atención a los códigos y respuestas de error no gestionados.

Solicitudes inválidas para obtener o revocar un App only Access Token

Intentos de:

• Obtener un App only Access Token (Bearer Token) con una solicitud inválida (por ejemplo, omitiendo grant_type=client_credentials).
• Obtener o revocar un App only Access Token (Bearer Token) con credenciales de app incorrectas o caducadas.
• Invalidar un App only Access Token (Bearer Token) incorrecto o ya revocado.
• Obtener un App only Access Token (Bearer Token) con demasiada frecuencia en un período corto de tiempo.

Darán como resultado:

HTTP/1.1 403 Forbidden
Content-Length: 105
Content-Type: application/json; charset=utf-8
...

{"errors":\[{"code":99,"label":"authenticity\_token\_error","message":"No se pudieron verificar sus credenciales"}\]}

​

La solicitud de la API contiene un token de acceso de solo App (Bearer Token) no válido

Usar un token de acceso incorrecto o revocado para realizar solicitudes a la API dará como resultado:

HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Content-Length: 61
...

{"errors":\[{"message":"Invalid or expired token","code":89}\]}

​

Token de acceso solo de App (Bearer Token) utilizado en un endpoint que no admite autenticación solo de aplicación

Al solicitar un endpoint que requiere un contexto de usuario (como statuses/home_timeline) con un token de acceso solo de App (Bearer Token) se producirá:

HTTP/1.1 403 Forbidden
Content-Type: application/json; charset=utf-8
Content-Length: 91
...

{"errors":\[{"message":"Your credentials do not allow access to this resource","code":220}\]}