Основы OAuth 2.0 и OpenID Connect

[@Евгений-ь3г5к]

Очень классный урок, респект! Большое спасибо за труд!)

[@Volosha1337]

Очень высокий уровень объяснения , безумно доступно в понимании и приятно смотреть ваши видео!

[@Devivl]

Непростая, но важная тема. Спасибо за интересную и понятную визуализированную подачу, Александр.

[@muznadzor554]

Очень трудно объяснять очень просто. Респект!

[@globalist1877]

Спасибо Вам за такие видео. Как бальзам на душу.

[@drugsbunny_8641]

Как раз дошел до этой темы и тут уже видос, очень вовремя))Спасибо огромное!

[@svyatoiambrozii]

Авотризация это конечно очень важно! Недавно осилил создание jwt токена с авторизацией по oauth2 через гугл и все получилось. Ваши советы как писал на почту, очень помогли. Спасибо вам, что стало все получаться по этой теме! Еще бы хотелось разобраться получше с интеграционным тестированием контрллеров и юнит мокито)🙂👍

[@shurik_codes]

Как-нибудь обязательно расскажу

[@vla-zav]

Спасибо за материал!

[@alexdiz4189]

топ ютубер! спасибо тебе за твою работу!

[@btk467]

Получил удовольствие от вашей работы. Спасибо. Вопрос: ожидать ли граблей если использовать вместо keycloak Azure Entra Id а в качестве клиента приложения desktop application (Delphi)?

[@dmitrylanin7812]

Спасибо!

[@e-researcher]

Ставлю лайк, пишу коммент.

[@eduardklygunov1412]

Вот это годнота подъехала

[@omonullo]

Попробуй oidc без keycloak чисто со спринг бутом. Вот тут уже надо поковыряться. А так видео хорош. Лайк

[@shurik_codes]

Пробовал, всё работает

[@АлексейЛойко-ы3в]

Здравствуйте! Скажите пожалуйста, сталкивались ли вы на практике с реализацией RegisteredClientRepository не в форме InMemoryRegisteredClientRepository ? Верно ли понимаю, что в таком случае, как вариант, потребуется хранить данные клиентов-приложений, участвующих в межсервисном взаимодействии, в БД ?

[@shurik_codes]

Да, данные клиентов хранятся в БД, реализация есть стандартная в Spring Authorization Server docs.spring.io/spring-authorization-server/docs/current/api/org/springframework/security/oauth2/server/authorization/client/JdbcRegisteredClientRepository.html

[@АлексейЛойко-ы3в]

@@shurik_codes Здравствуйте! Вновь подскажите, пожалуйста, верно ли, что в таком случае также потребуется определять в БД модель RegisteredClient(и это, видимо, на стороне сервера авторизации надо будет иметь БД, содержащую данные всех потенциальных приложений-клиентов сервера ресурсов!?) Если это верно, то тогда могут ли значения конкретного экземпляра RegisteredClient, который в данном контексте будет выражать собой отдельно взятый клиент, выступать в качестве client credentials данного клиента ?

[@homersimpson297]

дал бы хоть докер имаджи, подергать хоть эти проги для закрепления, так сказать, а так, конечно, и за это спасибо!

[@СергейПереславцев-р2э]

Отличный ролик, спасибо. 1:09:50- а скажите, для чего включен implisit flow и direct access grant в публичном клиенте, если по факту достаточно standart flow?

[@shurik_codes]

Для демонстрации этих способов предоставления полномочий. По факту правильнее всего использовать authorization code grant, он же standard flow

[@zed6204]

спасибочки

[@artemief]

Здравствуйте, Александр Подскажите пожалуйста, планируете ли снять видео урок с реализацией микросервисной архитектуры на примере, с api gateway, итд ? Было бы очень полезно Спасибо

[@shurik_codes]

Планирую)

[@artemief]

@@shurik_codes супер, большое спасибо 🤗

[@ruslannnnnn8888]

Очень здорово! Про тестирование что-нибудь не планируешь? юнит, интеграционное?

[@shurik_codes]

Что-нибудь будет обязательно

[@e-researcher]

Добавь, пожалуйста, этот ролик в плейлист Spring Security в деталях

[@gnidkoav]

Что Вы за шрифт используете тот рукописный? красивый очень! 😍

[@shurik_codes]

Это стандартный шрифт в Excalidraw

[@gnidkoav]

@@shurik_codes 🙏🙏

[@БогданЗараник]

