Рекомендуемый способ передачи информации о пользователях (токен id) на серверы ресурсов в контексте OpenId Connect - PullRequest
Новая
       39

Рекомендуемый способ передачи информации о пользователях (токен id) на серверы ресурсов в контексте OpenId Connect

0 голосов
/ 21 февраля 2020

В контексте следующих сервисов:

  • API Gateway / OID C клиент: подключиться к внешнему провайдеру OpenId Connect (для получения доступа, обновить sh и токены id) и выступать в качестве прокси для пересылки запросов другим службам с токеном доступа (поток кода авторизации)
  • Несколько серверов ресурсов, входящие запросы обрабатываются шлюзом API и включают токен доступа (для проверки с использованием ключей, предоставляемых провайдер OID C)

Я использую библиотеки клиент-серверных ресурсов Spring Security 5.2 Oauth2.

Какой рекомендуемый безопасный способ обеспечить работу всех серверов ресурсов осведомлен о пользовательской информации (включена в токен API).

Я оцениваю несколько вариантов:

  1. Включите id_token в запрос, отправленный сервисам. Затем каждая служба может проверять токен (в фильтре).
  2. Заставить API-шлюз выступать в роли эмитента токена для создания нового расширенного токена. Серверы ресурсов должны будут проверить полученный токен с новым ключом, предоставленным поставщиком шлюза / токена API. С этим решением должен быть реализован пользовательский AuthenticationManager.

Я думаю, что вариант 2 является более безопасным и перспективным, есть ли недостатки, которые я должен рассмотреть? Также возможны другие варианты.

1 Ответ

0 голосов
/ 21 февраля 2020

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

  • Open Id Connect Provider (OICP) выдает токены клиенту и выполняет всю глубокую работу, такую ​​как аудит выданных токенов + пользовательский интерфейс для управления ими
  • Клиент отправляет токен доступа на сервер ресурсов через API-шлюз
  • API-шлюз проверяет токен доступа, который может включать в себя вызов самоанализа OICP
  • API-шлюз может отправлять токен доступа в информацию пользователя конечная точка OICP для получения информации о пользователе, а затем перенаправления ее на серверы ресурсов - возможно, через заголовки
  • Шлюз API можно настроить для кэширования заявок (токен + сведения о пользователе) для последующих вызовов с тем же токеном доступа
  • Серверы ресурсов иногда работают в заблокированном Виртуальном частном облаке и не требуют повторной проверки токена доступа (если вы уверены, что это безопасно)

AWS API Gateway работает так же это при вызове лямбда-функций. Мне действительно нравится шаблон с точки зрения расширяемости, и он также может использоваться в автономных API.

Моя запись может дать вам некоторые идеи, наряду с образцом кода авторизатора и классом, который выполняет OAuth .

...