Архитектура аутентификации микросервисов с паспортом.

Question

Я пишу игрушку для практических микросервисов и аутентификации на узлах (expressjs).

У меня есть клиент-клиент, служба проверки подлинности и другие службы (они просто отвечают «Привет» до сих пор).

• Клиент будет размещен в CDN.
• Служба аутентификации прослушивает порт 5000 (например)
• Остальные службы прослушивают порт 6000-6100.
• У меня есть redis db для хранения информации о сеансе (маркер oauth, предоставленный твиттером).
• Mongodb, где хранится информация о приложении (не относится к этому вопросу).

Идея состоит в том, что клиент, не прошедший проверку подлинности, отправляется в службу авторизации, нажимая кнопку Twitter (SSO). Затем служба auth получает сгенерированный токен клятвы клятвы и устанавливает этот токен в хранилище redis. Затем токен доступен остальным службам, чтобы они знали, проверен ли запрос или нет, если он уже существует в магазине redis (если пользователь удаляет свою учетную запись, он также будет удален из магазина redis) , Я отправляю токен твитера туда и обратно от клиента к серверу после аутентификации.

Я считаю этот подход довольно прост (как другие используют Nginx прокси-сервер для проверки подлинности, но я не вижу никаких оснований для этого, за исключением, если услуги размещаются в разных доменах, но я не понимаю, это очень хорошо), поэтому я волнуюсь, что я что-то пропустил о безопасности, например.

Вопросы:

1. Является ли это правильный подход?
2. Можно ли делиться токеном Twitter (я так думаю)?
3. Есть ли проблема безопасности, которую я не замечаю здесь?

Answer 1

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

маркер доступа

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

• Когда маркер доступа истекает вы бы вернуть 401 для клиента, из Службы X, с которой вы пытаетесь поговорить.
• Клиент должен вызвать службу Auth обеспечения токенного обновления, получить новый маркер доступ
  • Finaly клиент будет поражая Service X снова с этим новым маркером доступа, имеет это подтверждено и получить ожидаемое ответ от Службы X.

В моих recent assignment я написал микро-сервис, который через прокси-все маркера, используя этот подход, мой прокси обрабатывается все от аутентификации ролей и отправками 401 для истекших лексем и отменив токены обновления и т.д. Я думаю, что это дал мне большее разделение проблем.

Важное примечание: В токен обновления сценария выше моего прокси только будет испытывать нагрузку на инвалидной/выдыхаемого маркер доступа, в то время как в вашем случае любая услуга может быть достигнуто с некорректными лексем ...

Другой подход чтобы Service-A и Service-B вызывали службу auth для проверки токенов, но это привело бы к большему количеству трафика между службами, поскольку каждый запрос HTTP с токеном должен быть проверен. В этом случае также недопустимый запрос токена достигнет вашего Сервиса X и, следовательно, выведет на него некоторую нагрузку ...