Авотризация это конечно очень важно! Недавно осилил создание jwt токена с авторизацией по oauth2 через гугл и все получилось. Ваши советы как писал на почту, очень помогли. Спасибо вам, что стало все получаться по этой теме! Еще бы хотелось разобраться получше с интеграционным тестированием контрллеров и юнит мокито)🙂👍
публичный клиент не может проходить аутентификацию так как невозможно хранить секретные данные ---- сейчас все это допиливается так что даже консоль разраба не открыть(при попытке все сразу затирается + невозможно сделать вообще ничего кроме как закрыть пустую панель разраба в браузере, простой пример - кассы онлайн, которые работают через браузеры, но это частные случаи.. ) но в целом ролики у вас отличные!
Здравствуйте! Скажите пожалуйста, сталкивались ли вы на практике с реализацией RegisteredClientRepository не в форме InMemoryRegisteredClientRepository ? Верно ли понимаю, что в таком случае, как вариант, потребуется хранить данные клиентов-приложений, участвующих в межсервисном взаимодействии, в БД ?
Да, данные клиентов хранятся в БД, реализация есть стандартная в Spring Authorization Server docs.spring.io/spring-authorization-server/docs/current/api/org/springframework/security/oauth2/server/authorization/client/JdbcRegisteredClientRepository.html
@@shurik_codes Здравствуйте! Вновь подскажите, пожалуйста, верно ли, что в таком случае также потребуется определять в БД модель RegisteredClient(и это, видимо, на стороне сервера авторизации надо будет иметь БД, содержащую данные всех потенциальных приложений-клиентов сервера ресурсов!?) Если это верно, то тогда могут ли значения конкретного экземпляра RegisteredClient, который в данном контексте будет выражать собой отдельно взятый клиент, выступать в качестве client credentials данного клиента ?
Здравствуйте, Александр Подскажите пожалуйста, планируете ли снять видео урок с реализацией микросервисной архитектуры на примере, с api gateway, итд ? Было бы очень полезно Спасибо
А это не я, это всё они: datatracker.ietf.org/doc/html/rfc6749#section-2.1 Нативное приложение устанавливается на устройство пользователя, где пользователь с высокой вероятностью может извлечь секретную информацию клиента (Client Secret, JWT, сертификаты) и использовать её в своих целях.
@@shurik_codes , тут все зависит от уровня безопасности, которого придерживались при разработке сервиса и клиента, и от уровня нарушителя. Подавляющее большинство средств защиты, например, ЭП от КриптоПро, ориентированы на защиту от неквалифицированного нарушителя, действующего удаленно без применения спец. средств. И там вполне нормально обеспечивают защиту ключей от подмены и несанкционированного использования)
Отличный ролик, спасибо. 1:09:50- а скажите, для чего включен implisit flow и direct access grant в публичном клиенте, если по факту достаточно standart flow?
Привет! Отличные видосы, но пожалуйста поставь стандартный шрифт в своих видео. Данный шрифт конечно красивый, но очень трудно его читать и слушать одновременно, поясню так как мы привыкли (со школы) к тексту в шрифте похожему Times New Roman, его наш мозг автоматически интерпретирует , а твой шрифт нужно читать и не всегда успеваешь ( ну медленно я читаю) за словами.
23:00 Поясните пожалуйста) Вы говорите, что OAuth предназначен для взаимодействия между независимыми приложениями, и если есть свой клиент и свой бекенд, то OAuth не нужен. Но если взять пример мобильных игр с онлайн составляющей - абсолютно везде есть авторизация через гугл, фейсбук и прочее. То же самое часто есть в обычных мобильных приложениях. Т.е. я не могу понять, почему они это используют? Для возможности быстрого логина?
Я не совсем корректно выразился: на мой взгляд использование схемы, когда фронт является OAuth-клиентом, а бек - OAuth-сервером ресурсов, является избыточным, т.к. в этой схеме бек однозначно доверяет фронту. И логичнее, на мой, взгляд выдглядит аутентификация на стороне бека с дальнейшим поддержанием сессии на стороне фронта, это банально дешевле с точки зрения использования ресурсов. Во многих онлайн-сервисах, в т.ч. и в играх, OAuth/OIDC используется как SSO для быстрой регистрации и входа.
Привет! Такой вопрос. У себя на проекте надо было вкатить OAuth 2.0 с красивой формочкой. Но не хотелось мучаться с аус флоу на фронте и решили просто через гейтвей прокинуть по /login урлу server-side-renderred формочку, которую даёт спринг. Только ещё кастомизировали, чтобы выглядела, как хотел заказчик: в стиле всего сайта. Как думаешь, это ок решение? Поджимали сроки, заказчику на презентацию проекта нужна была красивая формочка. Есть ли смысл переделывать на "трушный" фронтед и какие минусы у этого подхода (кроме UI составляющей, который придётся менять ещё и в шаблонах таймлифа. если заказчик захочет поменять цвет кнопок)
В целом нормальное решение. В любом случае процесс аутентификации реализуется на стороне бекенда. Единственный недостаток, но весьма условный, заключается в том, что на бекенда есть часть UI. Не совсем понятно, зачем нужна формочка на стороне приложения. Ведь можно сразу пользователя отправлять в сторону сервера OAuth/OIDC. Хотя если есть несколько вариантов аутентификации, то тогда да, формочка нужна.
просто по опыту, решение это сильно проще, чем заниматься мутью с интеграцией фронта с беком причём с таким запутанным флоу с кучей редиректов и проверок
Насчёт ID токена тоже не понятно. Он же может прилететь внутри body вместе с аксесс токеном, даже если его не запрашивать в явном виде на этапе аутентификации.
Здравствуйте. Я сейчас делаю веб приложение с бэком. Веб будет на реакте. Суть приложения: администратор выкладывает запрос на транспортировку, а компании на него отвечают. Само собой есть регистрация/авторизация. Нужно ли для такого приложения использовать OAuth 2.0 и OpenID Connect? На данный момент всё реализовано на jwt токенах. В видео вы сказали, что особо смысла нет. Можете более детально объяснить почему?
Приветствую! OIDC для аутентификации пользователя в сервисе - да, можно и нужно, если есть используемый сервис единого входа (SSO). Если для фронтенда разработан и бекенд, то тогда для общения между ними проще использовать обычную HTTP-сессию. А вот если фронт обращается к множеству разных сервисов, то тогда для общения между ними есть смысл использовать OAuth/OIDC.
@@shurik_codes чисто уже моя просьба: сделай пожалуйста, если возможно, с сущностями JPA (GrantType, Client, Scope, AuthenticationMethod, AccessToken, RefreshToken и тд), как по мне - JPA тут в самый раз, из-за огромного кол-ва связей (примеры с JDBC, с офф доки спринга - инконсистентны)
@@shurik_codes тут тоже инконсестенция выходит в некоторых местах (scopes varchar(1000) NOT NULL, когда скоупы через запятую записываются в колонку, а не через связи many to many, например). Хотелось бы увидеть идеальную имплементацию, по всем канонам sql :)
Как происходит 10. Пункт - Добавление события в календарь? То есть как клиент общается с сервисом ресурсов, он из JWT токена берет информацию об правах или или обращается затем к сервису авторизации?
Сервер ресурсов сам парсит JWT и получает из него нужные данные. К серверу авторизации сервер ресурсов обращается для получения ключей, чтобы провалидировать подпись JWT.
Привет! Разворачиваю spring authorization server, как замену keycloak. Не находил в русскоязычном сегменте разбора подробного как он устроен, так как проект относительно новый, на текущий момент 1.2.1 версия. Будет здорового если получится у тебя сделать по нему видео.
Привет! Можешь подсказать пожалуйста насчёт необходимости использовать OAuth. У меня 2 сервиса(java и php), оба имеют одну и ту же базу данных. Php взаимодействует с frontend(написан на каком-то шаблонизаторе и реакт). Они разрабатывались и жили отдельно, теперь же(в новом этапе) необходимо в frontend добавить(условно) новый раздел, в котором будет отображаться какие-то данные возвращаемые из java сервиса. Так как у каждого сервиса своя авторизация, то юзеру придётся несколько раз авторизоваться, если он захочет зайти и в java раздел и в основные. Я изначально думал сделать java сервисом ресурсов, а php клиентом, а сервисом авторизации бы выступал keycloak, но мне что-то кажется не правильным в таком взаимодействии. Правильно ли так делать? Если нет, то как мне лучше реализовать SSO?
Если обращения к Java-бекенду только из PHP-бекенда, то Java-бекенд можно сделать сервером ресурсов, а PHP-бекенд - клиентом. Если фронт (реакт) может обращаться к обоим бекендам, тогда можно сделать фронт клиентом, а оба бекенда - серверами ресурсов.
@@shurik_codes ещё вопросик :) У меня реакт будет являться публичным клиентом получается? Для того чтоб получить jwt от keycloak, мне нужны креды пользователя и секрет клиента. Я получается прячу секрет клиента на бэкентах и на каждом делаю точку для получения jwt, чтоб реакт мог его получить? Php же по идее будет допускать к своим ресурсам по ключу полученному от java в таком случае?
Нет, немного не так. Реакт будет публичным клиентом, но именно он будет получать ключ доступа, для этого нужен только client id, логин/пароль пользователь будет вводить в Keycloak. После авторизации реакт будет иметь ключ доступа, который будет передавать в запросах к бекендам. А бекенды уже будут валидировать ключ доступа.
Я что то все равно не понял разницу между OAuth 2.0 и OpenID)) И то и то, все спецификации. Но 2.0 имеет абстрактное описание и не подразумевает использование именно JWT. Но OpenId регламентирует использование именно JWT. Как то так что ли?)
OAuth 2.0 - стандарт авторизации, он нужен для предоставления доступа к ресурсу третьему лицу (клиенту) без передачи учётных данных (логина/пароля) владельца ресурса. OAuth 2.0 не регламентирует формат используемых ключей доступа. OpenID Connect (OIDC) - расширение OAuth 2.0 для аутентификации, оно регламентирует дополнительные эндпоинты (информация о пользователе, интроспекция ключей доступа, поиск сервисов и т.д.) и формат токенов (JWT).
Очень трудно объяснять очень просто. Респект!
Очень классный урок, респект! Большое спасибо за труд!)
Непростая, но важная тема. Спасибо за интересную и понятную визуализированную подачу, Александр.
Очень высокий уровень объяснения , безумно доступно в понимании и приятно смотреть ваши видео!
Как раз дошел до этой темы и тут уже видос, очень вовремя))Спасибо огромное!
Спасибо Вам за такие видео. Как бальзам на душу.
Авотризация это конечно очень важно! Недавно осилил создание jwt токена с авторизацией по oauth2 через гугл и все получилось. Ваши советы как писал на почту, очень помогли. Спасибо вам, что стало все получаться по этой теме! Еще бы хотелось разобраться получше с интеграционным тестированием контрллеров и юнит мокито)🙂👍
Как-нибудь обязательно расскажу
топ ютубер! спасибо тебе за твою работу!
Спасибо за материал!
Вот это годнота подъехала
Ставлю лайк, пишу коммент.
Попробуй oidc без keycloak чисто со спринг бутом. Вот тут уже надо поковыряться. А так видео хорош. Лайк
Пробовал, всё работает
Спасибо!
Очень здорово! Про тестирование что-нибудь не планируешь? юнит, интеграционное?
Что-нибудь будет обязательно
публичный клиент не может проходить аутентификацию так как невозможно хранить секретные данные ---- сейчас все это допиливается так что даже консоль разраба не открыть(при попытке все сразу затирается + невозможно сделать вообще ничего кроме как закрыть пустую панель разраба в браузере, простой пример - кассы онлайн, которые работают через браузеры, но это частные случаи.. ) но в целом ролики у вас отличные!
дал бы хоть докер имаджи, подергать хоть эти проги для закрепления, так сказать, а так, конечно, и за это спасибо!
Здравствуйте! Скажите пожалуйста, сталкивались ли вы на практике с реализацией RegisteredClientRepository не в форме InMemoryRegisteredClientRepository ? Верно ли понимаю, что в таком случае, как вариант, потребуется хранить данные клиентов-приложений, участвующих в межсервисном взаимодействии, в БД ?
Да, данные клиентов хранятся в БД, реализация есть стандартная в Spring Authorization Server docs.spring.io/spring-authorization-server/docs/current/api/org/springframework/security/oauth2/server/authorization/client/JdbcRegisteredClientRepository.html
@@shurik_codes Здравствуйте! Вновь подскажите, пожалуйста, верно ли, что в таком случае также потребуется определять в БД модель RegisteredClient(и это, видимо, на стороне сервера авторизации надо будет иметь БД, содержащую данные всех потенциальных приложений-клиентов сервера ресурсов!?) Если это верно, то тогда могут ли значения конкретного экземпляра RegisteredClient, который в данном контексте будет выражать собой отдельно взятый клиент, выступать в качестве client credentials данного клиента ?
Здравствуйте, Александр
Подскажите пожалуйста, планируете ли снять видео урок с реализацией микросервисной архитектуры на примере, с api gateway, итд ? Было бы очень полезно
Спасибо
Планирую)
@@shurik_codes супер, большое спасибо 🤗
Спасибо за материал. Немного непонятно, почему Вы отнесли нативные приложения к "не безопасным".
А это не я, это всё они: datatracker.ietf.org/doc/html/rfc6749#section-2.1
Нативное приложение устанавливается на устройство пользователя, где пользователь с высокой вероятностью может извлечь секретную информацию клиента (Client Secret, JWT, сертификаты) и использовать её в своих целях.
@@shurik_codes , тут все зависит от уровня безопасности, которого придерживались при разработке сервиса и клиента, и от уровня нарушителя. Подавляющее большинство средств защиты, например, ЭП от КриптоПро, ориентированы на защиту от неквалифицированного нарушителя, действующего удаленно без применения спец. средств. И там вполне нормально обеспечивают защиту ключей от подмены и несанкционированного использования)
Хороший человек
Добавь, пожалуйста, этот ролик в плейлист Spring Security в деталях
спасибочки
Отличный ролик, спасибо. 1:09:50- а скажите, для чего включен implisit flow и direct access grant в публичном клиенте, если по факту достаточно standart flow?
Для демонстрации этих способов предоставления полномочий. По факту правильнее всего использовать authorization code grant, он же standard flow
Что Вы за шрифт используете тот рукописный? красивый очень! 😍
Это стандартный шрифт в Excalidraw
@@shurik_codes 🙏🙏
Привет! Отличные видосы, но пожалуйста поставь стандартный шрифт в своих видео. Данный шрифт конечно красивый, но очень трудно его читать и слушать одновременно, поясню так как мы привыкли (со школы) к тексту в шрифте похожему Times New Roman, его наш мозг автоматически интерпретирует , а твой шрифт нужно читать и не всегда успеваешь ( ну медленно я читаю) за словами.
Учту
@@shurik_codesСпасибо 🤝
23:00 Поясните пожалуйста) Вы говорите, что OAuth предназначен для взаимодействия между независимыми приложениями, и если есть свой клиент и свой бекенд, то OAuth не нужен. Но если взять пример мобильных игр с онлайн составляющей - абсолютно везде есть авторизация через гугл, фейсбук и прочее. То же самое часто есть в обычных мобильных приложениях. Т.е. я не могу понять, почему они это используют? Для возможности быстрого логина?
Я не совсем корректно выразился: на мой взгляд использование схемы, когда фронт является OAuth-клиентом, а бек - OAuth-сервером ресурсов, является избыточным, т.к. в этой схеме бек однозначно доверяет фронту. И логичнее, на мой, взгляд выдглядит аутентификация на стороне бека с дальнейшим поддержанием сессии на стороне фронта, это банально дешевле с точки зрения использования ресурсов.
Во многих онлайн-сервисах, в т.ч. и в играх, OAuth/OIDC используется как SSO для быстрой регистрации и входа.
@@shurik_codes все, теперь понял, спасибо!
Привет! Такой вопрос. У себя на проекте надо было вкатить OAuth 2.0 с красивой формочкой. Но не хотелось мучаться с аус флоу на фронте и решили просто через гейтвей прокинуть по /login урлу server-side-renderred формочку, которую даёт спринг. Только ещё кастомизировали, чтобы выглядела, как хотел заказчик: в стиле всего сайта. Как думаешь, это ок решение? Поджимали сроки, заказчику на презентацию проекта нужна была красивая формочка. Есть ли смысл переделывать на "трушный" фронтед и какие минусы у этого подхода (кроме UI составляющей, который придётся менять ещё и в шаблонах таймлифа. если заказчик захочет поменять цвет кнопок)
В целом нормальное решение. В любом случае процесс аутентификации реализуется на стороне бекенда. Единственный недостаток, но весьма условный, заключается в том, что на бекенда есть часть UI. Не совсем понятно, зачем нужна формочка на стороне приложения. Ведь можно сразу пользователя отправлять в сторону сервера OAuth/OIDC. Хотя если есть несколько вариантов аутентификации, то тогда да, формочка нужна.
@@shurik_codes да, забыл сказать: у нас несколько аус серверов от разных контор
просто по опыту, решение это сильно проще, чем заниматься мутью с интеграцией фронта с беком причём с таким запутанным флоу с кучей редиректов и проверок
Насчёт ID токена тоже не понятно. Он же может прилететь внутри body вместе с аксесс токеном, даже если его не запрашивать в явном виде на этапе аутентификации.
Здравствуйте. Я сейчас делаю веб приложение с бэком. Веб будет на реакте. Суть приложения: администратор выкладывает запрос на транспортировку, а компании на него отвечают. Само собой есть регистрация/авторизация. Нужно ли для такого приложения использовать OAuth 2.0 и OpenID Connect? На данный момент всё реализовано на jwt токенах. В видео вы сказали, что особо смысла нет. Можете более детально объяснить почему?
Приветствую! OIDC для аутентификации пользователя в сервисе - да, можно и нужно, если есть используемый сервис единого входа (SSO). Если для фронтенда разработан и бекенд, то тогда для общения между ними проще использовать обычную HTTP-сессию. А вот если фронт обращается к множеству разных сервисов, то тогда для общения между ними есть смысл использовать OAuth/OIDC.
Привет! Очень понравилось видео :) Что думаешь насчет того, чтобы сделать гайд по spring-boot-authorization-server?
Обязательно будет
@@shurik_codes чисто уже моя просьба: сделай пожалуйста, если возможно, с сущностями JPA (GrantType, Client, Scope, AuthenticationMethod, AccessToken, RefreshToken и тд), как по мне - JPA тут в самый раз, из-за огромного кол-ва связей (примеры с JDBC, с офф доки спринга - инконсистентны)
эм) docs.spring.io/spring-authorization-server/reference/guides/how-to-jpa.html
а, вижу, тут не всё
@@shurik_codes тут тоже инконсестенция выходит в некоторых местах (scopes varchar(1000) NOT NULL, когда скоупы через запятую записываются в колонку, а не через связи many to many, например). Хотелось бы увидеть идеальную имплементацию, по всем канонам sql :)
Как происходит 10. Пункт - Добавление события в календарь? То есть как клиент общается с сервисом ресурсов, он из JWT токена берет информацию об правах или или обращается затем к сервису авторизации?
Сервер ресурсов сам парсит JWT и получает из него нужные данные. К серверу авторизации сервер ресурсов обращается для получения ключей, чтобы провалидировать подпись JWT.
Привет!
Разворачиваю spring authorization server, как замену keycloak.
Не находил в русскоязычном сегменте разбора подробного как он устроен, так как проект относительно новый, на текущий момент 1.2.1 версия.
Будет здорового если получится у тебя сделать по нему видео.
Про Spring Authorization Server я как-нибудь расскажу обязательно, но назвать его заменой Keycloak - слишком смелое заявление)
А по SAML будет что-то подобное?
Когда-нибудь
Александр, здравствуйте! Подскажите, пожалуйста, а исходный код выложите?
Да, исходный код будет, но чуть позже, когда его причешу)
@@shurik_codes а где смотреть?
@@shurik_codes Эхх видимо не причесали код?
@@shurik_codes я бы тоже код глянул
Привет! Можешь подсказать пожалуйста насчёт необходимости использовать OAuth. У меня 2 сервиса(java и php), оба имеют одну и ту же базу данных. Php взаимодействует с frontend(написан на каком-то шаблонизаторе и реакт). Они разрабатывались и жили отдельно, теперь же(в новом этапе) необходимо в frontend добавить(условно) новый раздел, в котором будет отображаться какие-то данные возвращаемые из java сервиса. Так как у каждого сервиса своя авторизация, то юзеру придётся несколько раз авторизоваться, если он захочет зайти и в java раздел и в основные. Я изначально думал сделать java сервисом ресурсов, а php клиентом, а сервисом авторизации бы выступал keycloak, но мне что-то кажется не правильным в таком взаимодействии. Правильно ли так делать? Если нет, то как мне лучше реализовать SSO?
Если обращения к Java-бекенду только из PHP-бекенда, то Java-бекенд можно сделать сервером ресурсов, а PHP-бекенд - клиентом. Если фронт (реакт) может обращаться к обоим бекендам, тогда можно сделать фронт клиентом, а оба бекенда - серверами ресурсов.
@@shurik_codes ещё вопросик :) У меня реакт будет являться публичным клиентом получается? Для того чтоб получить jwt от keycloak, мне нужны креды пользователя и секрет клиента. Я получается прячу секрет клиента на бэкентах и на каждом делаю точку для получения jwt, чтоб реакт мог его получить? Php же по идее будет допускать к своим ресурсам по ключу полученному от java в таком случае?
Нет, немного не так. Реакт будет публичным клиентом, но именно он будет получать ключ доступа, для этого нужен только client id, логин/пароль пользователь будет вводить в Keycloak. После авторизации реакт будет иметь ключ доступа, который будет передавать в запросах к бекендам. А бекенды уже будут валидировать ключ доступа.
@@shurik_codes спасибо )
Я что то все равно не понял разницу между OAuth 2.0 и OpenID))
И то и то, все спецификации. Но 2.0 имеет абстрактное описание и не подразумевает использование именно JWT. Но OpenId регламентирует использование именно JWT. Как то так что ли?)
OAuth 2.0 - стандарт авторизации, он нужен для предоставления доступа к ресурсу третьему лицу (клиенту) без передачи учётных данных (логина/пароля) владельца ресурса. OAuth 2.0 не регламентирует формат используемых ключей доступа.
OpenID Connect (OIDC) - расширение OAuth 2.0 для аутентификации, оно регламентирует дополнительные эндпоинты (информация о пользователе, интроспекция ключей доступа, поиск сервисов и т.д.) и формат токенов (JWT).
спецификация oauth 2.0 размазана по 17-20 rfc-шкам