25/07/2016

Основы oAuth API Autodesk Forge - часть 2

Убедитесь, что вы ознакомились с терминологией из предыдущей статьи, прежде чем читать этот раздел.

two-legged authentication

В формальной терминологии OAuth, для выполнения two-legged аутентификации на платформе Forge требуется, чтобы вы использовали тип подтверждения "Client Credentials".

Это означает, что ваше приложение непосредственно взаимодействует с платформой Forge для аутентификации и доступа к ресурсам. Если это веб-приложение, конечный пользователь непосредственно не осведомлен о какой-либо из этих сервер-серверных коммуникаций, так как ни один из них не передается через веб-браузер.

Типичный рабочий процесс выглядит следующим образом:

Ваше приложение ("client" в терминологии OAuth), использует конечную точку POST authenticate, чтобы отправить идентификатор клиента и секрет, наряду с любыми областями видимости, которые ему потребуется.
Предполагая успешную проверку учетных данных, возвращается маркер доступа.
Ваше приложение может совершать вызовы к любой конечной точке "app only" или "user context optional", для которых маркер имеет необходимые области видимости посредством включения Authorization:Bearer <token> заголовка запроса (где <token> - Ваш маркер доступа из 28 символов).
По истечении срока действия маркера, вашему приложению нужно будет получить новый маркер, снова пройдя через все эти шаги.

three-legged authentication и Authorization

В формальной терминологии OAuth, для достижения three-legged аутентификации и авторизации на платформе Forge, требуется, чтобы вы использовали тип подтверждения "Authorization Code".

Будем использовать веб-приложение в качестве примера. Так, ваше приложение перенаправляет конечного пользователя к авторизации Autodesk и потоку авторизации, и код авторизации возвращается в ваше приложение (с помощью параметра запроса в функции обратного вызова). Ваше приложение затем обменивается тем кодом авторизации для маркера, путем обмена данными напрямую с сервером аутентификации Forge.

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

Типичный рабочий процесс выглядит следующим образом:

Ваше приложение ("client" в терминологии OAuth) запускает браузер ( "user agent" в терминологии OAuth), чтобы перенаправить конечного пользователя конечной точке GET authorize в самом браузере. (Помните, что типичный веб-браузер технически обращается к конечным точкам HTTP REST!) Используя параметры запроса, ваше приложение идентифицирует себя, запрашивает области видимости, и указывает на URL обратного вызова, чтобы перенаправить браузер после завершения авторизации.
Если пользователь не вошел в службу аутентификации платформы Forge с Autodesk ID, пользователю будет предложено войти в систему или создать идентификатор Autodesk.
Пользователь предоставляется со страницы согласия в браузере и должен явным образом принять области видимости, которые запрашивает ваше приложение.
Браузер пользователя перенаправляется на URL обратного вызова, наряду с параметра запроса code, который содержит код авторизации.
Браузера загружает URL обратного вызова, который передает код авторизации обратно в ваше приложение.
Ваше приложение использует этот код авторизации, его client ID, и его client secret чтобы вызвать конечную точку POST gettoken.
Предполагая успешную проверку учетных данных, возвращаются маркер доступа и маркер обновления.
Ваше приложение может совершать вызовы к любой конечной точке "user context required" или "user context optional", для которых маркер имеет необходимые области видимости посредством включения заголовка запроса Authorization:Bearer <token> (где <token> - ваш маркер доступа из 28 символов).
По истечении срока действия маркера, ваше приложение может использовать маркер обновления с конечной точкой POST refreshtoken, чтобы получить новый маркер доступа. (Это позволит избежать повторного прохождения шагов 1-6 каждый раз, когда истекает маркер доступа.)