Предоставление авторизации кода Azure AD OAuth 2.0 с помощью Java Jersey

После прочтения этого руководства мой запрос REST выглядит так: Как авторизоваться в Microsoft Azure-AD

Client cli = ClientBuilder.newClient();
WebTarget webTar = cli.target("https://login.microsoftonline.com/yyyyy.onmicrosoft.com/oauth2/authorize").queryParam("response_type", "code");
webTar = webTar.queryParam("client_id", "ed4d67dc-34a8-4eb3-9058-49f39yyyyyy");
webTar = webTar.queryParam("redirect_uri", URLEncoder.encode("https://xyxyxyx.onmicrosoft.com/o365jso", "UTF-8"));
String response = webTar.request(MediaType.APPLICATION_JSON).get(String.class);

Однако в ответ я получаю полный HTML-код, в котором делается вывод, что конечная точка считает меня браузером. Есть ли способ как-то правильно действовать (в форме URL-адреса на стороне авторизации), чтобы получить код авторизации, а затем получить доступ к токену для Sharepoint/Exchange с помощью Java Jersey?


oauth-2.0 azure-active-directory office365api jersey-2.0
person Maevy    schedule 28.07.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

В потоке предоставления кода авторизации пользовательский агент (например, браузер) должен делать запрос GET к конечной точке авторизации. Это первый шаг, описанный в документе:

  1. Клиентское приложение запускает поток, перенаправляя пользовательский агент на конечную точку авторизации Azure AD. Пользователь аутентифицируется и соглашается, если требуется согласие.

Это необходимо для того, чтобы могли иметь место различные возможные взаимодействия с пользователем. Иногда отображается запрос согласия пользователя или, возможно, требуется многофакторная проверка подлинности или федерация с локальной STS пользователя.

После аутентификации пользователя Azure AD перенаправит пользовательский агент обратно на URI, указанный в redirect_uri, включая код авторизации в качестве параметра запроса. Это приведет к запросу GET к вашей службе с параметром code, который вы можете использовать для запроса токена доступа (теперь вы отправляете запрос непосредственно из своей службы в Azure AD).

Если вместо проверки подлинности пользователя вы заинтересованы в проверке подлинности между службами, вы должны использовать другой поток, как описано в Служба для обслуживания вызовов с использованием учетных данных клиента.

person Philippe Signoret    schedule 28.07.2015