Практическое руководство: управление авторизацией (приложение)

Введение

В этом руководстве мы расскажем, как обновлять, отзывать и хранить информацию об авторизации приложения C2C для Frame.io.

Что потребуется?

Если вы еще не читали руководство Реализация C2C: настройка, просмотрите его перед тем, как продолжить!Вам потребуется client_id, предоставленный нашей командой, и тот же device_id, который вы использовали в руководстве по аутентификации и авторизации. access_token и refresh_token также необходимы для выполнения этого руководства.

Токены авторизации

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

Токен обновления действует 30 дней. Ограничивая время действия access_token, мы ограничиваем потенциальные проблемы, которые могут возникнуть при его утечке. Если авторизация не обновляется до использования токена обновления, пользователю придется повторно проходить аутентификацию.

Обновление токена доступа

Если вы выполняете вызов к нашему API-интерфейсу, который требует токен доступа, и получаете следующий ответ:

1
{
2
    "code": 401,
3
    "errors": [
4
        {
5
            "code": 401,
6
            "detail": "You are not allowed to access that resource",
7
            "status": 401,
8
            "title": "Not Authorized"
9
        }
10
    ],
11
    "message": "Not Authorized"
12
}

… срок действия вашего токена доступа истек!

Чтобы обновить токен, выполните следующий вызов:

$
curl -X POST https://applications.frame.io/oauth2/token \
>
    --form 'client_id=[client_id]' \
>
    --form 'scope=offline device.connect asset.create' \
>
    --form 'grant_type=refresh_token' \
>
    --form 'refresh_token=[refresh_token]' \
>
    | python -m json.tool

Используя все эти значения (вместо только токена обновления), мы делаем невозможным создание новой авторизации из скомпрометированного токена обновления. Если кто-то хочет создать токен, как если бы он был вашей интеграцией, ему потребуются refresh_token и client_id.

Должен отобразиться такой ответ:

1
{
2
    "access_token": "[access_token]",
3
    "expires_in": 3599,
4
    "refresh_token": "[refresh_token]",
5
    "scope": "offline device.connect asset.create",
6
    "token_type": "bearer"
7
}

Это ваши новые токены авторизации. После обновления токенов старые токены перестанут работать, поэтому обязательно сохраните новые!

Если мы попробуем использовать старый токен обновления сейчас, мы получим ошибку:

1
{
2
    "error": "token_inactive",
3
    "error_description": "Token is inactive because it is malformed, expired or otherwise invalid. Token validation failed."
4
}

Наш токен уже обновлен, поэтому использование существующего токена обновления недействительно.

Отсутствие ответа на обновление

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

Такая вероятность существует и лучше перестраховаться!

Отзыв токенов

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

Чтобы отозвать нашу авторизацию, мы делаем следующий вызов:

$
curl -X POST https://applications.frame.io/oauth2/revoke \
>
    --include \
>
    --form 'client_id=[client_id]' \
>
    --form 'token=[refresh_token]'

Ответ не будет содержать полезную нагрузку. Мы использовали --include в команде для печати возвращенных заголовков, которые должны начинаться с кода состояния 200, если вызов выполнен:

HTTP/2 200
...

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

Хранение токенов

Для сохранения функциональности при циклах питания необходимо сохранить заголовки авторизации в состоянии покоя. Это можно сделать в файле, базе данных или в вашем собственном облаке. Вот несколько рекомендаций по хранению токенов авторизации:

Не разрешайте пользователю видеть токены или получать к ним доступ. Пользователю никогда не следует разрешать просматривать или извлекать свои токены. Ими должно управлять только ваше приложение. Шифруйте токены в состоянии покоя. Как и в случае с client_id, токены доступа и обновления следует шифровать в состоянии покоя, когда это возможно, чтобы предотвратить кражу ключей. Ключи авторизации не следует хранить в виде обычного текста. Не храните токены авторизации в том же файле, что и client_id. В примере приложение Python хранит client_id и device_id в том же файле, что и токены авторизации. Это работает в демонстрационных целях, но не является хорошей практикой для рабочего кода. client_id и device_id являются статическими значениями для устройства, и устройство перестанет работать, если они будут потеряны. Токены авторизации не являются статическими и их потребуется перезаписывать много раз на протяжении срока службы устройства. Если устройство потеряет питание во время обновления файла с новыми токенами, этот файл может быть поврежден, и client_id может быть утерян, в результате чего устройство не сможет повторно пройти аутентификацию в Frame.io больше никогда. При разделении токенов в худшем случае пользователю придется снова выполнить вход в Frame.io.

Лучшим местом для хранения токенов была бы проверенная база данных, например SQLite, но как минимум данные авторизации следует отделить от других значений.

Далее

Если вы еще не сделали этого, мы рекомендуем обратиться к нашей команде, а затем продолжить изучение следующего руководства. Надеемся на скорую обратную связь!