Аутентификация с ADAL JS не ведет себя так, как ожидалось

Question

У меня есть два приложения Azure AD в том же каталоге, назовем их FrontendAuth и BackendAuth, которые предоставляют аутентификацию для внешнего интерфейса ASP.NET MVC и веб-интерфейса Web API соответственно. Интерфейс MVC защищен с использованием стандартной конфигурации UseOpenIdConnectAuthentication, бэкэнд Web API с UseWindowsAzureActiveDirectoryBearerAuthentication.

То, что я хочу сделать, это войти в веб-интерфейс, проверка подлинности на FrontendAuth, а затем потреблять через JavaScript в API размещенный во внутреннем интерфейсе, предоставляя маркер, приобретенного с помощью ADAL JS, чтобы BackendAuth.

Предположения

Мои ожидания/предположения:

• То, что я должен был бы настроить FrontendAuth, чтобы иметь доступ к BackendAuth в классическом портале
• То, что я должен был бы изменить манифест файлы одного или обоих из них для установки oauth2AllowImplicitFlow на true
• Это, когда я настраиваю ADAL JS я должен быть установкой clientId, чтобы быть таким FrontendAuth
• endpoints объект конфигурации ADAL JS должен содержать адрес бэкэнда API и идентификатор клиента из BackendAuth

исход

могу достигните своей цели входа в интерфейс и связи с базовым обслуживанием через ADAL JS с:

• FrontendAuth приложение не имея доступа к BackendAuth на всех
• Ни файла манифеста, имеющего oauth2AllowImplicitFlow набор свойств для true
• ADAL JS, имеющий clientId набор, чтобы быть, что из BackendAuth
• Конечные точки объекта конфигурации ADAL JS не установлен на всех

Вопросы

Основываясь на этих выводах, я хотел бы понять следующее:

• Были ли мои предположения правильно? Так ли работает ADAL JS?
• Почему отсутствие доступа к приложениям и неизменные файлы манифеста не влияют на успешность аутентификации?
• Когда эти меры влияют на результат аутентификации?

Answer 1

Вы смешиваете два потока OAuth2 здесь (authorization code flow и implicit flow). Оба предназначены для выдачи токена клиентскому приложению.Поток кода аутентификации используется для веб-приложений, работающих на сервере (например, ваше приложение MVC), а неявный поток предназначен для публичных клиентов, таких как SPA.

Когда вы используете OpenID Connect, чтобы выполнить вход пользователя в ваше приложение MVC, используя гибридный поток, вы получите код авторизации в браузере. Вы используете этот код, чтобы поговорить с сервером авторизации и получить токен JWT, который затем хранится в сеансе cookie. Вы можете использовать тот же код, чтобы получить токен JWT для вашего приложения BackendAuth, если вы дали разрешение на использование приложения FrontendAuth для вызова приложения BackendAuth.

Если вы хотите включить JavaScript в браузере пользователя для вызова в приложение BackendAuth, вам необходимо каким-то образом передать токен доступа в браузер. Вы можете сделать это, отправив маркер вместе с первоначальным запросом и поместив его в локальное хранилище или выложив (защищенный) маршрут MVC, чтобы получить токен.

Пример того, что я описываю здесь, см. this Azure AD sample, который получает токен для API-интерфейса Graph, используя код авторизации.

ADAL.js реализует неявную поток и предназначен для JavaScript-приложений, таких как ООР и т.д.

Answer 2

Похоже, вы явно не оформлены контроллеры Web API с [Авторизоваться] атрибутов (либо на уровне класса, или уровень действия). Таким образом, ваш веб-API может с удовольствием обслуживать контент для всех, кто его запрашивает.