Блог

Главная - Вопросы по программированию - Azure AD OAuth генерирует токен для аудитории без разрешения

Azure AD OAuth генерирует токен для аудитории без разрешения

#.net-core #oauth-2.0 #azure-active-directory

#.net-core #oauth-2.0 #azure-active-directory

Вопрос:

Несмотря на чтение нескольких статей и руководств на Microsoft.com , у меня возникла проблема с пониманием того, как определять разрешения между API с помощью регистрации приложений / OAuth2 в Azure AD. Для примера я настроил 2 простые регистрации приложений в Azure AD, одну для внутреннего API (допустим, идентификатор клиента A), а другую для внешнего интерфейса или другого API (идентификатор клиента B). Затем я настроил базовый API .NET Core с аутентификацией по умолчанию (шаблонной) (параметры = клиент, идентификатор клиента и т. Д.) И конечной точкой прогноза погоды по умолчанию.

         services.AddAuthentication(AzureADDefaults.BearerAuthenticationScheme)
            .AddAzureADBearer(options => Configuration.Bind("AzureAd", options));
        services.AddControllers();

Прямо сейчас я могу получить токен https://login.microsoftonline.com/<tenant>/oauth2/token с идентификатором клиента = B и ресурсом = идентификатором клиента A, и когда я отправляю этот токен (с ‘aud = A’) в API, он принимает его.

Почему токен генерируется успешно, хотя я не установил никаких отношений между регистрациями приложений A и B? Вкладка разрешений API в Azure AD пуста в обеих регистрациях — я думал, что AAD отклонит запрос, указав, что приложение B не имеет доступа к приложению A. Или я несу полную ответственность за проверку утверждений аудитории с помощью кода в моем приложении?

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

1. Я написал статью на эту тему: joonasw.net/view /. … И это продолжение: joonasw.net/view /. … TL; DR вам необходимо определить и проверить наличие разрешений.

2. Спасибо вам за это. Я всегда думал, что AD будет проверять разрешения перед выдачей токена. Я очень удивлен тем, что ни один из учебников (microsoft.com те) упомянутые разрешения не проверяются AAD, и это полностью зависит от вас.

3. Я напишу ответ на это 🙂

Ответ №1:

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

Некоторое время назад я написал статью о необходимости всегда проверять разрешения: https://joonasw.net/view/always-check-token-permissions-in-aad-protected-api . Я также написал продолжение после того, как Microsoft обратилась к возможности кросс-арендатора получать токены доступа: https://joonasw.net/view/cross-tenant-token-attacks-now-harder-in-azure-ad .

Поскольку клиент может получить действительный токен доступа без назначения разрешений, авторизация имеет решающее значение на стороне вашего API. В нашей компании у нас есть политика авторизации по умолчанию, которая проверяет каждый запрос на наличие либо действительного делегированного разрешения / области действия, либо действительного разрешения приложения / роли приложения. Это дает нам базовый уровень, который уже защищает API от подобных токенов. Обычно это не единственная применяемая авторизация. В случае, если делегированные разрешения поддерживаются, необходимо проверить, что пользователь также имеет доступ к тому, что он пытается сделать. В конце концов, делегированные разрешения / разрешения приложения говорят только о том, что может делать клиентское приложение.

Метки: