Обновить токены - хранилище на стороне сервера и отменить для нескольких клиентов

Question

Я начинаю с аутентификации на токенах с использованием ASOS (AspNet.Security.OpenIdConnect.Server).

У меня есть генерация и извлечение токена доступа, и теперь я перехожу к обновлению бит токена.

Мои вопросы:

• Как следует хранить маркер на стороне сервера обновления?
  • Должен ли я просто хранить идентификатор клиента и хэшированный и соленый токен обновления в базе данных (вместе с полями полезности, например, срок годности)?
• Что такое ожидаемое поведение, если пользователь моего API имеет один идентификатор клиента и секретный, но одновременно выполняет множество вызовов (предположим, что они хотят масштабировать клиента на своем конце на нескольких компьютерах, чтобы получить лучшую пропускную способность, например).
  • В частности, я имею в виду, что если 1 токен доступа клиента истекает, но токен обновления также истек? Конечно, они могут перейти к конечной точке маркера, чтобы получить новый токен доступа и обновить токен одновременно, но как же другие экземпляры для этого идентификатора клиента? Предполагая, что их код идентичен (т. Е. Они не обмениваются знаниями токена обновления), каждый экземпляр также будет продолжать запрашивать новый токен доступа и обновления.
  • Если вы сохраняете единственный токен обновления для идентификатора клиента, вы в конечном итоге чрезмерно запрашиваете токены обновления, потенциально каждый раз, когда истекает токен доступа, что было бы нежелательным.
  • Если вы храните несколько токенов обновления для клиента, сколько их разумного числа?

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

Спасибо.

Answer 1

Должен ли я просто хранить идентификатор клиента и хэшированный и соленый токен обновления в базе данных (вместе с полями полезности, например, срок действия)?

Подход, который я рекомендую, заключается в использовании идентификатора билета, прилагаемого ASOS ко всем маркерам, которые он создает. Вы можете получить идентификатор токена обновления и дату истечения срока от события SerializeRefreshToken через context.Ticket.GetTokenId() и context.Ticket.ExpiresUtc.

Примечание: идентификатор по умолчанию является идентификатором GUID, но вы можете его заменить, используя context.Ticket.SetTokenId("token identifier").

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

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

Кроме того, что является общим процессом отзыва токенов обновления? Это так просто, как просто удалить его из того места, где вы его храните?

Если вы используете формат токена по умолчанию (более чем рекомендуется), токены обновления считаются действительными до истечения срока их действия. Вам решать проверить, был ли токен отменен с HandleTokenRequest, выполнив поиск в БД (вы можете получить идентификатор токена обновления с помощью context.Ticket.GetTokenId())