Привет! Такой вопрос. У себя на проекте надо было вкатить OAuth 2.0 с красивой формочкой. Но не хотелось мучаться с аус флоу на фронте и решили просто через гейтвей прокинуть по /login урлу server-side-renderred формочку, которую даёт спринг. Только ещё кастомизировали, чтобы выглядела, как хотел заказчик: в стиле всего сайта. Как думаешь, это ок решение? Поджимали сроки, заказчику на презентацию проекта нужна была красивая формочка. Есть ли смысл переделывать на "трушный" фронтед и какие минусы у этого подхода (кроме UI составляющей, который придётся менять ещё и в шаблонах таймлифа. если заказчик захочет поменять цвет кнопок)

[@shurik_codes]

В целом нормальное решение. В любом случае процесс аутентификации реализуется на стороне бекенда. Единственный недостаток, но весьма условный, заключается в том, что на бекенда есть часть UI. Не совсем понятно, зачем нужна формочка на стороне приложения. Ведь можно сразу пользователя отправлять в сторону сервера OAuth/OIDC. Хотя если есть несколько вариантов аутентификации, то тогда да, формочка нужна.

[@БогданЗараник]

@@shurik_codes да, забыл сказать: у нас несколько аус серверов от разных контор

[@БогданЗараник]

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

[@kolyuchkin]

Спасибо за материал. Немного непонятно, почему Вы отнесли нативные приложения к "не безопасным".

[@shurik_codes]

А это не я, это всё они: datatracker.ietf.org/doc/html/rfc6749#section-2.1 Нативное приложение устанавливается на устройство пользователя, где пользователь с высокой вероятностью может извлечь секретную информацию клиента (Client Secret, JWT, сертификаты) и использовать её в своих целях.

[@kolyuchkin]

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

[@Qew-jn3io]

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

[@Worraner]

Хороший человек

[@aleksey2793]

23:00 Поясните пожалуйста) Вы говорите, что OAuth предназначен для взаимодействия между независимыми приложениями, и если есть свой клиент и свой бекенд, то OAuth не нужен. Но если взять пример мобильных игр с онлайн составляющей - абсолютно везде есть авторизация через гугл, фейсбук и прочее. То же самое часто есть в обычных мобильных приложениях. Т.е. я не могу понять, почему они это используют? Для возможности быстрого логина?

[@shurik_codes]

Я не совсем корректно выразился: на мой взгляд использование схемы, когда фронт является OAuth-клиентом, а бек - OAuth-сервером ресурсов, является избыточным, т.к. в этой схеме бек однозначно доверяет фронту. И логичнее, на мой, взгляд выдглядит аутентификация на стороне бека с дальнейшим поддержанием сессии на стороне фронта, это банально дешевле с точки зрения использования ресурсов. Во многих онлайн-сервисах, в т.ч. и в играх, OAuth/OIDC используется как SSO для быстрой регистрации и входа.

[@aleksey2793]

@@shurik_codes все, теперь понял, спасибо!

[@igormartynkin298]

Привет! Отличные видосы, но пожалуйста поставь стандартный шрифт в своих видео. Данный шрифт конечно красивый, но очень трудно его читать и слушать одновременно, поясню так как мы привыкли (со школы) к тексту в шрифте похожему Times New Roman, его наш мозг автоматически интерпретирует , а твой шрифт нужно читать и не всегда успеваешь ( ну медленно я читаю) за словами.

[@shurik_codes]

Учту

[@igormartynkin298]

@@shurik_codesСпасибо 🤝

[@dmitrys7170]

Привет! Разворачиваю spring authorization server, как замену keycloak. Не находил в русскоязычном сегменте разбора подробного как он устроен, так как проект относительно новый, на текущий момент 1.2.1 версия. Будет здорового если получится у тебя сделать по нему видео.

[@shurik_codes]

Про Spring Authorization Server я как-нибудь расскажу обязательно, но назвать его заменой Keycloak - слишком смелое заявление)

[@кибер-раб]

Как происходит 10. Пункт - Добавление события в календарь? То есть как клиент общается с сервисом ресурсов, он из JWT токена берет информацию об правах или или обращается затем к сервису авторизации?

[@shurik_codes]

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

[@zero-ix3bz]

Здравствуйте. Я сейчас делаю веб приложение с бэком. Веб будет на реакте. Суть приложения: администратор выкладывает запрос на транспортировку, а компании на него отвечают. Само собой есть регистрация/авторизация. Нужно ли для такого приложения использовать OAuth 2.0 и OpenID Connect? На данный момент всё реализовано на jwt токенах. В видео вы сказали, что особо смысла нет. Можете более детально объяснить почему?

[@shurik_codes]

Приветствую! OIDC для аутентификации пользователя в сервисе - да, можно и нужно, если есть используемый сервис единого входа (SSO). Если для фронтенда разработан и бекенд, то тогда для общения между ними проще использовать обычную HTTP-сессию. А вот если фронт обращается к множеству разных сервисов, то тогда для общения между ними есть смысл использовать OAuth/OIDC.

[@СергейПереславцев-р2э]

