Использование внешнего поставщика аутентификации для учетных данных пользователя, частного IdentityServer для генерации токена

Question

Я разрабатываю бэкэнд безопасности, который должен предоставлять токены нескольким клиентам для защиты ряда API. База данных пользователей находится в Azure B2C https://azure.microsoft.com/en-us/services/active-directory-b2c/. Я хочу создать маркеры API, которые содержат различные требования, основанные на доступе пользователей. Например: пользователь A должен иметь возможность вызова/api/stores/11, но не/api/stores/12.

Прецеденты:

• приложение, (Ipad), который идет непосредственно к Azure B2C для входа пользователя в систему и маркера поколения. Используйте этот токен, чтобы вызывать API для социального взаимодействия профиля пользователя и т. Д.
• Внешние системы, которые будут вызывать те же API (разные модули) с ограничениями прав доступа. Внешние системы будут иметь администраторов, которые также получат учетные данные от Azure B2C.

Мое решение до сих пор:

1. IdentityServer4 (https://github.com/IdentityServer/IdentityServer4), который вызывает Azure B2C логин для проверки учетных данных пользователя.
2. После того, как аутентификация завершена (при обратном вызове), IdentityServer будет применять любые утверждения, которые пользователь имеет (права доступа и т. Д.) Для внешних систем, а затем генерирует токен. IdentityServer будет иметь локальную базу данных, которая связывает идентификаторы пользователей/электронной почты с правами доступа.
3. API-интерфейсы будут использовать поставщиков многоуровневой аутентификации для поддержки BOTH токена от Azure B2C И моего «промежуточного» IdentityServer. Поставщики - IdentityServerAuthentication и OpenIdConnectAuthentication соответственно.

Вопрос в том, является ли это жизнеспособным решением? Это слишком сложно? Что бы вы сделали по-другому в этом случае? Я не хочу внедрять второй логин пользователя, и Azure B2C, похоже, не поддерживает мелкие права доступа.

Заранее спасибо.

Answer 1

Это на самом деле очень распространенная архитектура.

Основная идентификационная и фирменная платформа принадлежит вам - и это единственная нормальная вещь.

Затем вы можете использовать любой механизм (в вашем случае Azure B2C) для аутентификации. Возможно, вам захочется добавить в будущем локальную базу данных с пользователями или другим механизмом аутентификации. И все в порядке.

Важным моментом является то, что ваши приложения не заботятся об этом. Все, что они знают, это ваша платформа (в вашем случае построена с использованием сервера идентификаторов). Если вы решите, что в один прекрасный день вам нужно будет изменить поставщика проверки подлинности - все в порядке. Ваши приложения защищены от этого факта.

На данный момент вашим приложениям и службам нужно доверять только маркерам, отправленным с сервера идентификации. - identityserver заботится о брокерстве доверия с внешними сторонами.

Answer 2

Это очень удобно с IdentityServer4. Ваши варианты использования могут быть удовлетворены. Я бы предложил проверить samples.