Как стать автором
Обновить

Комментарии 3

Есть мнение, что независимо от типа клиента, нужно использовать Authorization Code grant, благо нынче есть расширения типа PKCE, которые позволяют его использовать в мобильных/нативных приложениях и js-приложениях без бэкэнда. Implicit и Password Grant — зло.
И что касается refresh token'а — рекомендовано его выдавать только для confidential clients (т.е. опять же с бэкендом), для public клиентов использовать silent refresh.
Спасибо за ваш комментарий, Authorization Code действительно самый надежный и безопасный вариант для публичных клиентов. Implicit, Password Grant больше подойдут для внутренних клиентов. Refresh token может оказаться ненадежным, например в случае возможности внедрения XSS скрипта

" Implicit и Password Grant — зло"
Password Grant будет исключен из OAuth версии 2.1.
Но только аккуратнее нифига он не зло. Если вы не имеете федеративности — тоесть записи ваших пользователей всеравно у вас, то проблем с ним нет. Проблема в самом OAuth фреймворке который предлагал слишком много способов и люди использовали их не по назначению и всеравно говорили, смотрите так можно по OAuth.
Тоесть просто со опытом и временем стало ясно как сформулировать стандарт и что не надо писать стандарт на все возможные случаи аутентификации а сконцентрироваться на чем-то.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.