Вопрос или проблема
Личные токены доступа против OAuth
Мы хотим, чтобы пользователи нашего сервиса могли писать программы/скрипты, которые действуют от их имени (т.е. от имени пользователя).
Я видел, что различные сервисы (GitHub, Digital Ocean, GitLab) используют Личные Токены Доступа (PAT) для этой цели.
Разве это не то, с чем может помочь OAuth, в частности, Набор Учетных Данных Клиента?
В нашем случае мы используем краткоживущие и безсостояние JWT в качестве токенов доступа для нашего API. Таким образом, если бы мы реализовали что-то подобное PAT, это в любом случае выглядело бы очень похоже на Набор Учетных Данных Клиента. Т.е.:
- пользователь (в своем скрипте) запрашивает указанный долгоживущий учетные данные и получает пару (идентификатор, секрет)
- пользователь (в своем скрипте) использует (идентификатор, секрет) для запроса Токена Доступа (краткоживущего)
- пользователь (в своем скрипте) делает нужный запрос к API с Токеном Доступа
- пользователь (в своем скрипте) использует (идентификатор, секрет) для запроса нового Токена Доступа, если существующий истек
Значение sub в JWT токене доступа – это идентификатор пользователя, поэтому я колеблюсь называть этот поток Набором Учетных Данных Клиента.
Вы правильно отметили, что Личный Токен Доступа (PAT) и поток Набора Учетных Данных Клиента различны. PAT, как подразумевает термин “личный”, предоставляет авторизацию для Пользователя, поэтому JWT содержит информацию о Пользователе. Поток Набора Учетных Данных Клиента позволяет Сервисной Учетной Записи получить Токен Доступа, который обеспечивает авторизацию для Сервисной Учетной Записи, поэтому JWT содержит информацию о Сервисной Учетной Записи.
Что касается API ключа, поскольку кто-то упомянул об этом, API ключ является возможной альтернативой потоку Набора Учетных Данных Клиента, потому что он также предоставляет авторизацию для Сервисной Учетной Записи. Предполагая, что вы хотите предоставить авторизацию для Пользователя, то ни поток Набора Учетных Данных Клиента, ни API ключ не подходят. Вместо этого есть 2 решения: PAT и потоки авторизации пользователя OAuth 2 (например, поток кода авторизации). Для вашего конкретного требования не использовать долгоживущий объект авторизации, PAT обычно является худшей альтернативой по следующим причинам:
-
Пользовательский Опыт: С краткоживущим объектом авторизации Пользователь должен периодически переходить на ваше приложение, генерировать новый PAT и обновлять PAT в своем скрипте. Используя потоки авторизации пользователя OAuth 2, Пользователь должен только войти в систему, чтобы получить новый Токен Доступа и Токен Обновления (скрипт запускает страницу входа вашего приложения и завершает поток входа OAuth 2 для получения этих токенов).
-
Усилия Разработчика: Как вы отметили, что ваши API защищены авторизацией JWT, вам потребуется дополнительная работа для поддержки авторизации PAT, автоистечения PAT и т.д. Кроме того, OAuth 2 является отраслевым стандартом, в то время как PAT не имеет стандартов, регулирующих его, что означает, что нет общепринятых рекомендаций по лучшим практикам и подводным камням, которые следует избегать при реализации решения PAT.
Если вы задаетесь вопросом, почему GitHub позволяет пользователям генерировать PAT, вероятно, это связано с тем, что сторонним разработчикам намного проще попробовать API, так как это требует всего 2 шага:
- Создайте PAT на сайте вашего ПО
- Добавьте PAT в HTTP-запросы, отправленные вашему ПО
В то время как для потока входа пользователя OAuth 2 разработчику, вероятно, необходимо импортировать библиотеку OAuth 2 и настроить Клиента OAuth 2, что не только требует нескольких дополнительных шагов, но и, вероятно, будет нетривиально для разработчика, незнакомого с OAuth 2.
PAT обеспечивает лучший пользовательский опыт для длительного использования, если вероятность утечки PAT низка, потому что Пользователи не должны периодически повторно входить в систему.
Ответ или решение
Личностные токены доступа (PAT) против OAuth
Для обеспечения доступа к вашему сервису пользователи должны иметь возможность писать программы и скрипты, которые действуют от их имени. В этом контексте вам нужно рассмотреть два подхода: Личностные токены доступа (PAT) и протокол OAuth.
Личностные токены доступа (PAT)
Личностные токены доступа представляют собой специальные токены, которые пользователи могут генерировать для аутентификации и авторизации своих скриптов и приложений. Они часто используются в таких сервисах, как GitHub, Digital Ocean и GitLab, и имеют следующие характерные особенности:
- Простота использования: Пользователи могут легко сгенерировать PAT через интерфейс своего аккаунта. Этот процесс может быть интуитивно понятным и не требует глубоких знаний протоколов аутентификации.
- Долгосрочные токены: PAT, как правило, являются долговечными токенами, что позволяет пользователям не беспокоиться о частом обновлении токенов, пока нет утечки данных.
- Легкость внедрения: Для разработчиков API от ваших сервисов потребуется минимальная работа, чтобы настроить поддержку PAT. Использование PAT может быть менее трудоемким для быстрого тестирования и интеграции.
Тем не менее, использование PAT может иметь свои недостатки, особенно в контексте безопасности. Пользователи должны быть осторожны, чтобы не допустить утечек токенов, так как это может привести к несанкционированному доступу к их данным.
OAuth
OAuth – это более сложный, но также мощный протокол аутентификации и авторизации. Варианты использования OAuth, такие как Authorization Code Flow, предлагают более безопасный способ реализации авторизации пользователей:
- Краткосрочные токены и обновление: OAuth позволяет выдавать краткосрочные токены доступа и обновлять их с помощью refresh-токенов. Это помогает минимизировать сроки действия токенов и снижает риски, связанные с их компрометацией.
- Стандартизация: OAuth является индустриальным стандартом, который имеет богатое сообщество и рекомендации по безопасному внедрению. Это позволяет вам избежать проблем, связанных с отсутствием стандартов в реализации PAT.
- Безопасность: Процесс аутентификации через OAuth может быть защищен дополнительными методами, такими как двухфакторная аутентификация, что делает его более безопасным в сравнении с PAT.
Сравнение подходов
Вы правильно отметили, что использование OAuth в потоке клиентских учетных данных (Client Credentials Flow) не совсем соответствует вашим требованиям, так как токены, полученные таким образом, относятся к самой службе (Service Account), а не к пользователю.
Однако в вашем конкретном случае, если пользователи запрашивают долгосрочные учетные данные и впоследствии используют их для получения краткосрочных токенов, то это действительно будет похоже на поток клиентских учетных данных. Главное различие заключается в том, кто подписан на токен: в случае PAT это пользователь, а в случае Client Credentials – служебный аккаунт.
Итог
Если ваша приоритетная цель – предоставить простоту использования и скорость интеграции для разработчиков, вы можете рассмотреть возможность использования PAT. Однако имейте в виду, что это решение может обернуться проблемами в плане безопасности и удобства для пользователя в долгосрочной перспективе, особенно если токены будут утекать.
С другой стороны, если вы стремитесь к стандартному, безопасному и более управляемому решению, рассмотрите возможность внедрения OAuth с использованием подходящего потока аутентификации, предпочтительно Authorization Code Flow, для обеспечения безопасности и удобства для пользователей.
Выбор между PAT и OAuth должен основываться на конкретных требованиях вашего сервиса, уровне безопасности, который вы хотите обеспечить, и удобстве для ваших пользователей.