ไม่สามารถเล่นวิดีโอนี้
ขออภัยในความไม่สะดวก
Основы OAuth 2.0 и OpenID Connect
ฝัง
- เผยแพร่เมื่อ 19 ธ.ค. 2023
- При необходимости передачи данных пользователя сторонним приложениям надо как-то решать вопрос доступа - как предоставлять доступ к данным, не передавая стороннему приложения учётные данные пользователя - логин, пароль и т.д. И основным способом решения этого вопроса является фреймворк авторизации OAuth, который добавляет в эту схему сервер авторизации, а так же описывает сценарии взаимодействия между участниками для безопасного предоставления доступа сторонним приложениям к пользовательским данным.
OpenID Connect - это слой идентификации и аутентификации, разработанный на основе OAuth и совместимый с ним. OIDC вводит идентификационный токен (ID Token), специфичные области применения (scope) ключей доступа, JWT и дополнительные эндпоинты. Спецификация OAuth довольно абстрактна, а OIDC - более конкретна, поэтому я в данном ролике рассматриваю OAuth именно на примере OIDC.
В этом ролике я рассказываю об основах OAuth и OIDC: ролях, ключах доступа, клиентах, областях применения ключей доступа и способах предоставления доступа к защищённым ресурсам.
00:01:12 Пример без OAuth
00:04:55 Теория OAuth и OpenID Connect
00:20:52 Способы предоставления полномочий (Grant)
00:24:36 Authorization Code Grant
00:35:45 PKCE - Proof Key for Code Exchange
00:42:14 Hybrid Flow (OIDC)
00:46:07 Implicit Grant
00:49:47 Resource Owner Password Credentials Grant
00:52:51 Client Credentials Grant
00:56:07 Device Authorization Grant
01:04:24 Выводы по способам предоставления полномочий
OAuth 2.0 RFC 6749 datatracker.ietf.org/doc/html...
OpenID Connect 1.0 Core openid.net/specs/openid-conne...
PKCE RFC 7636 datatracker.ietf.org/doc/html...
OAuth 2.0 Device Authorization Grant RFC 8628 datatracker.ietf.org/doc/html...
#oauth #oidc #openidconnect
Мой сайт: alexkosarev.name/
Паблик в VK: public218833461
Канал в Telegram: t.me/+TZCuO38vG3oqu_Jq
Стать доном: donut/shurik.codes
Донаты в Boosty: boosty.to/akosarev/purchase/1...
Донаты в Tinkoff: www.tinkoff.ru/cf/4PEOiVCZQuS
Очень высокий уровень объяснения , безумно доступно в понимании и приятно смотреть ваши видео!
Непростая, но важная тема. Спасибо за интересную и понятную визуализированную подачу, Александр.
Как раз дошел до этой темы и тут уже видос, очень вовремя))Спасибо огромное!
Спасибо за материал!
Очень классный урок, респект! Большое спасибо за труд!)
Спасибо Вам за такие видео. Как бальзам на душу.
Спасибо!
Вот это годнота подъехала
Ставлю лайк, пишу коммент.
Авотризация это конечно очень важно! Недавно осилил создание jwt токена с авторизацией по oauth2 через гугл и все получилось. Ваши советы как писал на почту, очень помогли. Спасибо вам, что стало все получаться по этой теме! Еще бы хотелось разобраться получше с интеграционным тестированием контрллеров и юнит мокито)🙂👍
Как-нибудь обязательно расскажу
спасибочки
Попробуй oidc без keycloak чисто со спринг бутом. Вот тут уже надо поковыряться. А так видео хорош. Лайк
Пробовал, всё работает
дал бы хоть докер имаджи, подергать хоть эти проги для закрепления, так сказать, а так, конечно, и за это спасибо!
Очень здорово! Про тестирование что-нибудь не планируешь? юнит, интеграционное?
Что-нибудь будет обязательно
Добавь, пожалуйста, этот ролик в плейлист Spring Security в деталях
Отличный ролик, спасибо. 1:09:50- а скажите, для чего включен implisit flow и direct access grant в публичном клиенте, если по факту достаточно standart flow?
Для демонстрации этих способов предоставления полномочий. По факту правильнее всего использовать authorization code grant, он же standard flow
Насчёт ID токена тоже не понятно. Он же может прилететь внутри body вместе с аксесс токеном, даже если его не запрашивать в явном виде на этапе аутентификации.
Привет! Отличные видосы, но пожалуйста поставь стандартный шрифт в своих видео. Данный шрифт конечно красивый, но очень трудно его читать и слушать одновременно, поясню так как мы привыкли (со школы) к тексту в шрифте похожему Times New Roman, его наш мозг автоматически интерпретирует , а твой шрифт нужно читать и не всегда успеваешь ( ну медленно я читаю) за словами.
Учту
@@shurik_codesСпасибо 🤝
Здравствуйте, Александр
Подскажите пожалуйста, планируете ли снять видео урок с реализацией микросервисной архитектуры на примере, с api gateway, итд ? Было бы очень полезно
Спасибо
Планирую)
@@shurik_codes супер, большое спасибо 🤗
Привет! Такой вопрос. У себя на проекте надо было вкатить OAuth 2.0 с красивой формочкой. Но не хотелось мучаться с аус флоу на фронте и решили просто через гейтвей прокинуть по /login урлу server-side-renderred формочку, которую даёт спринг. Только ещё кастомизировали, чтобы выглядела, как хотел заказчик: в стиле всего сайта. Как думаешь, это ок решение? Поджимали сроки, заказчику на презентацию проекта нужна была красивая формочка. Есть ли смысл переделывать на "трушный" фронтед и какие минусы у этого подхода (кроме UI составляющей, который придётся менять ещё и в шаблонах таймлифа. если заказчик захочет поменять цвет кнопок)
В целом нормальное решение. В любом случае процесс аутентификации реализуется на стороне бекенда. Единственный недостаток, но весьма условный, заключается в том, что на бекенда есть часть UI. Не совсем понятно, зачем нужна формочка на стороне приложения. Ведь можно сразу пользователя отправлять в сторону сервера OAuth/OIDC. Хотя если есть несколько вариантов аутентификации, то тогда да, формочка нужна.
@@shurik_codes да, забыл сказать: у нас несколько аус серверов от разных контор
просто по опыту, решение это сильно проще, чем заниматься мутью с интеграцией фронта с беком причём с таким запутанным флоу с кучей редиректов и проверок
Здравствуйте. Я сейчас делаю веб приложение с бэком. Веб будет на реакте. Суть приложения: администратор выкладывает запрос на транспортировку, а компании на него отвечают. Само собой есть регистрация/авторизация. Нужно ли для такого приложения использовать OAuth 2.0 и OpenID Connect? На данный момент всё реализовано на jwt токенах. В видео вы сказали, что особо смысла нет. Можете более детально объяснить почему?
Приветствую! OIDC для аутентификации пользователя в сервисе - да, можно и нужно, если есть используемый сервис единого входа (SSO). Если для фронтенда разработан и бекенд, то тогда для общения между ними проще использовать обычную HTTP-сессию. А вот если фронт обращается к множеству разных сервисов, то тогда для общения между ними есть смысл использовать OAuth/OIDC.
23:00 Поясните пожалуйста) Вы говорите, что OAuth предназначен для взаимодействия между независимыми приложениями, и если есть свой клиент и свой бекенд, то OAuth не нужен. Но если взять пример мобильных игр с онлайн составляющей - абсолютно везде есть авторизация через гугл, фейсбук и прочее. То же самое часто есть в обычных мобильных приложениях. Т.е. я не могу понять, почему они это используют? Для возможности быстрого логина?
Я не совсем корректно выразился: на мой взгляд использование схемы, когда фронт является OAuth-клиентом, а бек - OAuth-сервером ресурсов, является избыточным, т.к. в этой схеме бек однозначно доверяет фронту. И логичнее, на мой, взгляд выдглядит аутентификация на стороне бека с дальнейшим поддержанием сессии на стороне фронта, это банально дешевле с точки зрения использования ресурсов.
Во многих онлайн-сервисах, в т.ч. и в играх, OAuth/OIDC используется как SSO для быстрой регистрации и входа.
@@shurik_codes все, теперь понял, спасибо!
Привет! Очень понравилось видео :) Что думаешь насчет того, чтобы сделать гайд по 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.
Привет! Можешь подсказать пожалуйста насчёт необходимости использовать 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 спасибо )
Александр, здравствуйте! Подскажите, пожалуйста, а исходный код выложите?
Да, исходный код будет, но чуть позже, когда его причешу)
Спасибо за материал. Немного непонятно, почему Вы отнесли нативные приложения к "не безопасным".
А это не я, это всё они: datatracker.ietf.org/doc/html/rfc6749#section-2.1
Нативное приложение устанавливается на устройство пользователя, где пользователь с высокой вероятностью может извлечь секретную информацию клиента (Client Secret, JWT, сертификаты) и использовать её в своих целях.
@@shurik_codes , тут все зависит от уровня безопасности, которого придерживались при разработке сервиса и клиента, и от уровня нарушителя. Подавляющее большинство средств защиты, например, ЭП от КриптоПро, ориентированы на защиту от неквалифицированного нарушителя, действующего удаленно без применения спец. средств. И там вполне нормально обеспечивают защиту ключей от подмены и несанкционированного использования)
Привет!
Разворачиваю spring authorization server, как замену keycloak.
Не находил в русскоязычном сегменте разбора подробного как он устроен, так как проект относительно новый, на текущий момент 1.2.1 версия.
Будет здорового если получится у тебя сделать по нему видео.
Про Spring Authorization Server я как-нибудь расскажу обязательно, но назвать его заменой Keycloak - слишком смелое заявление)
А по SAML будет что-то подобное?
Когда-нибудь
Я что то все равно не понял разницу между OAuth 2.0 и OpenID))
И то и то, все спецификации. Но 2.0 имеет абстрактное описание и не подразумевает использование именно JWT. Но OpenId регламентирует использование именно JWT. Как то так что ли?)
OAuth 2.0 - стандарт авторизации, он нужен для предоставления доступа к ресурсу третьему лицу (клиенту) без передачи учётных данных (логина/пароля) владельца ресурса. OAuth 2.0 не регламентирует формат используемых ключей доступа.
OpenID Connect (OIDC) - расширение OAuth 2.0 для аутентификации, оно регламентирует дополнительные эндпоинты (информация о пользователе, интроспекция ключей доступа, поиск сервисов и т.д.) и формат токенов (JWT).