Замена неявного разрешения OAuth2 на код авторизации без секрета клиента

Question

Код авторизации OAuth 2.0 без Client Secret используется вместо Implicit Grant для клиентских JavaScript-приложений несколькими компаниями.Каковы основные преимущества / недостатки использования кода авторизации без Client Secret против неявного предоставления?Неужели больше компаний и / или организаций по стандартизации движутся в этом направлении?

Red Hat, Deutsche Telekom и другие продвинулись в этом направлении в соответствии с этой статьей и сообщениями списка рассылки IETF OAuth ниже.*https://aaronparecki.com/oauth-2-simplified/

Неявный ранее рекомендовался для клиентов без секрета, но был заменен с помощью предоставления кода авторизации без секрета.

...

Ранее было рекомендовано, чтобы браузерные приложения использовали поток «Неявный», который немедленно возвращает токен доступа и не имеет шага обмена токенами.За время, прошедшее с момента первоначального написания спецификации, передовая отраслевая практика изменилась, чтобы рекомендовать использовать поток кода авторизации без секрета клиента.Это предоставляет больше возможностей для создания безопасного потока, например, с помощью параметра состояния.Ссылки: Redhat , Deutsche Telekom , Smart Health IT .

Вот сообщения, на которые даны ссылки выше.

Red Hat

Для нашего IDP [1] наша библиотека javascript использует поток кода аутентификации, но требует общедоступного клиента, проверки redirect_uri итакже выполняет проверки и обработку CORS.Нам не понравился Implicit Flow, потому что

1) токены доступа были бы в истории браузера

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

Deutsche Telekom

То же самое для Deutsche Telekom.Наши клиенты javascript также используют поток кода с обработкой CORS и, конечно, с проверкой redirect_uri.

SMART Health IT

МыМы использовали аналогичный подход для SMART Health IT [1], используя поток кода для общедоступных клиентов для поддержки приложений в браузере и время жизни токена <1h.(Мы также разрешаем этим общедоступным клиентам запрашивать токен обновления с ограниченной продолжительностью, запрашивая область «online_access»; эти токены обновления перестают работать, когда заканчивается сеанс пользователя с AS - полезно в системах, где эта концепция сеанса имеет смысл.) </p>

Answer 1

В конце 2018 года произошла большая перемена в парадигме, касающейся публичных клиентов (приложений SPA). Ранее рекомендованный неявный поток подвергся критике со стороны ряда сторон, как указано в первоначальном вопросе.В декабре 2018 года были опубликованы два проекта IETF с описанием возможных направлений атак и лучших практик.Оба рекомендуют использовать поток кода авторизации вместо неявного потока.

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-11
https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-00

Answer 2

Ответ лежит в этой спецификации https://tools.ietf.org/html/rfc8252 В нем говорится исключительно об OAuth 2.0 для собственных приложений.Раздел 8.2 https://tools.ietf.org/html/rfc8252#section-8.2 объясняет, почему неявный поток не является предпочтительным даже для публичных клиентов.Microsoft Azure AD также пошел по этому пути.

"Поток авторизации неявного предоставления OAuth 2.0 (определенный в Разделе 4.2 OAuth 2.0 [RFC6749]) обычно работает с практикой выполнения запроса авторизации вбраузер и получение ответа на авторизацию посредством связи между приложениями на основе URI. Однако, поскольку неявный поток не может быть защищен PKCE [RFC7636] (что требуется в разделе 8.1), использование неявного потока с собственными приложениями НЕ РЕКОМЕНДУЕТСЯ.

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