Архитектура аутентификации приложения VueJS (или React или Angular) во внешнем интерфейсе с использованием кода авторизации

Question

Я работаю над приложением, в котором внешний интерфейс равен VueJS, а внутренний - NodeJS и ExpressJS.

NodeJS, ExpressJS будут размещать API REST, и я хочу защитить их с помощью Azure AD. Я хочу использовать поток кода авторизации.

Мой вопрос: я вложил свои мысли в диаграмму, это правильный подход?

Answer 1

Этот подход выглядит хорошо для меня. Я думаю об этом как о расширенной версии чего-то вроде аутентификации на основе JWT (https://jwt.io/). См. Шаги ниже для JWT:

1. Клиент запрашивает аутентификацию, предоставляя учетные данные.
2. Сервер предоставляет клиенту токен, который зашифрован с использованием закрытого ключа, присутствующего на сервере. ,
3. JWT сохраняется в сеансе клиента и отправляется на сервер каждый раз, когда клиент запрашивает у него что-либо, требующее аутентификации.
4. Затем сервер расшифровывает токен, используя открытый / закрытый ключ, и отправляет ответ клиенту.
5. На этом этапе сеанс проверяется.

С архитектурой, которую вы описали выше, он делает то же самое, кроме средств шифрования (генерации) и дешифрования (проверки) токен существует с Azure AD. Ниже приведены шаги для достижения аутентификации на основе вашей архитектуры:

1. Клиент запрашивает аутентификацию, предоставляя учетные данные.
2. Сервер Azure AD выполняет действия 2FA, но в end предоставляет токен (эквивалентный JWT в предыдущем подходе).
3. Токен сохраняется в сеансе клиента и отправляется на внутренний сервер приложения каждый раз, когда клиент запрашивает у него что-либо, требующее аутентификации.
4. Внутренний сервер использует Azure AD для проверки токена (аналогично шагу дешифрования / проверки в JWT) и отправляет ответ клиенту.
5. На этом этапе сеанс проверяется.

Хотя я бы предложил небольшое изменение в этом. Если вы посмотрите на шаг 4 выше. Сервер приложений будет продолжать нажимать Azure AD каждый раз, когда ему нужно аутентифицировать сеанс. Если бы вы могли добавить фактический JWT для этой фазы, это может помочь избежать этих избыточных вызовов на Azure.

Таким образом, шаги, описанные выше для JWT, могут быть добавлены после 4-го шага для Azure AD, описанного выше, т.е. создайте JWT и сохраните его в сеансе клиентов, как только все будет проверено с Azure, а затем продолжайте использовать JWT на основе аутентификации в будущем для текущего сеанса.

При необходимости JWT может быть сохранен в куки-файлах браузера, а звонки на Azure AD могут быть полностью исключены в течение определенного c периода. Однако наша цель здесь состоит не в том, чтобы уменьшить нагрузку на сервер Azure AD, а просто в том, чтобы предложить способ использования JWT в этой конкретной c ситуации.

Надеюсь, это поможет.