я просмотрел 10 видео на данную тему но ваше пояснение оказалось самым понятным, логичным и доступным. Благодарю за информацию !

Спасибо, хорошее видео. Все очень доступно рассказали)

Отличное видео! Действительно из-за терминов казалось очень сложным. Спасибо

вы не поверите, это первый видос с более менее адекватным объяснением возможно,конечно, мне уже так кажется, после многочасового рытья в материале, но все равно, весьма доходчиво) помог наглядный пример с вк и аудиозаписями но вопрос возник, в случае с OpenId Connect мы получается одновременно даем права этому стороннему приложению для доступа к аудио, и в то же время "делегированно логинимся" в этом приложении, с использованием данных от OpenId Provider?

@user-el7yc3qe3h

2 жыл бұрын

Это полезное приложение или наоборот

@OlegTar

7 ай бұрын

Да, делегировано логинимся тоже

Grant Credential flow - это не когда мы отдаем свой логин, пароль приложению, а когда оно имеет СВОИ логин, пароль и получает токен и действует от имени себя. Не от имени пользователя. Например, это можно использовать, чтобы периодически без участия пользователя, что-то получить с сервиса авторизации.

Гибрид Флоу создан для плавного перехода с implicit flow на authorization flow, так как implicit flow не считается безопасносным А так доклад отличный

Если у меня фронтенд на react и отдельный бекенд, и я планирую сохранять токен в куках react, а не создавать отдельное хранилище access token-ов на бекенде, нормально ли будет использовать Implicit flow без client code? Я просто не понимаю, в каком случае он нужен? Если бекенд (что-то по типу Spring MVC) не является Rest API, а является Web MVC, генерируя в ответ фрагмент страницы с данными (типо он у себя хранит сессионные данные, а не в куках клиента)?

А как он работает с ТУЗами?

Если на телефоне иконка openID и его удалить нельзя то это плохо или забить на него все что я хотела узнать

Спасибо, очень многое прояснили! Просьба: приводите исходные английские понятия в паре с их точными русскими переводами вместо смешений на рунглиш. Например: claims[kleɪms] - утверждения вместо claim'ы. А то ваши слушатели будут знать рутермины, но не иметь ясного понятия :)

Ни в одном видео почему то не говорится, как валидируется JWT

@OlegTar

7 ай бұрын

Достаточно прочитать по какому принципу составляется подпись, тогда понятно будет как валидировать. Ну и библиотеки уже всё валидируют сами. А принцип там простой: Если у нас ассиметричное шифрование, то берется заголовок и тело (оба в base64url), соединённые точкой, получаем от них sha хэш и шифруем приватным ключом. Получившаяся подпись переводится в base64url И добавляется в jwt токен Валидация: Берём публичный ключ, декодируем base64url подписи, расшифроываем подпись публичным ключом, берём заголок.тело, берём от них sha-хэш и сравниваем с тем, что получили в подписи. Если используется симметричное шифрование, То подпись получается так: Заголовок.тело (оба в base64url между ними точка), Берем от этого sha-хэш, шифруем этот хэш симметричным ключом, кодируем в base64url, подпись готова Валидация. Берём заголовок и тело (оба в base64url), соединённые точкой, берём от них sha хэш Берём подпись, расшифровываем симметричным ключом, сравниваем, что получили, с хэшем полученным выше.

@OlegTar

7 ай бұрын

Подробности в RFC 7515

@user-sy4yz3kw4y

7 ай бұрын

@@OlegTar огромное спасибо за такое подробное объяснение!

@OlegTar

7 ай бұрын

@@user-sy4yz3kw4y не за что

не путаешь аутентификацию с авторизацией? kzread.info/dash/bejne/fZ991dBwktm7krQ.html

А с фигали у меня появилась openid ?

@user-ob2yc2ju3f

2 жыл бұрын

Иконка есть удалить нельзя

@redcat2469

2 жыл бұрын

@@user-ob2yc2ju3f ага

@user-fb1fs5uk4s

2 жыл бұрын

@@redcat2469 ну как , удалил ?

@user-fb1fs5uk4s

2 жыл бұрын

Ну как , удалил ?