Неверный access_token из AAD с потоком OAuth2 - PullRequest
1 голос
/ 09 мая 2019

Я выполняю аутентификацию кода аутентификации 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 и получаю много информации, например:

  1. token_type
  2. Объем
  3. id_token
  4. access_token
  5. refresh_token
  6. expires_at
  7. 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/"

Это нормально?

Вот мои разрешения для приложения: Права доступа

1 Ответ

0 голосов
/ 10 мая 2019

Основная проблема, с которой вы столкнулись, заключается в том, что вы запросили только маркер доступа для областей действия openid offline_access.Полученный токен доступа будет для Microsoft Graph (https://graph.microsoft.com), не для API Azure REST (https://management.azure.com).

). Чтобы указать, что вам нужен токен для данного API, параметр scope вВаш запрос на авторизацию должен включать делегированное разрешение, которое вы хотите, чтобы приложение имело для API. В случае API-интерфейса REST Azure есть только одно делегированное разрешение: user_impersonation. Идентификатор URI для API-интерфейса REST Azure равен https://management.azure.com,поэтому значение области действия, которое вы хотите использовать:

openid offline_access https://management.azure.com/user_impersonation

Еще два важных замечания:

  1. Как вы обнаружили, вам не всегда будет выдан токен доступа какJWT, который можно декодировать для просмотра. Формат токена доступа - это соглашение между службой, выдавшей токен (в данном случае Azure AD или учетными записями Microsoft), и службой, для которой был выпущен токен (Microsoft Graph, вэтот пример).
  2. Вы должны , а не всегда включать prompt=consent. prompt=consent следует использовать только в том случае, если вы уже пытались войти впользователь без пользователю необходимо повторно запросить согласие на новое разрешение.

    Если вы просто включите необходимые области в параметр scopes, платформа Microsoft Identity позаботится о том, нужно ли запрашивать согласие или нет.Если вы всегда включите prompt=consent, вы обнаружите, что многим организациям будет закрыт доступ к вашему приложению, потому что они отключили возможность для пользователей самому давать согласие (и этот параметр специально указывает, что вам требуется пользователю будет предложено снова).

...