Comments 22
Статья хорошая, я бы даже сказал отличная. Важное дело делаете — продолжайте освещать эту тему, а то в Интернете каша полная по ней, полнейшая путаница на stack overflow и 90% людей не понимают как это работает и как должно работать. Страшно подумать сколько уязвимостей сейчас существует из-за неправильно настроенной авторизации на сайтах.
И самое печальное, что в 2020 году до сих пор нет готовых решений plug and play, которые не требуют глубоких технических навыков и программирования для внедрения OAuth2 и Open ID Connect. Но есть перспективная тенденция: SECaaS, и например наша некоммерческая организация готовит SECaaS платформу которая в этом году произведёт революцию в этой сфере. И она независима (хоть и поддерживает/совместима) от OAuth2 и Open ID Connect.
Какая замечательная статья. Как раз разбирался в этой теме. Все статьи до этой были либо алверхностны либо запутанными и не понятными
Userinfo — защищённый ресурс, у него не должно быть права подписи токена, следовательно он не должен отвечать в jwt формате.
Конечная точка UserInfo является защищенным ресурсом OAuth 2.0, который возвращает утверждения о прошедшем проверку подлинности конечного пользователя. Чтобы получить запрошенные утверждения о конечном пользователе, клиент отправляет запрос конечной точке UserInfo, используя токен доступа, полученный посредством аутентификации OpenID Connect. Эти утверждения обычно представлены объектом JSON, который содержит коллекцию пар имя и значение для утвержденийJWT — стандарт для создания токенов доступа, имеющий json нагрузку. Где тут противоречие, непонятно. Да и сам OAuth ничего не имеет против — www.oauth.com/oauth2-servers/signing-in-with-google/verifying-the-user-info
В JWT данные (заголовок и пэйлоад) не шифруются, а передаются в открытом виде.
Все прекрасно и хорошо с OpenID, JWT и OAuth пока logout не нужно делать. Как с logout дела обстоят в identity server? Особенно когда есть кластер из нескольких серверов?
А что значит логаут для вас в этом контексте?
Это больше на бан похоже. Собственно во внутренних корпоративных системах очень частое требование от ИБ: "моментально" банить учетки сотрудников не то, что при подписании приказа об увольнении, а при любом подозрительном поведении, например активностях похожих на слив данных конкурентам или изучении данных клиентов, явно не относящихся к текущим задачам (а-ля "а пробью-ка я девушку, у которой номер телефона взял вчера, вдруг наш клиент").
И тут плюсы JWT превращаются если не в минусы, то в ограничения, для обхода которых нужно "убивать" плюсы. Например, таки делать запрос к базе данных при проверки токена. Подсластить пилюлю можно заменой тяжелого SQL запроса быстрым к key-value типа редиса чуть ли не с веб-сервера типа nginx, чтобы доходил до апп-сервера уже не просто провалидированный, но и проверенный на бан. А то и прямо в конфиге nginx вести список забаненных.
Насколько я понимаю, в статье допущена принципиальная грубая ошибка.
Пароль пользователя ни при каких обстоятельствах не должен передаваться клиентскому приложению. Весь смысл стандартов OAuth/OpenID как раз об этом.
Исправьте, пожалуйста.
Хотя бы один клиент как ни крутись всё равно должен увидеть пароль, просто потому что пользователь не может передать пароль напрямую на сервер (напомню, сайт в браузере - тоже клиент).
Видимо Вы тоже не до конца понимаете принцип. Пароль не должен выходить за пределы доверенного периметра куда входит браузер пользователя и сайт (приложение) провайдера аутентификации. В код третьей стороны, куда вы в данный момент хотите обратиться, неважно клиентский он или серверный, эти данные попадать не должны.
Пароль не должен выходить за пределы доверенного периметра куда входит браузер пользователя и сайт (приложение) провайдера аутентификации
Ну вот вам и тот самый клиент, которому пользователь сообщает свой пароль.
IdentityServer4. Основные понятия. OpenID Connect, OAuth 2.0 и JWT