Основы OAuth 2.0 и OpenID Connect

Рет қаралды 6,426

6 ай бұрын

При необходимости передачи данных пользователя сторонним приложениям надо как-то решать вопрос доступа - как предоставлять доступ к данным, не передавая стороннему приложения учётные данные пользователя - логин, пароль и т.д. И основным способом решения этого вопроса является фреймворк авторизации 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

Пікірлер: 57

@Volosha1337 4 ай бұрын

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

@Worraner 6 күн бұрын

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

@Devivl 3 ай бұрын

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

@user-hd8sc3ux7i 2 ай бұрын

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

@drugsbunny_8641 5 ай бұрын

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

@vla-zav 5 ай бұрын

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

@globalist1877 5 ай бұрын

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

@dmitrylanin7812 Ай бұрын

Спасибо!

@svyatoiambrozii 5 ай бұрын

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

@shurik_codes 5 ай бұрын

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

@eduardklygunov1412 5 ай бұрын

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

@e-researcher Ай бұрын

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

@zed6204 Ай бұрын

спасибочки

@ruslanalmukanov3338 5 ай бұрын

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

@shurik_codes 5 ай бұрын

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

@omonullo 5 ай бұрын

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

@shurik_codes 2 ай бұрын

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

@homersimpson297 3 ай бұрын

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

@e-researcher Ай бұрын

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

@artemief 5 ай бұрын

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

@shurik_codes 5 ай бұрын

Планирую)

@artemief 5 ай бұрын

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

@kazbo4431 5 ай бұрын

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

@shurik_codes 5 ай бұрын

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

@kazbo4431 5 ай бұрын

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

@shurik_codes 5 ай бұрын

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

@shurik_codes 5 ай бұрын

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

@kazbo4431 5 ай бұрын

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

@igormartynkin298 5 ай бұрын

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

@shurik_codes 5 ай бұрын

Учту

@igormartynkin298 5 ай бұрын

@@shurik_codesСпасибо 🤝

@user-up2lc4kb5o 5 ай бұрын

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

@shurik_codes 5 ай бұрын

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

@user-up2lc4kb5o 5 ай бұрын

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

@user-ib8rv1vr4r 5 ай бұрын

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

@shurik_codes 5 ай бұрын

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

@user-ib8rv1vr4r 5 ай бұрын

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

@user-ib8rv1vr4r 5 ай бұрын

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

@dmitrys7170 4 ай бұрын

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

@shurik_codes 4 ай бұрын

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

@zero-ix3bz 5 ай бұрын

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

@shurik_codes 5 ай бұрын

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

@user-ub5yg5sf6z 26 күн бұрын

Вы планируете выложить код проекта в репозиторий?

@shurik_codes 26 күн бұрын

Да, есть в планах

@user-pg5yb8vq7t 5 ай бұрын

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

@shurik_codes 5 ай бұрын

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

@user-lg9wf8sy9t 5 ай бұрын

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

@shurik_codes 2 ай бұрын

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

@user-rg6ns5hq1b 2 ай бұрын

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

@shurik_codes Ай бұрын

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

@user-rg6ns5hq1b Ай бұрын

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

@shurik_codes Ай бұрын

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

@user-rg6ns5hq1b Ай бұрын

@@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).