Спасибо, было очень полезно! В начале немного путано про аутентификацию - это просто проверка того, что в систему пытается зайти Вася, а не Петя. Все, никаких прав доступа и разрешений здесь не проверятся, для этого есть следующий шаг - авторизация. Темы для следующих видео - брокеры сообщений (и детальнее про кафку), grpc, мониторинг в микросервисах, особенности работы с Postgres из Spring-приложений
еще один момент: Вы везде пишите слово "Авторизация", по факту неверно применяете этот термин. Аутентификация - это процесс распознания лица/компа на основании предоставленных им данных сравнивая с идентификатором хранящимся в базе на сервере Авторизация - это процесс предоставления прав конкретному лицу По факту, сопровождая токен мы аутентифицируем тот или иной пакет. А уж потом сервер сам, решая задачу авторизацию дает право на информацию или действие или нет, но для пользователя это прозрачно. Сервер внутри , сам, в потрохах выполняет авторизацию. Пользователь лишь может сказать "Хочу удалить у Дяди Васи на счету 1 миллион рублей и зачислить их себе", а уж дать ему такое право или нет это сервер решает :)
Эхх, думал будет детально расскрыта тема авторизации, как и было заявлено в названии видео. По итогу, большая часть была посвящена разбору jwt токена. Хотелось бы улышать в видео с таким названием ответы на такие вопрсы как: 1. Как происходит процесс авторизации в микросервисной архитектуре, а имено в каком месте системы происходит проверка прав пользователя и почему? Например токен проверяется в каждом микросервисе или только в микросервисе авторизации? 2. Как происходит logout пользователя из системы с использованием того же jwt токена?
1. Проверяется всеми, кто рабоает с этим токеном, права выдаются на identity, и уже с этим токеном вы бегаете по всем потребителям 2. Там есть много вариантов как разлогинивать пользователя, обычно это осуществляется путём вызова logout в identity сервиса
sessionid хранят либо в бд, а ещё лучше в in memory db, к примеру редис. Тогда все инстансы будут обращаться к бд и мы можем поставить токену ttl (к примеру в редисе). Но тогда мы конечно допом держим redis, а в случае с jwt нам это не нужно. Но и выпуском токином мы не командуем. К примеру забанили юзера и нужно анулировать его токен. В случае с бд мы просто удалем его, а вот с jwt это сложнее. Тогда тоже придется где то в бд хранить токен, что бы при обращении анулировать.
@@sorokinpavel А вообще как пишут люди из условного бигтеха, то там у них используются внешние сервисы авторизации. То есть там все на много сложнее. Сам я в этом не сильно разбираюсь, только про keycloak знаю : )
Его валидация проиходит на всех уровнях при работе с ним, чем самым обеспечивается безопасность, каждый api сам проверяет валидность, внутри api вы настраиваете работу с jwt токеном
У меня такой вопрос, есть апи гейтвей, сервис с аунтефикацией и авторизацией и несколько сервисов с бизнес логикой, вот как лучше сделать, типо прикаждом запросе бращаться к сервису с аунтефикацией и проверять токен а затем уже идти к бизнес сервисам или на уровне каждого бизнес сервиса ставить проверку токена, вот втором подходе смущает что нужно везде добавлять Spring Security?? спасибо
Используя апи гейтвей у них обычно есть модули по работе с jwt в том числе по их валидации. Тоесть все сервисы с бизнес логикой сидят под гейтвеем, а уже он решает кому можно пройти или нет, ну и соответственно если нужны какие-то данные (например sub) из jwt их можно пробросить, уже из отвалидированного jwt
Как мне кажется, наилучшей практикой является как раз проверка валидности токена на прикладных сервисах. Так можно более гибко подстроить политику безопасности, да и задержка запроса снизится, так как не нужно будет обращаться каждый раз к сервису аутентификации Это если в каждом сервисе локально расположен открытый сертификат Но естественно есть подходы, которые вместо локального сертификата, запрашивают его у сервиса аутентификации Например при реализации OAuth 2.1 совместно с Keycloak. В каждом сервисе существует настройка jwk-set-uri, в которой указывается адрес, по которому можно получить открытый сертификат для возможности последующей проверки валидности токена. Keycloak в целом очень быстро обрабатывает запросы, задержки значительной не добавляет. В общем, подход с такой децентрализированной валидацией токена ещё и разгрузит сервис аутентификации в придачу Поэтому, я бы посоветовал сосредоточиться именно на валидации токена на стороне прикладного сервиса. Пусть это и заставляет дублироваться везде, но выглядит в перспективе получше, как мне кажется
Короче, чтобы расшифровать jwt, каждому сервису нужно знать secret key. И хакеру достаточно упереть этот ключ с одного из сервисов, чтобы ломануть всю систему. Я правильно уловил концепцию?)
Поняли верно) Но есть нюанс. Если используется симметричное шифрование, то потеря ключа сразу ломает всю безопасность. Я рассказывал простой пример с симметричным шифрованием, чтобы не усложнять. На практике же используются ассиметричные алгоритмы с закрытым и открытым ключом. Подписать токен можно только закрытым ключом, который хранится в одном месте (сервисе выдаче токенов). Публичный ключ хранится во всех сервисах и его потеря не критична
@@sorokinpavel вот я к этому и вёл!) Зачем же показывать плохие варианты. Люди будут их использовать. Начнут секретный ключ во все сервисы совать. И за этим ключом будет весьма проблематично следить. Какая-нибудь уязвимость, позволяющая читать файлы, в одном из сервисов сразу навернёт безопасность всей системы.)))
Вообщем - jwt token -- это зашифрованный набор байт, который в себе содержит какую-либо информацию. Зашифрован скорее всего каким-нибудь ассеметричным ключем RSA подобная хня...
Видос конечно интересный, но автор зачем-то сказал, что jwt токен может хранить в себе права доступа. Зачем хранить что-то кроме userid и какой-то другой безобидной инфы? Если тебе нужно в моменте забрать права у юзера, то тебе нужно ждать пока у юзера этот токен протухнет, либо делать хранилище токенов, вносить в чс и тд.
Спасибо за материал, пытаюсь понять смысл использования микросервисов в продакшене, смущает, что в вашем простом примере уже на первом шаге необходим отдельный авторизейшн сервер, что ставит под сомнение всю микро архитектуру приложения, и как итог появляется следующая идея для видео о поддержки транзакций между микросервисами, что-то мне подсказывает, что там также будут костыли с отдельными серверами.
При использовании jwt допустим что клиент хочет удалить заказ по id, как в таком случае проверить принадлежность заказа клиенту? Просто сам факт наличия токена не обезопасит от того, что клиент может узнать id чужого заказа и далее удалит его, используя свой токен
Это нужно проверять в приложении уже, это относится к бизнес логике. Когда пришел запрос - проверить, что данному пользователю разрешено менять данный заказ
@@sorokinpavel а как это можно сделать? Мне пока на ум приходит: 1) Gateway после проверки jwt добавляет userId как заголовок в запрос. Далее order-service проверяет, что userId в заголовке совпадает с user_id в записи с указанным order_id. 2) Парсим jwt на уровне сервиса, order-service будет разбирать JWT, извлекать user_id и проверять, что user_id из токена совпадает с user_id в записи с указанным order_id. Но в таком случае у всех сервисов с таким подходом граница становится больше.
@@redge2129 зачем так сложно? jwt токен может содержать (и часть содержит) внутри себя userId, и уже на стороне api Вы его используете как вашей душе угодно
Спасибо, было очень полезно!
В начале немного путано про аутентификацию - это просто проверка того, что в систему пытается зайти Вася, а не Петя. Все, никаких прав доступа и разрешений здесь не проверятся, для этого есть следующий шаг - авторизация.
Темы для следующих видео - брокеры сообщений (и детальнее про кафку), grpc, мониторинг в микросервисах, особенности работы с Postgres из Spring-приложений
Воу, воу, воу ты куда разошелся, микросервисы, так еще и с авторизацией... таким видео цены нет!
еще один момент:
Вы везде пишите слово "Авторизация", по факту неверно применяете этот термин.
Аутентификация - это процесс распознания лица/компа на основании предоставленных им данных сравнивая с идентификатором хранящимся в базе на сервере
Авторизация - это процесс предоставления прав конкретному лицу
По факту, сопровождая токен мы аутентифицируем тот или иной пакет. А уж потом сервер сам, решая задачу авторизацию дает право на информацию или действие или нет, но для пользователя это прозрачно. Сервер внутри , сам, в потрохах выполняет авторизацию. Пользователь лишь может сказать "Хочу удалить у Дяди Васи на счету 1 миллион рублей и зачислить их себе", а уж дать ему такое право или нет это сервер решает :)
Это мощно 💪
Эхх, думал будет детально расскрыта тема авторизации, как и было заявлено в названии видео. По итогу, большая часть была посвящена разбору jwt токена. Хотелось бы улышать в видео с таким названием ответы на такие вопрсы как:
1. Как происходит процесс авторизации в микросервисной архитектуре, а имено в каком месте системы происходит проверка прав пользователя и почему? Например токен проверяется в каждом микросервисе или только в микросервисе авторизации?
2. Как происходит logout пользователя из системы с использованием того же jwt токена?
1. Проверяется всеми, кто рабоает с этим токеном, права выдаются на identity, и уже с этим токеном вы бегаете по всем потребителям
2. Там есть много вариантов как разлогинивать пользователя, обычно это осуществляется путём вызова logout в identity сервиса
API Gateway
Привет, спасибо за видео, очень информативно, однако с примерами кода было бы вообще супер
Спасибо! Примеры кода будут в другом видео по теории со spring security)
sessionid хранят либо в бд, а ещё лучше в in memory db, к примеру редис. Тогда все инстансы будут обращаться к бд и мы можем поставить токену ttl (к примеру в редисе).
Но тогда мы конечно допом держим redis, а в случае с jwt нам это не нужно. Но и выпуском токином мы не командуем. К примеру забанили юзера и нужно анулировать его токен. В случае с бд мы просто удалем его, а вот с jwt это сложнее. Тогда тоже придется где то в бд хранить токен, что бы при обращении анулировать.
Согласен, есть свои плюсы и минусы
@@sorokinpavel А вообще как пишут люди из условного бигтеха, то там у них используются внешние сервисы авторизации. То есть там все на много сложнее.
Сам я в этом не сильно разбираюсь, только про keycloak знаю : )
15:00 проблема не решается sticky-sessions ?
Решается, как раз и говорил в видео, что нужно запоминать где сохранена сессия
Почему хедер называется Authorization, если токен, который в нем содержится, в первую очередь выполняет функцию аутентификации пользователя?
Думаю просто так исторически сложилось
Стоит ли делать проверку валидности токена и парсинг из него информации только в сервисе auth? А потом уже идти туда куда надо
Его валидация проиходит на всех уровнях при работе с ним, чем самым обеспечивается безопасность, каждый api сам проверяет валидность, внутри api вы настраиваете работу с jwt токеном
проверка валидности по-любому нужна. Иначе зачем вообще выдавать пользователю токен?
Приветствую, почему выбрал именно Java?
Просто что понравилось, то и начал изучать + не сложно в изучении
У меня такой вопрос, есть апи гейтвей, сервис с аунтефикацией и авторизацией и несколько сервисов с бизнес логикой, вот как лучше сделать, типо прикаждом запросе бращаться к сервису с аунтефикацией и проверять токен а затем уже идти к бизнес сервисам или на уровне каждого бизнес сервиса ставить проверку токена, вот втором подходе смущает что нужно везде добавлять Spring Security?? спасибо
Используя апи гейтвей у них обычно есть модули по работе с jwt в том числе по их валидации. Тоесть все сервисы с бизнес логикой сидят под гейтвеем, а уже он решает кому можно пройти или нет, ну и соответственно если нужны какие-то данные (например sub) из jwt их можно пробросить, уже из отвалидированного jwt
@@АлексейХарченко-л8ж спасибо!
Как мне кажется, наилучшей практикой является как раз проверка валидности токена на прикладных сервисах.
Так можно более гибко подстроить политику безопасности, да и задержка запроса снизится, так как не нужно будет обращаться каждый раз к сервису аутентификации
Это если в каждом сервисе локально расположен открытый сертификат
Но естественно есть подходы, которые вместо локального сертификата, запрашивают его у сервиса аутентификации
Например при реализации OAuth 2.1 совместно с Keycloak. В каждом сервисе существует настройка jwk-set-uri, в которой указывается адрес, по которому можно получить открытый сертификат для возможности последующей проверки валидности токена.
Keycloak в целом очень быстро обрабатывает запросы, задержки значительной не добавляет.
В общем, подход с такой децентрализированной валидацией токена ещё и разгрузит сервис аутентификации в придачу
Поэтому, я бы посоветовал сосредоточиться именно на валидации токена на стороне прикладного сервиса.
Пусть это и заставляет дублироваться везде, но выглядит в перспективе получше, как мне кажется
Короче, чтобы расшифровать jwt, каждому сервису нужно знать secret key. И хакеру достаточно упереть этот ключ с одного из сервисов, чтобы ломануть всю систему. Я правильно уловил концепцию?)
Поняли верно)
Но есть нюанс.
Если используется симметричное шифрование, то потеря ключа сразу ломает всю безопасность. Я рассказывал простой пример с симметричным шифрованием, чтобы не усложнять.
На практике же используются ассиметричные алгоритмы с закрытым и открытым ключом. Подписать токен можно только закрытым ключом, который хранится в одном месте (сервисе выдаче токенов). Публичный ключ хранится во всех сервисах и его потеря не критична
@@sorokinpavel вот я к этому и вёл!) Зачем же показывать плохие варианты. Люди будут их использовать. Начнут секретный ключ во все сервисы совать. И за этим ключом будет весьма проблематично следить. Какая-нибудь уязвимость, позволяющая читать файлы, в одном из сервисов сразу навернёт безопасность всей системы.)))
@@leniumso8578 Согласен с вами, но это лишь упрощенный урок по вводу в авторизацию вообще. Все впихнуть тяжело в один ролик
Вообщем - jwt token -- это зашифрованный набор байт, который в себе содержит какую-либо информацию. Зашифрован скорее всего каким-нибудь ассеметричным ключем RSA подобная хня...
Видос конечно интересный, но автор зачем-то сказал, что jwt токен может хранить в себе права доступа. Зачем хранить что-то кроме userid и какой-то другой безобидной инфы? Если тебе нужно в моменте забрать права у юзера, то тебе нужно ждать пока у юзера этот токен протухнет, либо делать хранилище токенов, вносить в чс и тд.
Как тогда твой сервер должен понимать если у тебя права на просмотр информации, если в токене нет информации о роли?
Я сказал, что токен "может" хранить это, но я не говорил, что обязательно надо делать именно так
@@dzenthai очевидно не доверять токену на 100%, для этого существую middleware
Спасибо за материал, пытаюсь понять смысл использования микросервисов в продакшене, смущает, что в вашем простом примере уже на первом шаге необходим отдельный авторизейшн сервер, что ставит под сомнение всю микро архитектуру приложения, и как итог появляется следующая идея для видео о поддержки транзакций между микросервисами, что-то мне подсказывает, что там также будут костыли с отдельными серверами.
При использовании jwt допустим что клиент хочет удалить заказ по id, как в таком случае проверить принадлежность заказа клиенту? Просто сам факт наличия токена не обезопасит от того, что клиент может узнать id чужого заказа и далее удалит его, используя свой токен
Это нужно проверять в приложении уже, это относится к бизнес логике. Когда пришел запрос - проверить, что данному пользователю разрешено менять данный заказ
@@sorokinpavel а как это можно сделать? Мне пока на ум приходит:
1) Gateway после проверки jwt добавляет userId как заголовок в запрос. Далее order-service проверяет, что userId в заголовке совпадает с user_id в записи с указанным order_id.
2) Парсим jwt на уровне сервиса, order-service будет разбирать JWT, извлекать user_id и проверять, что user_id из токена совпадает с user_id в записи с указанным order_id. Но в таком случае у всех сервисов с таким подходом граница становится больше.
@@redge2129 зачем так сложно?
jwt токен может содержать (и часть содержит) внутри себя userId, и уже на стороне api Вы его используете как вашей душе угодно
@@kuroiryuu75 то есть просто токен декодировать и извлекать из него информацию?
@@kuroiryuu75 то есть просто payload из токена декодировать на микросервисе?
12:10 уверены что в оперативной памяти? а если миллионы пользователей?)