Неверный access_token из AAD с потоком OAuth2
Я делаю поток аутентификации кода аутентификации OAuth 2.0 с многопользовательским приложением.
Вот мой авторизационный URL:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=my_id&prompt=consent&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fauthorize&response_type=code&scope=openid+offline_access&state=17
Все идет нормально, и я получаю auth_code. Затем я делаю запрос с этим auth_code на token_url и получаю много информации, например:
- token_type
- объем
- id_token
- access_token
- refresh_token
- expires_at
- ext_expires_in
Мне кажется, это нормально, но когда я делаю запрос к API с access_token, например:
https://management.azure.com/subscriptions/my_sub_id/locations?api-version=2016-06-01
с заголовками:
Content-Type:
- application/json
Authorization:
- Bearer EwBQA8l6BAAURSN/FHlDW5xN74t6GzbtsBBeBUYAAV1IHgHb4dOWblzfd/YsSuFicAMDYbua17QivnAT9/pIaeKAg3uKsK5VGqWLzjMOUQrCpd7R1RAM6RkzI0u8e4rpO7DISG7qLso5H5+U1jb+38/j1urcwlXMMxhy83ZXmdpkLXpZV+vcOV...
Отвечает с ошибкой 401
body:
encoding: UTF-8
string: '{"error":{"code":"InvalidAuthenticationToken","message":"The access token is invalid."}}'
Честно говоря, я думаю, что что-то не так с моим access_token. Мне кажется, это не похоже на JWT. Документация говорит, что это выглядит так:
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCEV1Q..."
Но мой access_token выглядит так:
"access_token": "EwBYA8l6BAAURSN/FHlDW5xN74t6GzbtsBBeBUYAAZDe7JE/MPLoAi+Fr+1Xxq5eBe5N9l8Q+c4QjkY5PGEzRnBpPe7+v6h+PLdh1cceBQx+/JsB2QCrYSCt7x/zGsQAhwoY/"
Все в порядке?
Вот мои разрешения для приложения: Разрешения
Кроме того, попробуйте включить https://management.azure.com/ в scope, когда вы запрашиваете код авторизации и токен доступа, смотрите эту ссылку: docs.microsoft.com/en-us/azure/active-directory/develop/…
Это https://management.azure.com/ не является допустимой областью действия. Я думаю, мне нужно установить правильный объем.
Ответы 1
Основная проблема, с которой вы столкнулись, заключается в том, что вы запросили только токен доступа для областей действия openid offline_access. Результирующий токен доступа будет для Microsoft Graph (https://graph.microsoft.com), а не для Azure REST API (https://management.azure.com).
Чтобы указать, что вам нужен токен для данного API, параметр scope в вашем запросе на авторизацию должен включать делегированное разрешение, которое вы хотите, чтобы приложение имело для API. В случае Azure REST API существует только одно делегированное разрешение: user_impersonation. URI идентификатора для Azure REST API — https://management.azure.com, поэтому значение области, которое вы хотите использовать, — это:
openid offline_access https://management.azure.com/user_impersonation
Еще два важных замечания:
- Как вы обнаружили, вам не всегда будет выдан токен доступа в виде JWT, который вы можете декодировать для просмотра. Формат маркера доступа — это соглашение между службой, выпустившей маркер (в данном случае Azure AD или учетные записи Майкрософт), и службой, для которой был выпущен маркер (в данном примере — Microsoft Graph).
Вы должны всегда включать нет
prompt=consent.prompt=consentследует использовать только в том случае, если вы уже пытались войти в систему пользователя без, пользователю необходимо повторно запросить согласие на новое разрешение.Если вы просто включите необходимые области в параметр
scopes, платформа Microsoft Identity позаботится о том, чтобы выяснить, нужно ли ей запрашивать согласие или нет. Если вы всегда включаетеprompt=consent, вы обнаружите, что многим организациям будет заблокирован доступ к вашему приложению, потому что они отключили возможность для пользователей давать согласие самостоятельно (и этот параметр конкретно указывает, что вы требовать пользователю, которому будет предложено снова).
Попробуйте добавить субъект-службу в свою подписку, перейдите к своей подписке на портале -> Контроль доступа (IAM) -> Добавить -> Добавить назначение роли, добавьте ее как роль (например, владельца).