Спецификация OAuth 2.1 запланирована. Давайте изучим ключевые отличия между OAuth 2.0 и OAuth 2.1 и как они были внедрены в Logto.
С тех пор как OAuth 2.0 (RFC 6749) был выпущен в 2012 году, мир веб-приложений и мобильных приложений сильно изменился. Люди переходят с настольных компьютеров на мобильные устройства, и одностраничные приложения (SPA) теперь в моде. Также мы видели появление множества новых фреймворков и веб-технологий. С этими изменениями возросли и вызовы в области безопасности. Чтобы не отставать от последних веб-технологий, новые RFC, такие как Proof Key for Code Exchange (PKCE), постоянно выпускаются для улучшения OAuth 2.0. Стало крайне важно объединить все лучшие практики для современных требований безопасности, и поэтому вводится OAuth 2.1.
В предстоящей спецификации OAuth 2.1 рабочая группа OAuth стремится объединить все лучшие практики и рекомендации по безопасности в один документ. В Logto мы принимаем последние стандарты и лучшие практики OAuth. В этой статье мы изучим ключевые отличия между OAuth 2.0 и OAuth 2.1 и то, как они были внедрены в Logto.
Одно из самых значительных изменений в OAuth 2.1 заключается в том, что Proof Key for Code Exchange (PKCE) теперь обязателен для всех клиентов OAuth, использующих flow авторизации по коду. PKCE — это расширение безопасности, предотвращающее перехват кода авторизации. Оно особенно полезно для мобильных приложений и одностраничных приложений (SPA), где секрет клиента не может быть безопасно сохранен.
Клиентов OAuth можно разделить на два различных типа в зависимости от их способности безопасно хранить секреты:
Конфиденциальные клиенты: Эти клиенты могут безопасно хранить секреты, такие как веб-приложения, отображаемые на сервере, и веб-серверы. Все запросы, связанные с авторизацией, выполняются со стороны сервера, и риск утечки секрета клиента минимален.
Публичные клиенты: Эти клиенты не могут безопасно хранить секреты, такие как мобильные приложения и SPA. Секрет клиента может быть легко извлечен из клиентского кода, и его сложно защитить от атакующих.
Для публичных клиентов PKCE является обязательной мерой безопасности. Он обеспечивает, что код авторизации может быть обменян только клиентом, который инициировал запрос на авторизацию.
PKCE работает, генерируя случайный проверочный код и задачу с кодом на основе проверочного кода. Проверочный код отправляется на сервер авторизации, а задача с кодом используется для проверки проверочного кода при обмене кода авторизации на токен доступа.
В OAuth 2.1 PKCE становится обязательным для всех OAuth-клиентов, использующих flow авторизации по коду, независимо от их конфиденциальности — будь то конфиденциальные или публичные. Это важное изменение обеспечивает универсальную защиту от возможных атак на перехват кода авторизации.
В Logto flow проверки PKCE автоматически активируется для публичных и конфиденциальных клиентов.
Для SPA и мобильных приложений PKCE является обязательной мерой безопасности для защиты потока кода авторизации в Logto. Любой запрос на авторизацию, не содержащий задачи с кодом, будет незамедлительно отклонен сервером авторизации Logto.
Что касается конфиденциальных клиентов (традиционные веб-приложения), для улучшенной поддержки устаревших приложений, Logto все же позволяет пропустить задачу с кодом в запросе на авторизацию. Однако мы настоятельно рекомендуем конфиденциальным клиентам внедрять PKCE, включив задачу с кодом в запрос на авторизацию, следуя примеру публичных клиентов.
URI (Унифицированный идентификатор ресурса) перенаправления — это конкретный конечный пункт или URL, на который сервер авторизации перенаправляет пользователя после завершения процесса аутентификации и авторизации.
Во время потока OAuth клиентское приложение включает URI перенаправления в качестве части первоначального запроса на авторизацию. После завершения пользователем процесса аутентификации сервер авторизации формирует ответ, содержащий код авторизации, и перенаправляет пользователя на указанный URI перенаправления. Любое отклонение от исходного URI перенаправления приведет к утечке кода или токена.
Точное строковое совпадение URIs перенаправления впервые было введено в разделе 4.1 OAuth 2.0 Security Best Current Practices. Эта практика гарантирует, что URI перенаправления должен точно совпадать с зарегистрированным на сервере авторизации. Любое отклонение от зарегистрированного URI перенаправления приведет к ответу с ошибкой.
мы получили множество запросов от сообщества по поводу реализации шаблонного совпадения для URIs перенаправления. Хотя шаблонное совпадение может быть удобным для разработчиков, управляющих множеством поддоменов или путей, особенно с большим количеством случайных поддоменов, оно также несет в себе риски для безопасности, такие как атаки с открытым перенаправлением. Для практической иллюстрации опасностей, связанных с отсутствием проверки URI перенаправления, обратитесь к нашему блогу Краткий обзор безопасности OAuth.
В соответствии со строгими стандартами безопасности OAuth 2.1, Logto использует точное строковое совпадение URIs перенаправления. Это решение приоритетизирует безопасность потока OAuth. Вместо использования шаблонного совпадения, мы рекомендуем разработчикам зарегистрировать все возможные URIs перенаправления на сервере авторизации Logto. Это обеспечивает тщательную проверку URIs перенаправления и помогает смягчить потенциальные уязвимости в безопасности.
Flow имплицитного подтверждения в OAuth 2.0 был разработан для SPA, где токен доступа возвращается непосредственно в фрагменте URL после аутентификации пользователя. Этот метод был удобен, поскольку позволял избежать дополнительного шага обмена токенов, предоставляя клиенту возможность непосредственно получить токен.
Однако у этого удобства есть отрицательные стороны. Токен доступа может быть раскрыт неавторизованным сторонам через историю браузера, заголовки реферера или другими способами, что упрощает возникновение нарушений безопасности, особенно если токены доступа остаются действительными в течение длительного времени. Например, если запрос на авторизацию перехвачен злоумышленником, он может легко извлечь токен доступа из фрагмента URL и выдать себя за пользователя.
В документе OAuth 2.0 Security Best Current Practices четко указано, что:
Клиенты НЕ ДОЛЖНЫ использовать flow имплицитного подтверждения (тип ответа "token") или другие типы ответов, выдающие токены доступа в ответе на авторизацию.
Таким образом, Implicit Flow был официально исключен из спецификации OAuth 2.1.
В Logto flow авторизации по коду с PKCE — единственный поддерживаемый flow для SPA и мобильных приложений. Flow авторизации по коду обеспечивает более безопасный способ получения токенов доступа путем обмена кода авторизации.
Grant-доступ на основе учетных данных владельца ресурса (ROPC) позволяет клиенту обменять имя пользователя и пароль пользователя на токен доступа. Он был впервые введен в спецификации OAuth 2.0 как способ поддержки устаревших приложений, таких как HTTP basic аутентификация или устаревшие нативные приложения, которые не могли использовать более безопасные потоки на основе OAuth.
Тип Grant ROPC был помечен как не рекомендуемый в спецификации OAuth 2.0 из-за своих рисков безопасности. Учетные данные пользователя подвергаются раскрытию клиентскому приложению, что может привести к потенциальным нарушениям безопасности. Клиентское приложение может хранить учетные данные пользователя, и если оно будет скомпрометировано, учетные данные пользователя могут быть раскрыты злоумышленникам.
Позже в разделе 2.4 OAuth 2.0 Security Best Current Practices запрет на использование типа Grant ROPC был далее подчеркнут как НЕ ДОЛЖЕН быть использован. В результате этого, тип Grant ROPC был исключен из спецификации OAuth 2.1.
Из-за высоких рисков безопасности, связанных с типом Grant ROPC, Logto никогда его не поддерживал. Если вы все еще используете прямой flow авторизации учетных данных пользователя в своих устаревших приложениях, мы настоятельно рекомендуем перейти на более безопасный метод, например, flow авторизации по коду или Grant-доступ по учетным данным клиента. Logto предлагает различные SDK и учебные материалы, чтобы помочь вам легко интегрировать эти безопасные потоки OAuth в ваши приложения.
Мы понимаем, что разработчики могут захотеть создать или разместить собственный интерфейс для входа пользователей ради лучшего пользовательского опыта с продуктом. В Logto мы предлагаем ряд опций кастомизации интерфейса входа (SIE), включая настройки бренда и пользовательский CSS. Кроме того, у нас есть несколько текущих проектов, таких как инкапсуляция собственного интерфейса и прямой вход, чтобы предоставить разработчикам больше гибкости для создания собственного интерфейса входа, сохраняя при этом безопасность потока OAuth.
OAuth 2.1 — это последнее обновление протокола OAuth, направленное на решение сегодняшних вызовов безопасности, одновременно учитывающее нужды современных веб- и мобильных приложений. Рабочая группа OAuth активно обновляет и совершенствует OAuth 2.1, чтобы обеспечить его соответствие последним стандартам безопасности и лучшим практикам. Последний проект, OAuth 2.1 11, был выпущен в мае 2024 года, что свидетельствует о значительном прогрессе на пути к его окончательной версии. С грядущим широкомасштабным применением мы настоятельно рекомендуем всем следовать лучшим практикам, изложенным в OAuth 2.1, чтобы повысить безопасность и улучшить пользовательский опыт.