Авторизация: Любые преимущества OAuth2 для сторонних веб- и мобильных клиентов
Я хотел бы узнать, есть ли какие-либо преимущества в плане безопасности при использовании OAuth2 для авторизации, когда все клиенты разрабатываются, принадлежат и контролируются разработчиком/владельцем/контролером API; в отличие от использования аутентификации по токенам согласно Django Rest Framework's Token Authentication.
Насколько я понимаю, OAuth был создан для целей делегированной авторизации - предоставления сторонним приложениям доступа к данным пользователя без знания его учетных данных. Похоже, что теперь он стал стандартом даже там, где делегирование не требуется. Я не понимаю, почему. Есть ли вообще какая-либо польза в тех случаях, когда делегирование не требуется?
Моя установка будет представлять собой Django Rest Framework API с веб-клиентом SPA и мобильными клиентами. Права ассоциируются с учетными записями пользователей. Пользователи входят в систему с помощью электронной почты и пароля.
Я не думаю, что это вопрос мнения, потому что я не спрашиваю, что лучше, я сам приму это решение, я просто пытаюсь понять, есть ли на самом деле хоть какое-то преимущество в безопасности у варианта OAuth. Этот вопрос может быть несколько открытым, но, надеюсь, в пределах допустимого, поскольку я ограничиваю рассмотрение только соображениями безопасности. Усилия разработчиков и т.д. не являются необходимыми для обсуждения.
OAuth - это, прежде всего, набор лучших практик проектирования безопасности, представленных в виде стандартных спецификаций, которые отображаются на сценарии использования для компаний-разработчиков программного обеспечения. Речь идет не только о делегировании.
Я бы не сказал, что решения становятся more secure при использовании OAuth. Это скорее случай, когда угрозы лучше продуманы, а также общая архитектура.
ПРОТЕСТИРОВАТЬ ДАННЫЕ В API
Решение OAuth включает проверку маркера доступа JWT при каждом запросе, а затем использование claims для осуществления реальной работы по авторизации.
Это хорошо подходит для архитектур с нулевым доверием, где JWT могут передаваться между API, а утверждения scope и audience могут использоваться для проверки границ. В документе IAM Primer представлен хороший обзор.
УИ ПОТОКИ
Веб и мобильные устройства сложны, и стоит помнить о SPA Best Practices, независимо от того, используете ли вы OAuth или любое другое решение, например, сайт, управляющий собственными паролями.
ПОЛНЫЕ РЕШЕНИЯ OAUTH
Полное решение OAuth предполагает использование стороннего сервера авторизации (AS), который управляет сложной работой по обеспечению безопасности, но его интеграция требует определенного обучения. Он также позволяет использовать поток кода , о котором стоит прочитать.
Иногда компании используют AS, когда им требуется несколько методов входа, пользовательская аутентификация, интеграция с бизнес-партнерами или использование расширенных потоков или финансовой безопасности, что требуется в некоторых отраслях промышленности.
ВАШЕ РЕШЕНИЕ
Безопасность для веб, мобильных устройств и API - сложная задача, как бы вы ее ни решали. Обычно компании определяют требования и разрабатывают, как они хотят, чтобы работали сквозные потоки, а не просто ставят задачу разработчикам. В моем посте в блоге предлагается процесс для людей.
Моя общая рекомендация - следовать шаблонам OAuth для защиты данных, даже если вы изначально реализуете потоки пользовательского интерфейса более простым способом. В будущем ваш код можно будет перевести на архитектуру с полным OAuth, если ваши требования к безопасности изменятся.