Должен ли я использовать роли, утверждения, атрибуты, групповые утверждения для крупномасштабной аутентификации / авторизации B2 C - PullRequest
0 голосов
/ 10 апреля 2020

Я использую Azure B2 C для аутентификации в нескольких различных приложениях с различными потоками OIDC / OAuth (от имени потока, потока кода устройства, предоставления кода авторизации и т. Д. c). ).

Другими словами, я хотел бы иметь сервер API, который используется WebApps, SPA, Xamarin и другими клиентами.

Как мне сделать следующее в B2 C:

  • Назначение {многих} пользователей Facebook | Google | Office365 | Salesforce для входа в приложение и его API
  • Назначение заданных приложением строк c, которые влияют на то, как приложение работает, или какие функции доступны

Вопрос

  1. Являются ли назначение приложения, принципал обслуживания и другие AD-B2B ( Azure AD) концепции, переносимые на Azure B2 C, даже если они не документированы или на портале администратора?

  2. Какой продукт считается «Microsoft Identity»?

  3. Доступны ли все эти атрибуты (утверждения, роли, (атрибуты расширения)) из policy?

  4. Существуют ли проблемы масштабируемости с любым из подходов (количество групп для пользователя / приложения). Поскольку приложения для социальных сетей могут иметь миллионы входов в систему, я хочу убедиться, что этот подход масштабируемый и подходит для этой цели.

  5. Являются ли они удобными в обслуживании / легкими для разработчика? Для определения новых претензий для приложения может потребоваться инструментарий, независимо от того, где он хранится.

  6. Являются ли они отчетными? Мне нужно знать, кто имеет доступ, удалить доступ к конфиденциальным функциям или заставить пользователя повторно подтвердить претензии

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...