Почему вам следует отказаться от использования типа выдачи учетных данных владельца ресурса (ROPC)

Введение#

Тип выдачи учетных данных владельца ресурса (ROPC), также известный как тип выдачи пароля, является потоком OAuth 2.0, который позволяет приложению обменивать имя пользователя и пароль пользователя на токен доступа. Этот тип впервые был введен в спецификации OAuth 2.0 в качестве способа поддержки устаревших приложений, таких как базовая HTTP-аутентификация или устаревшие локальные приложения, которые не могли использовать более безопасные токенизированные потоки OAuth.

Однако тип выдачи ROPC представляет несколько угроз безопасности и был отмечен как НЕ ДОЛЖЕН использоваться в лучших практиках безопасности OAuth 2.0.

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

Тип выдачи ROPC vs. поток авторизационного кода#

Как работает тип выдачи ROPC#

Тип выдачи ROPC является простым потоком, который обменивает имя пользователя и пароль пользователя на токен доступа. Клиентское приложение напрямую собирает учетные данные пользователя и отправляет их непосредственно на сервер авторизации. Затем сервер авторизации проверяет учетные данные и выдает клиенту токен доступа.

Как работает поток авторизационного кода#

В отличие от этого, поток авторизационного кода является рекомендуемым потоком OAuth 2.0 для веб-приложений. Он включает в себя несколько шагов и перенаправлений между клиентским приложением, сервером авторизации и браузером пользователя. Поток авторизационного кода является более безопасным, так как он не раскрывает учетные данные пользователя клиентскому приложению.

Основное различие между типом выдачи ROPC и потоком авторизационного кода заключается в том, что тип выдачи ROPC раскрывает учетные данные пользователя клиентскому приложению, тогда как поток авторизационного кода этого не делает. Учетные данные пользователя должны храниться конфиденциально на сервере авторизации. Всякий раз, когда клиентское приложение запрашивает ресурс от имени пользователя, оно должно перенаправить пользователя на сервер авторизации для аутентификации и авторизации клиентского приложения. Это сводит к минимуму количество авторизационных данных на стороне клиентского приложения.

Угрозы безопасности типа выдачи ROPC#

1. Раскрытие учетных данных пользователя#

Как мы уже упоминали, тип выдачи ROPC раскрывает учетные данные пользователя клиентскому приложению. Это значительная угроза безопасности, так как клиентское приложение может сохранить или занести в журнал учетные данные пользователя, и быть повторно авторизованным без ведома пользователя.

Особенно для публичных клиентских приложений, таких как мобильное приложение или одностраничное приложение, клиентское приложение может быть легко изменено или подвергнуто реверс-инжинирингу для извлечения учетных данных пользователя. Ни мобильное приложение, ни одностраничное приложение, работающее в браузере пользователя, не могут хранить секреты конфиденциально. Следовательно, они не могут аутентифицировать пользователя без раскрытия его учетных данных.

Даже если владелец ресурса имеет доверительные отношения с клиентским приложением, клиентское приложение играет роль посредника в процессе аутентификации и может быть скомпрометировано другим злонамеренным участником. Злоумышленник может украсть учетные данные пользователя и выдать себя за пользователя для доступа к его ресурсам.

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

Представьте, что у вас есть несколько приложений, использующих тип выдачи ROPC, потенциальный риск раскрытия учетных данных увеличивается многократно.

2. ROPC не поддерживает согласие пользователя#

Тип выдачи ROPC не поддерживает согласие пользователя. Когда клиентское приложение напрямую собирает учетные данные пользователя, у пользователя нет возможности просмотреть и одобрить доступ клиентского приложения к его ресурсам. Это является нарушением конфиденциальности и доверия пользователя.

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

3. ROPC не поддерживает многофакторную аутентификацию#

Многофакторная аутентификация (MFA) — это механизм безопасности, который требует от пользователя предоставить два или более факторов проверки для доступа к своим ресурсам. Это добавляет дополнительный уровень безопасности в процесс аутентификации. Тип выдачи ROPC не поддерживает MFA. Вместо этого он ограничивает процесс аутентификации одним фактором, а запрос токена основан только на учетных данных пользователя. Невозможно реализовать механизмы аутентификации на основе вызовов, такие как SMS OTP, email OTP или WebAuthn, с использованием типа выдачи ROPC.

Тип выдачи ROPC не совместим с современными приложениями#

Тип выдачи ROPC был разработан для поддержки устаревших приложений, которые не могут поддерживать современные системы управления идентификацией (IAM), такие как одноразовая идентификация и федерации идентификаторов.

1. ROPC не совместим с одноразовой идентификацией#

Одноразовая идентификация (SSO) — это современная архитектура аутентификации, которая позволяет пользователям один раз войти в систему и получить доступ к нескольким приложениям без усилий.

Централизованный IdP (Identity provider) играет ключевую роль в архитектуре SSO. Он управляет сессией аутентификации пользователя и выдает токены клиентским приложениям. Клиентским приложениям не нужно собирать учетные данные пользователя напрямую, и учетные данные пользователя хранятся конфиденциально внутри IdP.

Тип выдачи ROPC не поддерживает SSO. Он требует от клиентского приложения собирать учетные данные пользователя напрямую, что нарушает архитектуру SSO. Он не совместим с современными системами SSO, такими как OpenID Connect (OIDC) или SAML.

2. ROPC не совместим с федерациями идентификаторов#

Подобно архитектуре SSO, федерации идентификаторов позволяют пользователям использовать свою существующую идентификацию для доступа к нескольким сторонним приложениям. Пользователь может связать несколько социальных аккаунтов, таких как Google, Facebook или Twitter, с централизованным IdP и использовать эти социальные аккаунты для аутентификации с клиентскими приложениями. Все федерации идентификаторов управляются IdP, и клиентские приложения не знают деталей аутентификации пользователя.

Тип выдачи ROPC, напротив, требует от клиентского приложения собирать учетные данные пользователя напрямую. Это ограничивает возможности клиентского приложения по поддержке федераций идентификаторов и раскрывает данные идентификатора пользователя клиентскому приложению.

Заключение#

Тип выдачи учетных данных владельца ресурса (ROPC) является устаревшим потоком OAuth 2.0, который представляет значительные угрозы безопасности и должен быть признан устаревшим. Он раскрывает учетные данные пользователя клиентскому приложению, не поддерживает современные механизмы безопасности, такие как MFA или SSO. Мы настоятельно рекомендуем избегать использования типа выдачи ROPC в ваших приложениях. Если у вас есть устаревшие системы аутентификации, которые зависят от типа выдачи ROPC, рассмотрите возможность миграции на более безопасные потоки OAuth 2.0, такие как поток авторизационного кода или поток клиентских учетных данных.

Свяжитесь с нами, если вам нужна помощь в интеграции безопасной службы аутентификации и авторизации пользователей в ваши приложения или в миграции с устаревшей системы аутентификации на основе паролей на более безопасный поток OAuth 2.0. Мы здесь, чтобы помочь вам создавать безопасные и современные приложения.