Реализация хранилища Identity Server без памяти - это нормально, если SubjectId является точным идентификатором таблицы базы данных?

Question

По сравнению с большим уникальным числом, являющимся субъектом по умолчанию, очень ли плохо, если я просто сохраню там столбец первичного ключа? Для некоторых пользователей это значение будет 1, для других - 9480, но вряд ли оно когда-либо будет таким огромным, как значение subjectId по умолчанию. Это столбец автоидентификации, поэтому вы можете представить, как он себя ведет.

Если это плохая практика, объясните, пожалуйста, почему, поскольку я не вижу причины для заполнения дополнительного столбца этими атрибутами. , Токен должен быть защищен подписью, чтобы они не могли этим злоупотреблять?

Answer 1

Из спецификации :

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

Таким образом, идентификатор пользователя подходит идеально, что также является значением по умолчанию, используемым для sub. И вы свободны в том, как реализовать Id (например, Guid или int). Но есть еще кое-что в спецификации:

Два типа Идентификатора субъекта определены этой спецификацией:

publi c

Это обеспечивает тот же самый sub (субъект ) значение для всех клиентов. Это значение по умолчанию, если поставщик не имеет элемента subject_types_supported в своем документе обнаружения.

попарно

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

IdentityServer использует public сабы по умолчанию. Если вас беспокоит конфиденциальность, вы можете переключиться на pairwise подпрограмм.

Однако, на данный момент указанные клиентом темы c не поддерживаются IdentityServer. Похоже, что это запланировано на будущий выпуск, так как обсуждается здесь .