вы не поверите, это первый видос с более менее адекватным объяснением возможно,конечно, мне уже так кажется, после многочасового рытья в материале, но все равно, весьма доходчиво) помог наглядный пример с вк и аудиозаписями но вопрос возник, в случае с OpenId Connect мы получается одновременно даем права этому стороннему приложению для доступа к аудио, и в то же время "делегированно логинимся" в этом приложении, с использованием данных от OpenId Provider?
Если у меня фронтенд на react и отдельный бекенд, и я планирую сохранять токен в куках react, а не создавать отдельное хранилище access token-ов на бекенде, нормально ли будет использовать Implicit flow без client code? Я просто не понимаю, в каком случае он нужен? Если бекенд (что-то по типу Spring MVC) не является Rest API, а является Web MVC, генерируя в ответ фрагмент страницы с данными (типо он у себя хранит сессионные данные, а не в куках клиента)?
Grant Credential flow - это не когда мы отдаем свой логин, пароль приложению, а когда оно имеет СВОИ логин, пароль и получает токен и действует от имени себя. Не от имени пользователя. Например, это можно использовать, чтобы периодически без участия пользователя, что-то получить с сервиса авторизации.
Достаточно прочитать по какому принципу составляется подпись, тогда понятно будет как валидировать. Ну и библиотеки уже всё валидируют сами. А принцип там простой: Если у нас ассиметричное шифрование, то берется заголовок и тело (оба в base64url), соединённые точкой, получаем от них sha хэш и шифруем приватным ключом. Получившаяся подпись переводится в base64url И добавляется в jwt токен Валидация: Берём публичный ключ, декодируем base64url подписи, расшифроываем подпись публичным ключом, берём заголок.тело, берём от них sha-хэш и сравниваем с тем, что получили в подписи. Если используется симметричное шифрование, То подпись получается так: Заголовок.тело (оба в base64url между ними точка), Берем от этого sha-хэш, шифруем этот хэш симметричным ключом, кодируем в base64url, подпись готова Валидация. Берём заголовок и тело (оба в base64url), соединённые точкой, берём от них sha хэш Берём подпись, расшифровываем симметричным ключом, сравниваем, что получили, с хэшем полученным выше.
Спасибо, очень многое прояснили! Просьба: приводите исходные английские понятия в паре с их точными русскими переводами вместо смешений на рунглиш. Например: claims[kleɪms] - утверждения вместо claim'ы. А то ваши слушатели будут знать рутермины, но не иметь ясного понятия :)
я просмотрел 10 видео на данную тему но ваше пояснение оказалось самым понятным, логичным и доступным. Благодарю за информацию !
Спасибо, хорошее видео. Все очень доступно рассказали)
Отличное видео! Действительно из-за терминов казалось очень сложным. Спасибо
Гибрид Флоу создан для плавного перехода с implicit flow на authorization flow, так как implicit flow не считается безопасносным
А так доклад отличный
вы не поверите, это первый видос с более менее адекватным объяснением
возможно,конечно, мне уже так кажется, после многочасового рытья в материале, но все равно, весьма доходчиво)
помог наглядный пример с вк и аудиозаписями
но вопрос возник, в случае с OpenId Connect мы получается одновременно даем права этому стороннему приложению для доступа к аудио, и в то же время "делегированно логинимся" в этом приложении, с использованием данных от OpenId Provider?
Это полезное приложение или наоборот
Да, делегировано логинимся тоже
«самым секьюрным»... Ну не забывайте русские слова-то. А так видео прекрасное, действительно понятно рассказано.
Если у меня фронтенд на react и отдельный бекенд, и я планирую сохранять токен в куках react, а не создавать отдельное хранилище access token-ов на бекенде, нормально ли будет использовать Implicit flow без client code? Я просто не понимаю, в каком случае он нужен? Если бекенд (что-то по типу Spring MVC) не является Rest API, а является Web MVC, генерируя в ответ фрагмент страницы с данными (типо он у себя хранит сессионные данные, а не в куках клиента)?
Grant Credential flow
- это не когда мы отдаем свой логин, пароль приложению, а когда оно имеет СВОИ логин, пароль и получает токен и действует от имени себя. Не от имени пользователя.
Например, это можно использовать, чтобы периодически без участия пользователя, что-то получить с сервиса авторизации.
А как он работает с ТУЗами?
Ни в одном видео почему то не говорится, как валидируется JWT
Достаточно прочитать по какому принципу составляется подпись, тогда понятно будет как валидировать.
Ну и библиотеки уже всё валидируют сами.
А принцип там простой:
Если у нас ассиметричное шифрование, то берется заголовок и тело (оба в base64url), соединённые точкой, получаем от них sha хэш и шифруем приватным ключом.
Получившаяся подпись переводится в base64url
И добавляется в jwt токен
Валидация:
Берём публичный ключ, декодируем base64url подписи, расшифроываем подпись публичным ключом, берём заголок.тело, берём от них sha-хэш и сравниваем с тем, что получили в подписи.
Если используется симметричное шифрование,
То подпись получается так:
Заголовок.тело (оба в base64url между ними точка), Берем от этого sha-хэш, шифруем этот хэш симметричным ключом, кодируем в base64url, подпись готова
Валидация.
Берём заголовок и тело (оба в base64url), соединённые точкой, берём от них sha хэш
Берём подпись, расшифровываем симметричным ключом, сравниваем, что получили, с хэшем полученным выше.
Подробности в RFC 7515
@@OlegTar огромное спасибо за такое подробное объяснение!
@@ПавелАвдеев не за что
Спасибо, очень многое прояснили!
Просьба: приводите исходные английские понятия в паре с их точными русскими переводами вместо смешений на рунглиш.
Например: claims[kleɪms] - утверждения вместо claim'ы.
А то ваши слушатели будут знать рутермины, но не иметь ясного понятия :)
Если на телефоне иконка openID и его удалить нельзя то это плохо или забить на него все что я хотела узнать
не путаешь аутентификацию с авторизацией? ruclips.net/video/KkIsn7bvUbQ/видео.html
путает, путает. :)
А с фигали у меня появилась openid ?
Иконка есть удалить нельзя
@@СашаСтрельник-т2н ага
@@redcat2469 ну как , удалил ?
Ну как , удалил ?