Как реализовать клиентский API-доступ к ресурсам, защищенным Azure AD B2C - PullRequest
Новая
       13

Как реализовать клиентский API-доступ к ресурсам, защищенным Azure AD B2C

0 голосов
/ 14 апреля 2020

В настоящее время у меня есть приложение Angular SPA, которое использует Azure B2 c для авторизации пользователей и использует токен для передачи на микросервисы для получения / установки всех функций.

Теперь я хочу создать API, который клиенты могут использовать для доступа к самим микросервисам (напрямую или через Azure API Management).

Я не могу найти хорошую документацию по этому вопросу, но в идеале я бы хотел, чтобы пользователи могли создайте в нашем приложении «приложения», которые дадут им API-ключ и секрет, и затем они смогут использовать их для обмена на токен JWT, который они смогут передавать на микросервисы - Azure B2 C, сгенерированный идеально, чтобы он мог просто используйте ту же аутентификацию, которую мы делаем сейчас. API для преобразования ключа / секрета в токен должен быть неинтерактивным.

Azure AD B2 C теперь поддерживает ROP C, но это не подходит, так как это просто используйте имя пользователя и пароль, которые мы не хотим (поскольку я хочу, чтобы пользователи могли отозвать доступ). https://docs.microsoft.com/en-us/azure/active-directory-b2c/configure-ropc?tabs=applications

Я мог бы построить все это внешне для Azure B2 c - есть собственный поставщик Identity, который генерирует токены для API, и на всех микросервисах измените конвейер, чтобы иметь два аутентификатора. валидации - одна для Azure B2 c токенов, а другая для проверки собственной идентификации API, но надеялась, что есть более упорядоченный подход.

Есть предложения?

1 Ответ

1 голос
/ 15 апреля 2020

В этом сценарии вы должны создать следующую архитектуру:

  1. Пользователь входит в ваш портал. Они используют политику Azure AD B2 C для получения своих токенов.
  2. Они используют свой токен доступа для вызова вашей службы
  3. Ваша служба создает Azure AD Регистрация приложения в вашей Azure AD B2 C directory
  4. Это делается с использованием Azure AD Graph API. Ваш API создает App Reg, генерирует необходимый Application Secret и возвращает AppId и Secret пользователю
  5. . Вам также необходимо зарегистрировать приложение, чтобы представлять сам микросервис, и предоставить ему указанные выше разрешения App Reg.
  6. Ваш микросервис должен доверять 2 эмитентам токенов. Azure эмитент токена AD и Azure AD B2 C эмитент токена из каталога Azure AD B2 C
  7. Теперь пользователь может использовать поток учетных данных клиента в соответствии с обычным Azure AD, против вашей Azure AD B2 C директории и запросите область действия вашего приложения микросервиса Рег.
  8. Затем они используют новый токен для вызова вашей микросервисной службы

Если вы используете APIM или что-то подобное, их можно настроить для доверия нескольким эмитентам токенов.

Таким образом, аутентификация пользователя защищена B2 C пользовательскими потоками / политиками и издателем токенов B2 C. А доступ на основе API защищен конечной точкой AAD вашего клиента B2 C. Микросервис, поскольку он совместно используется обоими типами механизмов аутентификации, должен доверять двум эмитентам токенов.

...