Проверить заголовок токена, полученный веб-API

Question

У меня есть сценарий: у меня есть это веб-приложение, которое аутентифицируется на лазурной рекламе через OWIN, и я создал веб-API, который вызывается действием HTTP через Microsoft Flow.

Сейчас в процессе я настроил HTTP-вызов с помощью Azure AD OAuth, и он успешно генерировал заголовки токенов авторизации и вызывает веб-API.

Сначала я помещаю атрибут [Authorize], как обычно, так как это заставляет войти, если запрос не аутентифицирован, но в этом случае всякий раз, когда я его использую, api не вызывается, а запрос отказано, даже если у него есть заголовки токена.

Теперь, как обходной путь, я подумал, что вместо использования атрибута [Authorized] я могу просто проверить токен запроса. Но я не уверен, как это сделать. Я почти уверен, что просто проверить, находится ли токен в заголовке, будет недостаточно, я тоже не думаю, что это безопасно. Я гуглил и прочитал какой-то пост, но, кажется, указывает на использование JWT.

Любые идеи приветствуются.

Большое спасибо заранее.

Answer 1

Сначала я ставлю атрибут [Authorize], как обычно, как это вынуждает войти, если запрос не аутентифицирован, но в этом всякий раз, когда я его использую, API не вызывается, и запрос отказ, даже если он имеет заголовки токена.

Теперь в качестве обходного пути я подумал, вместо того чтобы использовать [Авторизованный] атрибутов,

Избегайте обходных путей с Аутентификацией / Авторизацией

Мое предложение было бы не искать обходных путей, так как вы могли бы в итоге пойти на компромисс в отношении безопасности. Поведение, которое вы упоминаете здесь, может быть связано с:

1. Неправильная конфигурация / код, связанный с Аутентификацией в вашем веб-API или если с веб-API все в порядке, возможно, что-то не так с отправляемым токеном.

   Вот пример кода из Microsoft Docs , который очень похож на вашу ситуацию и использует атрибут [Authorize] в коде Web API для всех безопасных маршрутов (например, / TodoListService / Контроллеры / TodoListController.cs). Попробуйте сравнить ваши конфиги / код веб-API с этим пошагово.

   В этом примере показано, как Web API вызывается настольным приложением WPF (в вашем случае Microsoft Flow будет вызывать API).

2. Если для Web API все верно, возможно, что-то не так с отправляемым токеном. Как распространенная проблема, неправильная аудитория (это должен быть URI идентификатора приложения для вашего веб-API).

   В этом случае вы можете проверить отправляемый токен с помощью такого инструмента, как https://jwt.ms или https://jwt.io, чтобы проверить все претензии и затем принять решение.

Проверка токена

Проверка токена заключается в том, чтобы убедиться, что токен был выдан правом или доверенным органом / эмитентом, все еще действителен (не истек) и для правильного арендатора и т. Д. Он требуется наряду с обычной аутентификацией и авторизацией и не заменяет необходимость в [ Authorize] для всех безопасных маршрутов.

Вы не упоминаете, предназначен ли ваш веб-API для использования несколькими арендаторами или это приложение для одного арендатора.

В случае, если это приложение с одним арендатором, большая часть проверочной части покрывается самой конфигурацией аутентификации. Снова обратитесь к примеру кода, показанному выше (в частности, /TodoListService/App_Start/Startup.Auth.cs)

Если это мультитенантное приложение, то с вашей стороны требуется немного больше работы. Я подробно ответил на это в этой статье ( Многопользовательские приложения Azure AD - Как реализовать проверку токена? ). Вдумайтесь в это только в том случае, если это применимо к делу вашего Web API.