MSAL для React frontend & Django backend - Любая помощь
Существует ли стандартная практика для MSAL auth при использовании отдельного фронтенда/бэкенда lagnuage? Должен ли я иметь и Public, и ConfidentialClient, или только один? Я запутался после тщательного чтения документации в течение пары недель...
Моя основная цель состоит в том, чтобы пользователи получали токен доступа с моим идентификатором клиента в качестве требования аудитории, чтобы django api мог подтвердить его (промежуточное ПО), а затем закрепить дополнительный набор токенов со стандартным диапазоном MS Graph, чтобы мой бэкэнд мог выполнять обращения к MS Graph (например, отправлять электронные письма через конечную точку mail).
Кажется излишним, чтобы react использовал библиотеку msal.js, а бэкенд django также использовал msal, поскольку это приведет к двум отдельным кэшам токенов... Должен ли я внедрить msal только в один из них? Если да, то стоит ли предпочесть один из них другому?
Мне бы не помешало небольшое руководство в плане того, как структурировать аутентификацию msal в моем проекте... Любая помощь будет оценена по достоинству, какой бы маленькой/быстрой она ни была...
У вас есть два основных подхода, разница между которыми заключается в том, на какой «стороне» разделения клиент/сервер находится «босс».
Наиболее распространенным является клиент-авторитарный, который сводится к тому, что клиент указывает серверу, что есть что в плане пользовательских данных.
При такой настройке, для сценария, который вы описали, вам нужен MSAL с обеих сторон. @azure/msal-react с экземпляром приложения Public (который не хранит токены) на фронтенде для обработки онбординга, pipy-msal с экземпляром приложения Confidential на бэкенде для обработки хранения токенов и вызовов API. Это потребует взаимодействия между фронтендом и бэкендом; как минимум, вам придется передавать либо клиентский секрет, либо токен, который можно обменять на клиентский секрет.
Менее распространенным, но не менее эффективным является подход с использованием сервера-авторитета, когда сервер не принимает произвольные данные от клиента, а собирает их самостоятельно. Когда пользователю нужно пройти процедуру регистрации в Azure, фронтенд перенаправляет его на конечную точку бэкенда и обрабатывает все там без взаимодействия между фронтендом и бэкендом. Для этого вам не понадобятся публичные экземпляры приложений MSAL.
Обзор:
Клиент-авторитет
Плюсы:
- Общий поток, поэтому много документации и примеров
Против:
- Требуется небольшая степень дублирования, поскольку вам нужно обращаться к конечным точкам Azure с двух разных серверов .
Сервер-авторитет
Плюсы:
- Сохраняет Azure-логику централизованной и де-дублированной
- Инкапсулирует Azure-логику так, что фронтенду не нужно заботиться или знать о чем-либо, связанном с Azure
Против:
- Требует создания конечных точек, ориентированных на пользователя (с безопасностью, аутентификацией, доступом к домену и т. д.), вне фронтенда
- В некоторой степени требует создания конечных точек бэкэнда (и, опционально, оберток фронтенда) для реализации «недостающей» логики приложения, которая в противном случае могла бы быть обработана библиотекой Microsoft
Заключение:
«Стандартная практика» - это плохой термин. То, что является лучшим выбором для вас, в конечном счете зависит от ваших бизнес-потребностей, выбора технологической архитектуры и т. д.
Но если вы сомневаетесь, то, скорее всего, по многим причинам вам больше подойдет подход клиент-авторитет. Минусы серверно-авторитарного подхода могут быть обманчиво сложными (в зависимости от вышеупомянутых вариантов), и только по этой причине его не следует применять, если у вас нет действительно детального понимания всего пути пользователя на техническом уровне. Сложность клиентско-авторитарного подхода значительно более устойчива к архитектурным решениям.