Как правильно определить пользователя во время предоставления refresh_token? - PullRequest
0 голосов
/ 30 октября 2019

У меня есть центральный «хаб», содержащий данные для нескольких организаций, каждая из которых содержит несколько пользователей. Организации и пользователи группируются вместе вместе с client_credentials в рамках проекта. Пользователь может аутентифицироваться, используя тип предоставления «пароль», и он получает токен доступа и обновления согласно спецификации OAuth2. И то, и другое - JWT.

Проблема, с которой я столкнулся, заключается в правильном присвоении токена обновления соответствующему пользователю «правильным» образом, чтобы я мог выдать токен доступа JWT с правильным содержимым.

Когдазапрашивая оригинальные токены, я передаю и проверяю как учетные данные клиента, так и имя пользователя / пароль пользователя. Генерируются два идентичных (кроме времени истечения) токена, содержащие user_id и другие биты. Один для доступа, другой для обновления.

Поэтому, проверяя токен обновления, я вижу (если мое понимание неверно) несколько способов сделать это:

  • По первому запросу сохраните refresh_token для записи базы данных пользователя и выполните поиск на основе связи с учетными данными клиента, а также с этим сохраненным токеном. ИЛИ:

  • Создайте новый токен доступа из распакованного refresh_token, просто с новой датой истечения срока действия - это означает, что мне не нужно на самом деле сохранять эти вещи.

В некоторых отношениях первый подход кажется нормальным, за исключением моего нежелания выполнять запросы к базе данных, используя любой тип пароля / токена, поскольку обычно я никогда не индексирую эти поля. И с другой стороны, второй подход кажется приемлемым, так как он фактически не требует от меня сохранения чувствительных токенов, если я не хочу явно пометить его для отзыва - но он требует, чтобы access_token и refresh_token оставались практически одинаковыми.

Есть ли у кого правильный подход или у кого-нибудь есть альтернативы?

1 Ответ

0 голосов
/ 30 октября 2019

Используя тип «Предоставление пароля», вы генерируете / получаете два токена: токен доступа и токен обновления. Эти токены должны надежно храниться либо в таблице памяти вашего приложения, либо в базе данных. Если вы используете автомасштабирование или отказоустойчивый дизайн, вам необходимо использовать базу данных.

Получив токены, вы создаете случайное число opaque (обычно 128-битное, иногда 64-битное)давайте назовем это AUTH_ID. Жетоны плюс срок действия индексируются этим AUTH_ID. Вы сохраняете AUTH_ID в сеансе браузера клиента или возвращаетесь с токенами. Если дизайн уже существует, вам нужно будет создать метод для поиска в базе данных, чтобы он соответствовал переданным вам токенам. Если пользователь на самом деле не требует токенов, вместо этого дайте ему AUTH_ID.

Когда клиент отправляет вам запрос, извлеките AUTH_ID из сеанса клиента и найдите токены. Если срок действия токена скоро истечет, обновите его и сохраните новый токен. Затем продолжите выполнение запроса клиента.

Содержимое маркера обновления зависит от реализации. Это означает, что если вы хотите полагаться на информацию о токене обновления (или токене доступа), вы должны хранить эту информацию вместе с токеном. Некоторые токены - Signed-JWT, некоторые - непрозрачные.

...