Насчёт ID токена тоже не понятно. Он же может прилететь внутри body вместе с аксесс токеном, даже если его не запрашивать в явном виде на этапе аутентификации.

[@kazbowski]

Привет! Очень понравилось видео :) Что думаешь насчет того, чтобы сделать гайд по spring-boot-authorization-server?

[@shurik_codes]

Обязательно будет

[@kazbowski]

@@shurik_codes чисто уже моя просьба: сделай пожалуйста, если возможно, с сущностями JPA (GrantType, Client, Scope, AuthenticationMethod, AccessToken, RefreshToken и тд), как по мне - JPA тут в самый раз, из-за огромного кол-ва связей (примеры с JDBC, с офф доки спринга - инконсистентны)

[@shurik_codes]

эм) docs.spring.io/spring-authorization-server/reference/guides/how-to-jpa.html

[@shurik_codes]

а, вижу, тут не всё

[@kazbowski]

​@@shurik_codes тут тоже инконсестенция выходит в некоторых местах (scopes varchar(1000) NOT NULL, когда скоупы через запятую записываются в колонку, а не через связи many to many, например). Хотелось бы увидеть идеальную имплементацию, по всем канонам sql :)

[@РоманДядичкин]

Александр, здравствуйте! Подскажите, пожалуйста, а исходный код выложите?

[@shurik_codes]

Да, исходный код будет, но чуть позже, когда его причешу)

[@akaZarj]

@@shurik_codes а где смотреть?

[@АлександрГубочкин-л3я]

@@shurik_codes Эхх видимо не причесали код?

[@nocturne7151]

@@shurik_codes я бы тоже код глянул

[@ЕвгенийЗубков-т9й]

А по SAML будет что-то подобное?

[@shurik_codes]

Когда-нибудь

[@игорьрезников-т5ю]

Привет! Можешь подсказать пожалуйста насчёт необходимости использовать OAuth. У меня 2 сервиса(java и php), оба имеют одну и ту же базу данных. Php взаимодействует с frontend(написан на каком-то шаблонизаторе и реакт). Они разрабатывались и жили отдельно, теперь же(в новом этапе) необходимо в frontend добавить(условно) новый раздел, в котором будет отображаться какие-то данные возвращаемые из java сервиса. Так как у каждого сервиса своя авторизация, то юзеру придётся несколько раз авторизоваться, если он захочет зайти и в java раздел и в основные. Я изначально думал сделать java сервисом ресурсов, а php клиентом, а сервисом авторизации бы выступал keycloak, но мне что-то кажется не правильным в таком взаимодействии. Правильно ли так делать? Если нет, то как мне лучше реализовать SSO?

[@shurik_codes]

Если обращения к Java-бекенду только из PHP-бекенда, то Java-бекенд можно сделать сервером ресурсов, а PHP-бекенд - клиентом. Если фронт (реакт) может обращаться к обоим бекендам, тогда можно сделать фронт клиентом, а оба бекенда - серверами ресурсов.

[@игорьрезников-т5ю]

​@@shurik_codes ещё вопросик :) У меня реакт будет являться публичным клиентом получается? Для того чтоб получить jwt от keycloak, мне нужны креды пользователя и секрет клиента. Я получается прячу секрет клиента на бэкентах и на каждом делаю точку для получения jwt, чтоб реакт мог его получить? Php же по идее будет допускать к своим ресурсам по ключу полученному от java в таком случае?

[@shurik_codes]

Нет, немного не так. Реакт будет публичным клиентом, но именно он будет получать ключ доступа, для этого нужен только client id, логин/пароль пользователь будет вводить в Keycloak. После авторизации реакт будет иметь ключ доступа, который будет передавать в запросах к бекендам. А бекенды уже будут валидировать ключ доступа.

[@игорьрезников-т5ю]

@@shurik_codes спасибо )

[@yashkevich8164]

Я что то все равно не понял разницу между OAuth 2.0 и OpenID)) И то и то, все спецификации. Но 2.0 имеет абстрактное описание и не подразумевает использование именно JWT. Но OpenId регламентирует использование именно JWT. Как то так что ли?)

[@shurik_codes]

OAuth 2.0 - стандарт авторизации, он нужен для предоставления доступа к ресурсу третьему лицу (клиенту) без передачи учётных данных (логина/пароля) владельца ресурса. OAuth 2.0 не регламентирует формат используемых ключей доступа. OpenID Connect (OIDC) - расширение OAuth 2.0 для аутентификации, оно регламентирует дополнительные эндпоинты (информация о пользователе, интроспекция ключей доступа, поиск сервисов и т.д.) и формат токенов (JWT).

[@recycle-bin-camp]

спецификация oauth 2.0 размазана по 17-20 rfc-шкам