Микросервисы OAuth2/OpenID Connect потоки
Я создаю новую платформу приложений, используя Microservice Architecture, но я много читал о различных видах аутентификации / авторизации для использования.
Я согласен на OAuth2/OpenID Connect, но просто чтобы убедиться, что мои предположения верны.
Мне нравится знать, прав ли мой поток для обработки аутентификации / авторизации моего приложения. Во-вторых, для моих доверенных приложений, как я могу запретить OAuth запрашивать у пользователя согласие?
1 ответ
С точки зрения протоколов / стандартов, использование OAuth 2.0 и OpenID Connect для системы, подобной описанной вами, является правильным решением. Они активно используются, имеют большую поддержку библиотек и сторонних провайдеров, и они также были разработаны с учетом большой зависимости от HTTP, которую демонстрируют современные системы.
С точки зрения выбора правильного потока для каждого приложения на решение не влияет приложение, воспринимаемое как стороннее или доверенное приложение; это больше о характеристиках развертывания приложения, а также о том, хочет ли приложение получить доступ к ресурсам от имени конечного пользователя или от имени самого приложения.
Проверьте Auth0 - Какой поток OAuth 2.0 я должен использовать? для хорошей иллюстрации этого процесса принятия решения.
Различие между сторонним приложением и доверенным приложением остается на усмотрение провайдера идентификации / сервера авторизации. Обычно это поддерживается, так что конечному пользователю явно не требуется согласие, если приложению доверяют; в этих случаях пометка приложения для пропуска согласия конечного пользователя рассматривается как этап администрирования, когда кто-то в одностороннем порядке и в административном порядке решает, что согласие было предоставлено этому приложению, и поэтому нет необходимости запрашивать его у конечных пользователей.
Если вы действительно решили поддержать административное согласие для какого-либо приложения, имейте в виду, что если характеристики этих приложений не позволяют им быть конфиденциальными клиентами (поддерживают безопасный механизм для аутентификации самого клиентского приложения) или имеют какой-то другой способ гарантировать идентификационная информация клиента, а затем враждебное приложение может попытаться подделать доверенное приложение, чтобы пропустить шаг согласия пользователя.