> This page is for Платформа, version Предыдущая версия.
> For other versions, use one of these documentation indexes:
> - V4 (default): https://next.developer.frame.io/platform/v4/llms.txt
> - Версия 4 экспериментальная: https://next.developer.frame.io/platform/v4-experimental/llms.txt
> - Предыдущая версия: 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.

# Поток авторизации кода OAuth 2

## Обзор

Frame.io поддерживает создание приложений OAuth 2 и управление ими. В отличие от [токенов разработчика](/getting-started/authentication#developer-tokens), приложения OAuth 2 позволяют любому пользователю Frame.io предоставить свои учетные данные через безопасный вход, после чего приложение может действовать от имени этого пользователя.

Простыми словами, приложения OAuth 2 лучше всего подходят для любого сценария интеграции, в котором важен контекст и доступ отдельного пользователя.





## Поток кода OAuth 2




### Основная последовательность




На очень высоком уровне OAuth 2 имеет три стороны:



1. **Пользователь** (в нашем случае: любой с входом в Frame.io)
2. Клиентское **приложение** (внешнее приложение OAuth2.0)
3. **Сервер** учетных данных (в нашем случае: Frame.io)





Поток кода для OAuth 2 — это четырехэтапный процесс, в ходе которого:



1. **Приложение** показывает **пользователю** экран входа.
2. **Пользователь** вводит свои учетные данные, которые направляются непосредственно на **сервер**.
3. В случае выполнения входа **сервер** отправляет обратно страницу с запросом к **пользователю** подтвердить, что он хочет предоставить **приложению** предварительно настроенный набор областей доступа.
4. Если **пользователь** дает согласие, **сервер** отправляет **приложению** токен, который можно использовать для действий от имени **пользователя** с запрошенными областями доступа.





Таким образом, клиентское приложение может безопасно действовать от имени пользователя с его разрешения и (что важно) никогда не видеть и не обрабатывать фактические учетные данные пользователя.





### Цикл обратного вызова




Описанная выше последовательность основана на том, что сервер (Frame.io) размещает две службы, каждая со своим собственным маршрутом:




| Служба | URL-адрес | Метод | Описание |
| ---------- | ---------- | ---------- | ---------- |
| Аутентификация | `https://applications.frame.io/oauth2/auth` | `GET` | Используя информацию о клиентском приложении OAuth запускает поток аутентификации на сервере. |
| Токен | `https://applications.frame.io/oauth2/token` | `POST` | Используя информацию, полученную на этапе аутентификации, запрашивает токен от имени пользователя. |




Роль приложения OAuth 2 в этом цикле заключается в идентификации себя на сервере и выполнении этих двух запросов.





## Краткий пример



<Info title="Создавали ли вы приложение OAuth 2 раньше?">
  Если вы знакомы с остальными компонентами OAuth2.0, приведенного ниже примера может быть достаточно для начала работы. Если вам нужно больше сведений, ознакомьтесь с более подробным руководством [здесь](/oauth-2-applications/building-an-oauth2-app).
</Info>


### Настройка приложения



1. Войдите на [Frame.io Developer Portal](/) с помощью учетных данных Frame.io, перейдите к **OAuth Apps**, используя ссылки слева, и нажмите **New**, чтобы начать настройку приложения.
2. На следующем экране введите **имя** и **URI перенаправления** для вашего приложения, выберите **области доступа** и укажите, использовать ли **PKCE**.
3. Сохраните — теперь вы должны увидеть конфигурацию нового приложения.




<Info title="О PKCE">
  **P**roof **K**ey for **C**ode **E**xchange (произносится «пикси») позволит вашему приложению запрашивать токены без указания `client_secret`. Соответственно, вам не будет предоставлен `client_secret`, и не следует включать заголовок `Authorization` при отправке `POST` для токена в цикле обратного вызова приложения. Тем не менее **вам потребуется включить `client_id` в обратный вызов**, иначе ваш запрос будет отклонен.
</Info>


#### Когда следует использовать PKCE?




В целом использование PKCE не имеет отрицательных побочных эффектов и является рекомендуемым и предпочтительным подходом. При разработке клиентского приложения OAuth2.0 вы реализуете поток авторизации кода в одном из двух контекстов:

- **Частный**: поток реализован на серверном языке (Python, Java), и вы можете безопасно управлять `client_secret` на сервере, который контролируете. - **Общедоступный**: поток реализован на клиентском языке (Javascript) или непосредственно на клиентском устройстве, которым управляет конечный пользователь (iOS, Android).

Как правило, приложение можно считать «общедоступным», если вы, разработчик приложения, не можете видеть и контролировать весь сетевой трафик, связанный с обменом секретными ключами. Это означает, что помимо клиентских приложений общедоступными следует считать приложения для мобильных устройств, встроенные устройства или любые устройства, находящиеся в сети конечного пользователя (AppleTV, Roku и т. д.).





В частных контекстах вы *можете* использовать PKCE. В общедоступных контекстах вы *должны* использовать PKCE.





## Создание приложения OAuth 2




Теперь, когда у вас есть конфигурация приложения в Frame.io, вы можете настроить сервер обратного вызова для обработки двух ключевых маршрутов, чтобы завершить цикл обратного вызова согласно приведенной выше таблице.

Более подробную информацию о том, как создать ваше приложение, см. в разделе [Создание приложения OAuth 2](/oauth-2-applications/building-an-oauth2-app).