SDK Frame.io для Python — руководство по аутентификации
SDK Frame.io для Python — руководство по аутентификации
В этом руководстве объясняется, как выполнять аутентификацию с помощью API-интерфейса Frame.io, используя SDK Frame.io для Python (frameio). API-интерфейс Frame.io V4 использует службу Adobe Identity Management Service (IMS) — платформу идентификации Adobe на базе протокола OAuth 2.0. Это отдельное справочное руководство для Python-разработчиков. Все приведенные ниже примеры кода и рабочие процессы относятся исключительно к пакету frameio.
Типы аутентификации в SDK для Python
SDK для Python поддерживает четыре варианта аутентификации.
Учетные данные встроенного приложения Adobe требуют настройки пользовательских обработчиков схем URI (например, adobe+<hash>://…</hash>), которые перехватывают перенаправления на уровне ОС. В Python нет стандартного способа регистрации таких обработчиков, поэтому в SDK для Python отсутствует класс NativeAppAuth. Для интерактивных приложений Python используйте WebAppAuth с локальным сервером обратного вызова (например, Flask или FastAPI). Для неинтерактивных рабочих нагрузок используйте ServerToServerAuth.
Пользователи сервисных учетных записей
При использовании межсерверной аутентификации ваше приложение выступает в роли пользователя сервисной учетной записи — отдельного типа учетной записи, которая может выполнять действия от имени сервиса. Эти действия видны другим пользователям в Frame.io: когда сервисная учетная запись выполняет какое-либо действие, ее имя отображается в интерфейсе. Вы можете предоставлять и отзывать права доступа сервисных учетных записей через Adobe Admin Console и Developer Console. Управление именами сервисных учетных записей осуществляется через интерфейс Frame.io. По умолчанию ваше первое межсерверное подключение (S2S) называется Service Account User, второе — Service Account User 2 и так далее.
Подробнее — в разделе Автоматизация настройки с помощью межсерверной поддержки Frame.io.
Быстрый старт
Предварительные требования
- Учетные данные из Adobe Developer Console
- Client ID — требуется для всех процессов OAuth - секретный ключ клиента — требуется для процессов S2S и веб-приложения - URI перенаправления — требуется для процессов веб-приложения и одностраничного приложения (SPA); должен быть зарегистрирован в вашем проекте Adobe
- Установка SDK
Выбор метода
- Пользователь не участвует? Используйте межсерверную аутентификацию (
ServerToServerAuth). - Пользователь участвует и вы можете хранить секретный ключ? Используйте веб-приложение (
WebAppAuth). - Пользователь участвует, но вы не можете хранить секретный ключ? Используйте одностраничное приложение (
SPAAuth).
Токен доступа
Если у вас уже есть токен доступа, полученный из другой системы OAuth или в результате предыдущего обмена (например, через наш API-интерфейс Explorer), вы можете передать его напрямую.
Это самый простой подход, но срок действия токена со временем истечет, и SDK не будет обновлять его автоматически.
Устаревшие токены разработчика
Для учетных записей, переведенных на версию V4, которые еще не управляются через Adobe Admin Console, можно продолжать использовать устаревшие токены разработчика с сайта Frame.io Developer. При этом необходимо добавить заголовок x-frameio-legacy-token-auth и установить его значение на true.
Устаревшие токены разработчика не истекают, но они являются переходным механизмом. Для новых интеграций и производственных нагрузок мы рекомендуем использовать один из приведенных ниже процессов OAuth 2.0. Подробнее — в руководстве по миграции.
Межсерверная аутентификация (учетные данные клиента)
Используйте этот метод для серверных сервисов и сценариев, которым нужен доступ к Frame.io без участия пользователя. Этот процесс доступен только для учетных записей Frame.io V4, управляемых через Adobe Admin Console. Ваше приложение проходит аутентификацию как пользователь сервисной учетной записи без участия человека.
Синхронный
Асинхронный
Готово. auth.get_token — это вызываемый объект, который SDK запускает при каждом запросе. Если текущий токен все еще действителен, он возвращается мгновенно. Если срок его действия подходит к концу, метод сначала запрашивает новый токен без всякого вашего участия.
Как это работает
Ваши учетные данные клиента (идентификатор клиента + секретный ключ) не имеют срока действия. Вы меняете их только вручную в целях безопасности. Метод S2S обеспечивает фактически бессрочный и бесперебойный доступ к API-интерфейсу без какого-либо ручного вмешательства.
Архитектура процесса
- При первом вызове API-интерфейса метод
get_tokenзапрашивает новый токен доступа от Adobe IMS, используя тип разрешенияclient_credentials. - Токен кэшируется в памяти. Срок действия отдельных токенов доступа ограничен (обычно 24 часа), но SDK берет управление этим процессом на себя.
- При попадании кэшированного токена в буфер обновления (по умолчанию за 60 секунд до истечения) SDK автоматически получает новый токен, используя те же учетные данные клиента.
- Токены обновления не используются. Сами учетные данные клиента являются долговременным секретным ключом, который всегда можно использовать для выпуска нового токена доступа.
Явная аутентификация
Если вы хотите получить токен заранее (например, чтобы быстро выявить ошибку на этапе запуска, если учетные данные неверны), используйте следующий метод.
Веб-приложение (код авторизации)
Используйте этот метод для серверных приложений, в которых пользователи выполняют вход с помощью Adobe ID. В этом процессе требуется секретный ключ клиента, который должен безопасно храниться на вашем сервере.
Обработка обратного вызова
Когда Adobe IMS перенаправляет пользователя обратно на ваш redirect_uri, извлеките параметры code и state. Убедитесь в соответствии состояния тому, что вы сохранили, затем обменяйте код на токены.
Синхронный
Асинхронный
Этот процесс производит обмен кода авторизации на токен доступа и токен обновления, сохраняя их оба во внутренней памяти.
Полный пример реализации на Flask
Одностраничное приложение / PKCE (код авторизации + PKCE)
Используйте этот метод для браузерных приложений, программ для ПК или инструментов командной строки (CLI), которые не могут безопасно хранить секретный ключ клиента. В этом процессе используется расширение PKCE (RFC 7636), чтобы защитить обмен кода авторизации. <Steps>
<Step title=“Создание URL-адреса авторизации”>
<Tabs>
Синхронный
Асинхронный
</div>Метод
get_authorization_url возвращает объект AuthorizationUrlResult, содержащий полный URL-адрес (с встроенной строкой PKCE code_challenge) и строку code_verifier, которая понадобится вам на следующем шаге.
</Step>
Обмен кода с проверочной строкой
Когда пользователь перенаправляется обратно, используется следующий метод.
Синхронный
Асинхронный
Готово. Обновление работает так же, как и в процессе веб-приложения — SDK использует токен обновления автоматически. Разница заключается в том, что при обновлении не отправляется секретный ключ клиента, поскольку сценарий SPA разработан специально для публичных клиентов.
</Steps>
Асинхронное использование
Каждому классу аутентификации соответствует его асинхронный аналог с префиксом Async. Приведенные выше примеры кода содержат вкладки Синхронный и Асинхронный, где это применимо.
Ручное обновление токена
В процессах веб-приложения и одностраничного приложения SDK обновляет токены автоматически с помощью метода get_token. Если вам нужен явный контроль над этим процессом, вы можете вызвать метод refresh() напрямую.
Синхронный
Асинхронный
Это полезно, когда нужно принудительно обновить токен перед выполнением критически важной операции, вместо того чтобы полагаться на автоматический буфер обновления.
Сохранение токенов
Все классы аутентификации поддерживают методы export_tokens() и import_tokens() для сохранения состояния токенов между перезапусками приложения. Для процессов веб-приложения и одностраничного приложения это особенно важно, поскольку токены доступа и обновления по умолчанию хранятся в памяти. Если ваше приложение перезапустится, пользователям придется проходить аутентификацию заново, если только вы не сохранили токены. Для межсерверной аутентификации сохранение необязательно (учетные данные клиента всегда могут выпустить новый токен), но импорт кэшированного токена позволяет избежать лишнего цикла запроса-ответа при запуске.
Экспорт и импорт
Автоматическое сохранение с помощью функции on_token_refreshed
Чтобы автоматически сохранять токены при каждом их обновлении, используйте функцию обратного вызова on_token_refreshed.
Функция обратного вызова принимает словарь того же формата, что и export_tokens(), и срабатывает после каждого успешного обновления токена. Для асинхронных классов on_token_refreshed может быть как обычной функцией, так и асинхронной (async). Поддерживаются оба варианта.
Отзыв токенов
Чтобы выполнить выход пользователя из системы и аннулировать его токены в Adobe IMS, используется следующий метод.
Этот метод отправляет в Adobe IMS запрос на аннулирование токена доступа и токена обновления по принципу наилучших усилий, а затем очищает все локальные данные о состоянии токенов. После отзыва токенов пользователю потребуется пройти аутентификацию заново.
Для асинхронных классов используйте await auth.revoke().
Обработка ошибок
Все ошибки аутентификации наследуются от FrameioAuthError, поэтому вы можете перехватывать их в общем блоке или обрабатывать конкретные случаи отдельно.
Справочник по ошибкам
Обработка истекших токенов обновления в производстве
В процессах веб-приложения и SPA срок действия токена обновления со временем истекает. Когда это происходит, метод get_token генерирует исключение TokenExpiredError. Вам следует перехватить эту ошибку и перенаправить пользователя на повторное прохождение процедуры авторизации.
Справочник по конфигурации
Все классы аутентификации принимают следующие дополнительные параметры.
Справочник по параметрам
Тестовые среды
Чтобы перенаправить запросы на тестовый экземпляр Adobe IMS, переопределите параметр ims_base_url. SDK также экспортирует константу DEFAULT_IMS_BASE_URL (https://ims-na1.adobelogin.com) если вам необходимо программно ссылаться на значение, используемое в производственной среде.
Пользовательский HTTP-клиент
Для поддержки прокси или пользовательской конфигурации TLS используйте следующий метод.
Безопасность потоков
Синхронные классы аутентификации полностью потокобезопасны. Если несколько потоков одновременно вызывают метод get_token в момент, когда требуется обновление, только один поток выполняет это обновление. Остальные потоки ожидают и получают тот же результат. Никаких внешних механизмов блокировки не требуется. Асинхронные классы обеспечивают такую же гарантию безопасности с помощью механизма asyncio.Lock, что делает их безопасными для одновременного использования несколькими сопрограммами в рамках одного цикла событий.