Я пытаюсь защитить свой веб-API (.net core 2.2) с помощью Azure Ad, используя неявный поток.
Я зарегистрировал свое приложение в Azure AD, используя Портал Azure > Azure Active Directoy > Регистрация приложений > Регистрация нового приложения:
Имя = MyWebApi
Тип приложения = веб-приложение/API
URL-адрес для входа = http://локальный: 55000
После создания этого приложения я открыл его файл манифеста и изменил oauth2AllowImplicitFlow с ложный на истинный.
Это все, что я сделал для регистрации приложения на портале Azure.
Затем я вручную вызвал следующий URL-адрес из браузера Chrome, чтобы получить access_token:
ответ от вызова вышеуказанного URL-адреса:
когда я передаю MY-ACCESS-TOKEN в качестве токена носителя в заголовке авторизации в свой веб-API (.net core 2.2), я получаю следующее исключение:
Microsoft.IdentityModel.Tokens.SecurityTokenInvalidSignatureException: IDX10511: Ошибка проверки подписи. Пробовали ключи: «Microsoft.IdentityModel.Tokens.X509SecurityKey, KeyId: N-lC0n-9DALqwhuHYnHQ63GeCXc».
Затем я попытался вручную проверить подпись:
когда я вставляю MY-ACCESS-TOKEN в https://jwt.io/, заголовок:
{
"typ": "JWT",
"nonce": "AQABAAAAAACEfexXxjamQb3OeGQ4Gugvm6YdOT-bkA0IPllKMt06-J8If5AQ075TVCav94X_ZYcEYKaPneqdJcqYry-Z4XjX0eMN_fiJX_8wXe9D2b6eRiAA",
"alg": "RS256",
"x5t": "N-lC0n-9DALqwhuHYnHQ63GeCXc",
"kid": "N-lC0n-9DALqwhuHYnHQ63GeCXc"
}
Затем я перешел по этому URL-адресу, чтобы получить открытый ключ для ребенка: N-lC0n-9DALqwhuHYnHQ63GeCXc.
https://login.microsoftonline.com/common/discovery/keys
Затем я вставил следующее в качестве открытого ключа на jwt.io для проверенной подписи токена:
-----BEGIN CERTIFICATE-----
OBTAINED-PUBLIC-KEY-FROM-THE-ABOVE-URL-HERE
-----END CERTIFICATE-----
и я снова получаю Неверная подпись.
Я был в этой теме: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/609, но я не уверен, почему заголовок моего токена имеет значение одноразовый номер и является ли это проблемой вообще в моем случае или нет.
Любые идеи, что я делаю неправильно здесь?
Любые идеи, почему я получаю возможности для Microsoft Graph? Я не просил его в своем запросе.
На мой взгляд, вам следует изменить свое приложение, чтобы получить токен доступа для вашего API. Поскольку на данный момент вы не указываете, для какого API вы хотите. Вы можете зарегистрировать API как приложение, определить для него разрешения OAuth и назначить разрешения внешнему приложению, получающему токен.
Это возможный план, но концепция остается той же. Я создал регистрацию приложения для API и пытаюсь получить доступ к этому API после получения токена доступа из Azure AD. Проблема, я думаю, связана с одноразовым номером, и я не уверен, почему мои токены рекламы Azure содержат одноразовый номер, когда я не запрашиваю область графа Microsoft.
Приятно видеть, что вы уже четко определились с регистрацией API и окончательным планом, как вы говорите. Еще одна вещь, на которую следует обратить внимание. Вы зарегистрировали приложение на обычном портале Azure (поэтому оно будет принимать токены v1 по умолчанию).. но вы работаете с конечной точкой v2 для получения токена... и поскольку вы не указываете, какой API вы хотите токен для, конечная точка возвращает вам токен для всех разрешений, которые были статически определены во время регистрации вашего приложения. Я думаю, что в настоящее время при регистрации вашего приложения может быть выбрано Microsoft Graph с User.Read в соответствии с требуемыми разрешениями.





Я попробовал это на своей стороне, это сработало хорошо.
URL-адрес запроса:
https://login.microsoftonline.com/tenant-name/oauth2/v2.0/authorize?client_id=application_id&response_type=token&redirect_uri=https://snv2app.azurewebsites.net&scope=api://f3d966c0-517e-4e13-a5bb-9777a916b1a0/User.read openid&response_mode=fragment
И когда я получил access_token, я разобрал его в jwt.io и ввел публичный ключ, я получил результат:
Что такое api://f3d966c0-517e-4e13-a5bb-9777a916b1a0/User.read в области видимости?
api://f3d966c0-517e-4e13-a5bb-9777a916b1a0 — это мой API и соответствующие разрешения.
это действительно было проблемой, моя область не содержала URI API, передача которого в область не возвращала значение nonce, и поэтому я смог проверить подпись. Спасибо за вашу помощь.
Здесь происходит токен, который вы получаете, это access_token для конечной точки userInfo. Аудитория граф. Токены для графа были изменены особым образом, так что они должны быть преобразованы, прежде чем подпись может быть проверена. Это позволяет графу пересылать токен вниз по течению (после преобразования) и не беспокоиться о переадресации атаки.
Чтобы проверить, посмотрите, есть ли «aud == graph».
У меня была такая же проблема, я использовал токен доступа, чтобы проверить его с помощью сайта JWT.io, но это не удалось, и ваш комментарий помог мне увидеть, могу ли я проверить idToken, и он был проверен! Но есть идеи, как проверить токен доступа? Я использую библиотеку MSAL.js, и для получения маркера доступа вызывается методAcquireTokenSilent с параметром областей графа. Итак, есть ли способ проверить этот токен доступа к графу?
@Maverick, что вы хотите проверить о токене? Graph проверит токен при получении.
Я хочу получить роли пользователей и группы, к которым они принадлежат, например
Вы можете отправить токен на график, чтобы получить эту информацию. Трудно сказать, что находится в этом токене или как его использует график.
Я вижу, что токен доступа, который вы возвращаете, также включает в себя область для Microsoft Graph API. Я думаю, что это причина того, что
Nonceтакже появляется. чтобы проверить его.. в частности,00000003-0000-0000-c000-000000000000/User.Readобласть.. где00000003-0000-0000-c000-000000000000— идентификатор ресурса для Microsoft Graph API..