OpenID Connect / Oauth2 - кешировать / использовать токены - PullRequest
Новая
       89

OpenID Connect / Oauth2 - кешировать / использовать токены

0 голосов
/ 20 января 2020

У меня есть система с REST API. Пользователи API REST должны иметь возможность проходить аутентификацию с использованием OpenID Connect через Oauth2. Сама система имеет собственную систему разрешений. Мне нужно сопоставить пользователя IDP с моей локальной системой разрешений. Я думаю о сохранении ключа openid scope sub в локальной базе данных в качестве уникального идентификатора пользователя.

Но какой токен я должен вернуть пользователю в API. Должен ли это быть идентификатор доступа oauth2 или token_id из уровня OpenID Connect, или, возможно, оба?

Итак, я вижу эти альтернативы для конечного пользователя API: 

Authorization: Bearer <access_id>

Authorization: Bearer <token_id>

Authorization: Bearer <access_id>
TokenID: <token_id>

Не сохраняя token_id / access_id в системе, мне нужно получить это от клиента для каждого запроса API. Идентификатор токена содержит утверждения (под) JWT, поэтому мне нужно это проверить, что клиент может сделать в моей системе.

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

  • Refre sh token?
  • Access token?
  • ID токена?

Я в основном после аутентификации и идентификации пользователя. Я не получаю доступ к каким-либо внешним ресурсам, кроме этого.

И последний вопрос. Нужно ли проверять токен доступа при каждом запросе к IDP или я могу его кэшировать? Нужно ли проверять токен доступа и идентификатор токена при использовании OpenID Connect?

Редактировать:

Моя система сама имеет REST API и собственную систему разрешений. Система разрешений использует идентификаторы пользователей, данные любой системой аутентификации, использующей OpenID Connect. Первый пользователь добавляется в систему разрешений вручную.

Поток мысли:

  1. Пользователь моей системы запрашивает https://mysystem/login
  2. Пользователь получить перенаправление на https://idp/auth
  3. IDP перенаправляет успешный вход на https://mysystem/callback Моя система получает идентификатор пользователя ( sub ) и электронную почту от токена id JWT.
  4. И обратно к пользователю с токеном доступа (не OID C id токена).
  5. Теперь пользователь может выполнить: curl -H "Авторизация: токен доступа к носителю" https://mysytem/some/resource
  6. Mysytem получает этот запрос от пользователя, но не знает, как сопоставить токен доступа с идентификатором пользователя в базе данных, не запрашивая IDP для идентификатора пользователя.

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

1 Ответ

1 голос
/ 21 января 2020

ОБНОВЛЕНИЕ

Токен доступа имеет идентификатор пользователя - см. шаг 14 этой записи . Как вы думаете, почему это не так?

Единственное исключение из этого правила - когда нет участия пользователя - для связи между приложениями (например, поток учетных данных клиента). Но вы этим не пользуетесь.

ОРИГИНАЛЬНЫЙ ОТВЕТ

Вам просто нужно отправить токен полного доступа (на предъявителя) из пользовательского интерфейса в API - и вам не нужно хранить данные токена в вашей базе данных.

При переходе на архитектуру OAuth пользовательские данные будут храниться в 2 местах:

  • Обычная база данных вашего продукта, часто включающая роли и права пользователя
  • Авторизация Сервер - который генерирует уникальный идентификатор пользователя

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

Несколько постов в моем блоге более подробно освещают эти темы:

Мой блог также ссылается на пример кода , который связывает эти понятия вместе.

...