Azure AD — Как я могу связать пользовательские компоненты регистрации и входа в SPA с базовым процессом Azure AD

#azure-active-directory #azure-storage #azure-functions #single-page-application #serverless

#azure-active-directory #azure-хранилище #azure-функции #одностраничное приложение #бессерверный

Вопрос:

Я нахожусь на ранних стадиях разработки бессерверного приложения со следующими компонентами:

  1. SPA, использующий React, для которого я планирую запустить статические ресурсы в хранилище Azure.

  2. Внутренний API, управляемый функциями Azure.

  3. Потенциально база данных CosmosDB, если мы сможем избежать использования полноценного SQL Server. Это будет зависеть от того, насколько сложной окажется наша схема.

В серверной части задействовано несколько других компонентов, но они не имеют отношения к этому вопросу.

По сути, я пытаюсь выяснить, как я могу создать формы регистрации, кнопки и т.д. в моем React SPA, Которые подключаются к пулу пользователей, управляемому Azure.

Проблема, с которой я сталкиваюсь на ранних стадиях разработки, заключается в моем понимании решений Azure для того, что мне нужно. Я работаю в AWS. В AWS я бы просто создал пул пользователей Cognito и подключил процесс регистрации моего приложения к указанному пулу пользователей с помощью AWS SDK.

Для меня этот процесс имеет смысл. Однако в мире Azure это, похоже, не так просто. Я прочитал статьи / технические документы о Azure AD, Azure AD B2C и т.д. и т.п. Процессы, описываемые в этих статьях, похоже, никогда не упоминают взаимосвязь между формами, которые я создаю в своем SPA, и тем, как инициировать аутентификацию оттуда в Azure AD. В принципе, я хочу, чтобы тот факт, что Azure AD работает, был невидимым для пользователя; они должны взаимодействовать только с моим интерфейсным приложением (т. Е. Никаких перенаправлений на страницы регистрации Microsoft или Azure и т.д.).

На данный момент то, что я придумал, включает следующее (опять же, я все еще на стадии проектирования):

  1. Хранилище Azure для размещения статических ресурсов.
  2. Функции Azure с прокси-серверами Azure Function для маршрутизации между интерфейсом и API.
  3. Похоже, что поток пользователей Azure AD может быть способом для ознакомления; однако я все еще не уверен, существуют ли SDK, которые SPA может использовать для взаимодействия с такими функциями, как вход, забытый пароль, выход и т.д. Я хочу, насколько это возможно, избежать повторного запуска колеса.

Я еще не начал писать код, поскольку в настоящее время я все еще на стадии разработки карандашом / бумагой. С чем я столкнулся, так это с такими проблемами, как:

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

  2. A полностью ожидаю, что как только я внедрю пользовательский поток регистрации / Sign-In, я смогу запускать процессы AAD и получать JWT для использования с последующими вызовами внутреннего API. Я пока не уверен, что это настолько просто.

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

Ответ №1:

Вы правы. Azure AD B2C — это именно то, что вы ищете.

Чтобы ответить на ваши вопросы —

  1. ДА. Вы также можете разместить в хранилище больших двоичных объектов и настроить статический хостинг веб-сайтов. Вы также можете заглянуть в Azure CDN или Azure Frontdoor, чтобы ускорить доставку ваших статических ресурсов.

    Но если вам также требуется рендеринг на стороне сервера и / или проверка подлинности Azure AD для вашего пользовательского интерфейса, вам придется использовать веб-приложение.

  2. Рекомендуемый способ выполнения аутентификации в соответствии со спецификациями OAuth / OpenID Connect — это поток, при котором пользователь регистрируется на сервере аутентификации (здесь Azure AD), который перенаправляет их в клиентское приложение, передавая код авторизации, который позже обменивается на токен доступа и токен обновления.

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

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

Вы можете прочитать больше о различных протоколах OAuth 2.0 и OpenID Connect, поддерживаемых Azure AD, в документации.

Комментарии:

1. Спасибо за это. Это именно то, что я искал.