Хранить пользовательские данные на сервере авторизации или на сервере ресурсов?Или оба?

Question

Я впервые настраиваю OpenID Connect с IdentityServer 4 и AspNetIdentity, и я надеялся, что кто-то сможет демистифицировать часть о хранении пользовательских данных.

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

В настоящее время у меня есть модель данных, которая выглядитнапример:

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

Это такой элементарный вопрос об архитектуре, но действительно трудно найти хороший ответ, который имеет смысл и не имеет смысла.т полный взлом.До сих пор я читал о следующих решениях от разных людей:

1. Сохраните все пользовательские данные только в Auth db, а затем установите API на сервере Auth, чтобы ResourceСервер может получать данные с сервера Auth.

2. Кто-то еще говорит, что не связанные с аутентификацией данные, такие как город или страна пользователя, не должны храниться в базе данных Auth.Вместо этого храните данные, относящиеся к аутентификации, только на сервере аутентификации, а любые данные, относящиеся к пользователю, - в базе данных ресурсов.Похоже, что две записи пользователя должны быть синхронизированы?Звучит как плохая идея.

3. Пусть сервер ресурсов и сервер аутентификации - это одно приложение, чтобы мы могли построить необходимые отношения между пользователем, хостом и событием.Но это, кажется, сводит на нет всю цель использования OpenID Connect.

Итак, какова здесь стандартная архитектура?Или, если не существует одного универсального формата, как бы вы хранили эти пользовательские данные?

Answer 1

С учетом разделения интересов и единственной ответственности:

Не существует только одной пользовательской таблицы. Поля в таблице имеют только значение в контексте.

Пользователь может иметь учетную запись Google для входа, но для бизнеса, который не является учетной записью, где вы можете связаться с сотрудником.А как насчет отображения информации в отчете, который не является частью контекста?Предположим, вы храните город в контексте идентичности.Тогда как вы собираетесь показать эту информацию в отчете?Вам понадобится информация в бизнес-контексте.

Также подумайте, является ли контекст идентификации хорошим местом для хранения информации.Потому что пользователь контролирует.Что происходит, когда пользователь не дает согласия на использование информации или просто удаляет аккаунт?И какую стратегию использовать, когда вы хотите синхронизировать данные?

Обмен контекстами не нужен.За идентификацию отвечает IdentityServer, контекст идентификации должен содержать только информацию о личности и доступен только IdentityServer.Обратите внимание, что IdentityServer не привязан к одному приложению.

Вам понадобится таблица пользователя в каждом контексте. Если информация может показаться избыточной, но на самом деле это не так, потому что она является частью отдельного контекста.Например, когда вы входите через такого провайдера, как Google.Затем в контексте идентификации создается локальная копия пользователя.

Но, возможно, вам не следует называть ее «Пользователь» в бизнес-контексте.Потому что в бизнес-контексте нет пользователей.Скорее всего, это сотрудники, клиенты и т. Д. Кто может иметь логин, но не обязательно.Кроме того, можно иметь (удостоверяющих личность) пользователей, которые неизвестны бизнесу (например, в случае нескольких приложений).

IdentityServer - это орган для аутентификации пользователя.Авторизация может быть реализована на нескольких уровнях.Вы можете создать отдельный сервер авторизации (например, policyserver ).Или более низкий уровень ( на основе ресурсов ), где наличие пользователя внутри таблицы person означает, что пользователь имеет доступ к ресурсу.

Лучшая часть отдельных контекстов - эточто внутри контекста вы можете создавать отношения между таблицами, не мешая другим контекстам.Вы можете легко переключиться на другого поставщика oidc, если хотите.Но как только вы начнете смешивать контексты, пути назад уже не будет.

Единственное, что очень полезно в oidc - это утверждение sub.Просто найдите пользователя по заявке sub и используйте локальный идентификатор для бизнес-контекста.

О полях city и country в контексте идентификации: существует несколько уровней аутентификации, поэтомувам может действительно понадобиться информация в этом контексте.Но если вам нужна информация в другом контексте (например, для отображения в отчетах), ее следует добавить туда (также).

Answer 2

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