Я создаю проект в Django (v2.2) с бэкэндом REST через Django Rest Framework (v3.9.4). Этот REST API используется как SPA, так и автономными приложениями, работающими на внешних серверах. Все представления требуют аутентификации пользователя с соответствующими разрешениями.
Внешние SPA могут использовать аутентификацию сеанса и без проблем передавать ее в API REST. Однако аутентификация сеанса не подходит для автономных серверов и автономных функций, которые мы хотим использовать и для API.
Я остановился на использовании Django OAuth Toolkit (v1.2.0) для обеспечения аутентификации с использованием OAuth2.
Моя проблема заключается в следующем. Разработчики, которые хотят использовать API из какой-либо автономной среды, могут сгенерировать токен доступа с использованием типа предоставления на основе пароля или клиентских учетных данных (или любого другого типа на самом деле). Это дает им токен доступа, время истечения и токен обновления.
Для приложений, имеющих сервер с состоянием, они могут хранить токены доступа и обновления в файле, переменной среды и т. Д. По истечении срока действия токена они могут использовать токен обновления для получения нового токена доступа и перезаписи файла. или переменная окружения, чтобы она была доступна в будущем.
Однако некоторые из наших приложений существуют в виде облачных функций Google или контейнеров Docker, развернутых Jenkins. С токеном с неограниченным сроком действия мы могли бы передать токен в эти, как и любые другие секретные учетные данные, и приложение было бы неплохо в работе. Суть моей проблемы заключается в том, что должны делать эти серверные приложения после истечения срока действия токена доступа? Им нужно будет использовать токен обновления, но новый токен доступа должен быть доступен в будущих вызовах функции Cloud (для которой требуется повторное развертывание для установки переменных среды) или контейнера Docker (через диспетчер учетных данных Jenkins для повторной настройки среды). переменные в контейнере).
По умолчанию токены истекают каждый час, и истечение срока их действия не может быть отключено. Я хотел бы избежать обходного пути установки времени истечения на какое-то большое количество.
Будем весьма благодарны за любые предложения по прямым решениям или другим рекомендациям по управлению токенами с истекающим сроком действия в доверенных клиентах!
Редактировать для уточнения
В функции Google Cloud мы можем установить токен доступа, который будет доступен в качестве переменной среды для всех вызовов этой функции (в частности, зашифрованная переменная environemnt, расшифрованная с помощью Google KMS). Эта переменная среды считывается в облачной функции и передается в запросы API с заголовком Authorization: Bearer <token>. Когда срок действия этого маркера доступа истечет, нам потребуется обновить переменную среды для будущих вызовов, что потребует повторного развертывания облачной функции с помощью инструмента командной строки gcloud functions.