> ## Documentation Index > Fetch the complete documentation index at: https://generaltranslation.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # 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](http://tools.ietf.org/html/rfc6749#section-4.4) de la [especificación OAuth 2](http://tools.ietf.org/html/rfc6749). 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](/es/resources/fundamentals/authentication/oauth-1-0a/api-key-and-secret) o [OAuth 2.0 Authorization Code Flow](/es/resources/fundamentals/authentication/oauth-2-0/authorization-code) con PKCE son necesarios para emitir solicitudes en nombre de los usuarios. La página de [Referencia de la API](/es/resources/fundamentals/authentication/api-reference) describe el método de autenticación necesario para usar una API. Necesitarás autenticación en contexto de usuario, con un [access token](/es/resources/fundamentals/authentication/oauth-1-0a/obtaining-user-access-tokens) (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](/es/resources/fundamentals/authentication/oauth-2-0/application-only) (también conocido como [Bearer Token](/es/resources/fundamentals/authentication/oauth-2-0/bearer-tokens)). Puedes generar un App only Access Token (Bearer Token) pasando tu consumer key y secret al endpoint [POST oauth2/token](/es/resources/fundamentals/authentication/api-reference#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](/es/resources/fundamentals/authentication/api-reference#post-oauth2-token) para intercambiar estas credenciales por un [App only Access Token](/es/resources/fundamentals/authentication/oauth-2-0/application-only). * 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](/es/resources/fundamentals/authentication/guides/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](/es/x-api/posts/creation-of-a-post) no funcionarán con autenticación solo de App. Consulta [using OAuth](/es/resources/fundamentals/authentication/oauth-1-0a/obtaining-user-access-tokens) 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](/es/x-api/fundamentals/rate-limits) y [revisa los límites](https://developer.x.com/en/portal/products).
#### 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](http://www.ietf.org/rfc/rfc1738.txt). 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](http://en.wikipedia.org/wiki/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](/es/resources/fundamentals/authentication/api-reference#post-oauth2-token): * La solicitud debe ser una solicitud HTTP POST. * La solicitud debe incluir un encabezado `Authorization` con el valor `Basic .` * 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):** ```json theme={null} 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:** ```json theme={null} 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 . 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](/es/resources/fundamentals/authentication/api-reference#post-oauth2-invalidate-token). **Ejemplo de solicitud (el encabezado Authorization se ha dividido en varias líneas):** ```bash theme={null} 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:** ```json theme={null} 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: ```json theme={null} 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: ```json theme={null} 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á: ```json theme={null} 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}\]} ```