я просто не до конца понимаю как это работает

я делал авторизацию свою раньше

тут всё понятно - создаешь пользователя сохраняаешь в базу

Ну так тебе пришел токен, по которому ты можешь получить почту юзера или просто использовать его Твиттер ид

потом при логине сверяешь пароли если совпал берешь этого юзера

Это абсолютно не имеет к микросервисам отношения, это что то другое, про что я никогда не слышал

смотри про что я: каждый микросервис это свой модуль, его связь(каплинг) с остальными должен быть минимален, иначе вообще нафига он нужен. Во вторых он должен сам мочь провести транзакцию, при этом синхронно с точки зрения клиента. У него могут быть какие-то побочки, которые выполнятся в будущем, обычно как раз через другие сервисы. В идеале микросервис это свой bounded context, в рамках которого живут связанные агрегаты, которые и являются границами транзакции

т.е. как мне например сохранять записи в базе ассоциированные с этим юзером

Да, но все это в рамках бэкэнда

мне все равно нужно в своей таблице юзеров создать для него запись

Все обращаения клиента имеют повышенные требования к авторизации, валидации, и т д

Да, но все это в рамках бэкэнда

ну так необязательно же

правильно?

Обязательно

т.е. как мне например сохранять записи в базе ассоциированные с этим юзером

Твиттер тебе просто подтверждает что юзер вошел

не могу понять почему тогда

как вы пришли к микросервисам вообще? У меня реальная проблема здесь)

А ты уже сверяешь твиттерид с тем что у тебя в бд и понимаешь кто залогинелся

В первую очередь потому, что это естественный этап в развитии кода

как вы пришли к микросервисам вообще? У меня реальная проблема здесь)

суббота, какая разница что обсуждать, а с умными людьми-то

А переход к тому что ты описываешь не имеет никакого профита

ты про jwt или границы транзакций?)

мне все равно нужно в своей таблице юзеров создать для него запись

Можно запросить у твиттера почту юзера и сохранять по почте

А ты уже сверяешь твиттерид с тем что у тебя в бд и понимаешь кто залогинелся

сорри за тупые вопросы, но я не совсем представляю себе весь процесс

хз, я знаю приложения, где это успешно прижилось, клиент вообще при этом не трогали, ему все равно какие токены гонять

Загугли OAuth 2

и я бы не назвал это усложнением

В например у меня юзеры существуют в только в рамках api

В микросервисах их вообще нет

постепенно чуваки от монолита хорошенько отпиливали куски, которые надо было резко скейлить

Никакой авторизации, ничего

Это просто кусок кода, который что делает, не важно для кого и почему

ну у тебя получается есть центральная точка отказа

Более того, достаточно важно что два разных микросервиса не должны работать с одними и теми же данными

сервис авторизации

ну у тебя получается есть центральная точка отказа

Нет конечно

ну тогда я опять не понял(

API gateway полностью stateless

Их столько, сколько хочется

так а как он авторизирует?

jwt?))))

Загугли OAuth 2

гугл выдает подробности по тому как это внутри работает. Мне это в общем-то не надо знать, потому что за меня эту низкоровневую задачу делает либа (grant)

так а как он авторизирует?

Берет токен из запроса и идет в БД

ахахах, низкоуровневый OAuth 2

))))

меня интересует что мне делать когда я уже авторизовался

Берет токен из запроса и идет в БД

ну чет не очень стейтлес

ахахах, низкоуровневый OAuth 2

что не так?

гугл выдает подробности по тому как это внутри работает. Мне это в общем-то не надо знать, потому что за меня эту низкоровневую задачу делает либа (grant)

Так ты и должен знать что там происходит. Что бы знать что сохранять

Ну БД не стейтлесс, да

Было бы странно если бы БД была стейтлесс

ну я понял твой подход, но тогда если у нас резко растет нагрузка на сервис доставки груза, то нам вместе с ним надо скейлить авторизацию

или еще че

ну т.е. фронт, который чуть сложнее, чем прокся

Растет только нагрузка на базу

это бывает неудобно

Она растет всегда и в любом случае

Это элементрано решается кэшированием

в случае микросервисов у тебя под каждый сервис своя база

Так и есть, условно

ну или что-то изолированное

как это организованно - деталь реализации

но ты можешь их скейлить вместе, грубо говоря

а тут надо еще скейлить всегда "центральный сервис"

это часто не проблема, но бывает проблема

тогда и нужен jwt

jwt это трэш

Неоднократно поднимался вопрос

Оно убивает безопасность

тогда и нужен jwt

или другой стейтлес-токен

Оно убивает безопасность

ну понятно, что у тебя рефреш токены стейтфул будут

а стейтлес на короткий срок

Это делает авторизацию слишком сложной на клиентской стороне

вопрос в том, чтобы экономить в 95% запросах время на хождение за инфой сессии куда-либо

Более того, использование кук является критичным для безопасности

Это делает авторизацию слишком сложной на клиентской стороне

так опять же, вопрос экономики, если на клиенте это решать в итоге дешевле, то так и надо делать

такие случаев КРАЙНЕ мало

но они есть

просто может кто-то пояснить чем отличается флоу когда у меня табличка с юзерами и я их сам аутентифицирую по своей базе данных, от делегированной аутентификации?

Строить такую систему дороже

При этом можно наделать катастрофических ошибок