> This page is for Plataforma, version Heredado.
> For other versions, use one of these documentation indexes:
> - V4 (default): https://next.developer.frame.io/platform/v4/llms.txt
> - V4 experimental: https://next.developer.frame.io/platform/v4-experimental/llms.txt
> - Heredado: https://next.developer.frame.io/platform/v2/llms.txt
> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://next.developer.frame.io/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://next.developer.frame.io/_mcp/server.
# Flujo de autorización de código de OAuth 2
## Información general
Frame.io admite la creación y administración de aplicaciones de OAuth 2. A diferencia de los [tokens de desarrollador](/getting-started/authentication#developer-tokens), las aplicaciones de OAuth 2 permiten que cualquier usuario de Frame.io conceda sus credenciales mediante inicio de sesión seguro para que la aplicación puede actuar en nombre de ese usuario.
Básicamente, las aplicaciones de OAuth 2 son ideales para cualquier escenario de integración en el que el contexto y el acceso de una persona individual sean importantes.
## Flujo de código OAuth 2
### La secuencia básica
En un nivel muy alto, OAuth 2 tiene tres partes:
1. El **usuario** (en nuestro caso, cualquier persona con inicio de sesión de Frame.io)
2. La **aplicación** cliente (la aplicación de OAuth 2.0 externa)
3. El **servidor** de credenciales (en nuestro caso: Frame.io)
El flujo de código para OAuth 2 es un proceso de cuatro pasos mediante el cual:
1. La **aplicación** presenta al **usuario** una pantalla de inicio de sesión
2. El **usuario** introduce sus credenciales, que van directamente al **servidor**
3. Si el inicio de sesión es correcto, el **servidor** devuelve una página que solicita al **usuario** que confirme si desea conceder un conjunto preconfigurado de ámbitos de acceso a la **aplicación**
4. Si el **usuario** da su consentimiento, el **servidor** envía a la **aplicación** un token que se puede usar para actuar en nombre del **usuario** con los ámbitos solicitados.
De esta manera, una aplicación cliente puede tomar medidas en nombre del usuario, de forma segura, con el permiso del usuario y (lo que es importante) sin ver ni gestionar nunca las credenciales reales del usuario.
### El ciclo de devolución de llamada
La secuencia anterior se basa en que el servidor (Frame.io) aloje dos servicios, cada uno de ellos con su propia ruta:
| Servicio | URL | Método | Descripción |
| ---------- | ---------- | ---------- | ---------- |
| Autorización | `https://applications.frame.io/oauth2/auth` | `GET` | Dada la información sobre la aplicación cliente de OAuth, invoca el flujo de autorización con el servidor. |
| Token | `https://applications.frame.io/oauth2/token` | `POST` | Dada la información del paso de autorización, recupera un token en nombre del usuario. |
La función de la aplicación de OAuth 2 en este ciclo es identificarse ante el servidor y realizar esas dos solicitudes.
## Ejemplo rápido
Si ya conoce el resto de la estructura de OAuth 2.0, el siguiente ejemplo puede ser suficiente para empezar. Si quiere obtener más información, consulte la guía más detallada [aquí](/oauth-2-applications/building-an-oauth2-app).
### Configurar su aplicación
1. Inicie sesión en [Frame.io Developer Portal](/) con sus credenciales de Frame.io, vaya a **OAuth Apps** a través de los vínculos del lado izquierdo y haga clic en **New** para comenzar a configurar su aplicación.
2. En la pantalla siguiente, introduzca un **nombre** y **URI de redirección** para su aplicación, seleccione sus **ámbitos** y elija si desea usar **PKCE**.
3. Guarde la información que ha introducido, y ahora debería ver la configuración de su aplicación nueva.
La configuración de "**P**roof **K**ey for **C**ode **E**xchange" ("pixie", Clave de prueba para el intercambio de códigos) habilitará a su aplicación para solicitar tokens sin proporcionar su `client_secret`. Como tal, no se le proporcionará un `client_secret`, y no debe incluir ningún encabezado `Authorization` al realizar la solicitud `POST` para un token en el ciclo de devolución de llamada de su aplicación. Dicho esto, **sí necesitará incluir su `client_id` en su devolución de llamada**, o su solicitud será denegada.
#### ¿Cuándo debo usar PKCE?
En general, no hay efectos secundarios negativos al usar PKCE, y es el enfoque recomendado y preferido. Al desarrollar una aplicación cliente OAuth 2.0, implementará el flujo de autorización de código en uno de dos contextos:
- **Privado**: Su flujo se implementa en un lenguaje del lado del servidor (Python, Java) y puede administrar de forma segura su `client_secret` en un servidor que controla. - **Público**: Su flujo se implementa en un lenguaje del lado del cliente (JavaScript) o directamente en un dispositivo cliente que controla un usuario final (iOS, Android).
Como regla general, puede considerar una aplicación como "pública" si usted, el desarrollador de la aplicación, no puede ver y controlar todo el tráfico de red relacionado con el intercambio secreto. Esto significa que, además de las aplicaciones en el lado del cliente, las aplicaciones de dispositivo móvil, los dispositivos integrados o cualquier dispositivo que se encuentre en la red de un usuario final (AppleTV, Roku, etc.) deben considerarse públicos.
En contextos privados, *puede* usar PKCE. En contextos públicos, *debe* usar PKCE.
## Crear su aplicación de OAuth 2
Ahora que tiene una configuración de aplicación en Frame.io, puede proceder a configurar el servidor de devolución de llamada con el fin de gestionar las dos rutas clave para completar el ciclo de devolución de llamada, según la tabla anterior.
Para obtener información más detallada sobre cómo generar la aplicación, consulte [Crear una aplicación de OAuth 2](/oauth-2-applications/building-an-oauth2-app).