Как почтальон завершает поток OAuth 2.0 без фактического перенаправления на RedirectURL (callbackUrl)? - PullRequest
0 голосов
/ 29 сентября 2019

В настоящее время я пытаюсь интегрировать логин MQL5 в мое мобильное приложение с использованием собственного реагирования.

Не так много примеров, чтобы узнать, как его интегрировать. Однако я могу успешно использовать почтальон для получения токена доступа

enter image description here

После того, как я заполнил URL-адрес обратного вызова, client_id и client_secret, я щелкаю токен запросакнопка. Он попросит меня войти в MQL5, и после этого почтальон сможет получить токен доступа без фактического перенаправления на страницу URL обратного вызова. Как почтальон достигает этого?

1 Ответ

0 голосов
/ 30 сентября 2019

Почтальон может захватывать код или токен в зависимости от процесса авторизации, потому что он обрабатывает запрос внутренне. Это отличается от рекомендованного типичного и рекомендованного потока ( rfc ) для собственных приложений, где аутентификация обрабатывается системным браузером, который обрабатывает перенаправление как запрос конечной точки авторизации, как это видно в первойдиаграмма. Вместо этого Postman восстанавливает код и использует его для получения токена доступа непосредственно с сервера ресурсов.

  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
  |          User Device          |
  |                               |
  | +--------------------------+  | (5) Authorization  +---------------+
  | |                          |  |     Code           |               |
  | |        Client App        |---------------------->|     Token     |
  | |                          |<----------------------|    Endpoint   |
  | +--------------------------+  | (6) Access Token,  |               |
  |   |             ^             |     Refresh Token  +---------------+
  |   |             |             |
  |   |             |             |
  |   | (1)         | (4)         |
  |   | Authorizat- | Authoriza-  |
  |   | ion Request | tion Code   |
  |   |             |             |
  |   |             |             |
  |   v             |             |
  | +---------------------------+ | (2) Authorization  +---------------+
  | |                           | |     Request        |               |
  | |          Browser          |--------------------->| Authorization |
  | |                           |<---------------------|    Endpoint   |
  | +---------------------------+ | (3) Authorization  |               |
  |                               |     Code           +---------------+
  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+

Источник: https://tools.ietf.org/html/rfc8252#section-4.1

Вместо этого поток запросов в Postman выглядит следующим образом

  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
  |          User Device          |
  |                               |
  | +--------------------------+  | (3) Authorization  +---------------+
  | |                          |  |     Code           |               |
  | |        Postman           |---------------------->|     Token     |
  | |                          |<----------------------|    Endpoint   |
  | +--------------------------+  | (4) Access Token,  |               |
  |   |             ^             |     Refresh Token  +---------------+
  |   |             |             |
  |   |             |             |
  |   | (1)         | (2)         |
  |   | Authorizat- | Authoriza-  |
  |   | ion Request | tion Code   |
  |   |             |             |        +---------------+
  |   |             |             |        |               |
  |   |             '--------------------->| Authorization |
  |   '------------------------------------|    Endpoint   |
  |                               |        |               |
  |                               |        +---------------+
  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
  1. Поэтому почтальон откроет соединение с конечной точкой авторизации и
  2. отправит HTTP-запрос GET, подобный следующему.
GET /authorize?prompt=login&response_type=code&state=<STATE>&redirect_uri=<REDIRECT_URI>&client_id=<CLIENT_ID> HTTP/1.1
Host: AUTHORIZATION_SERVER_URL
Авторизация ответит формой входа, которую почтальон покажет вам. Вы вводите свои учетные данные, а почтальон отвечает запросом POST с вашими учетными данными. Сервер отправляет ответ сперенаправление 302, например:
HTTP/1.1 302 Found
Location: <REDIRECT_URI>?code=<CODE>
&state=<STATE>
Почтальон теперь вместо перенаправления на перенаправление uri отправляет запрос POST с кодом, полученным в ответе на конечную точку токена, с:
POST /token HTTP/1.1
Host: AUTHORIZATION_SERVER
Authorization: Basic <CLIENT_SECRET_IF_CONFIDENTIAL_CLIENT>
...
grant_type=authorization_code&code=<CODE>
&redirect_uri=<REDIRECT_URI>
Сервер авторизации отвечает токеном, подписанным объектом json в кодировке base64, который почтальон может отобразить для вас.

Весь процесс описан здесь: https://tools.ietf.org/html/rfc6749#section-4.1 Естьнесколько вариантов (неявный поток, поток конфиденциального или открытого кода) в этом процессе для различных ограничений (SPA, веб-сайты с полным стеком, нативные приложения), но все они работают одинаково.

В заключение, Postman предлагает удобство немедленногополучать токен и встраивать его и широко использовать в целях разработки. Тем не менее, многие другие нативные приложения делают то же самое, и даже веб-сайты будут обрабатывать аутентификацию в IFrame, который открывает дверь для злонамеренного использования, но также обучает пользователей вводить свои учетные данные даже в ненадежных настройках. Одно из преимуществ безопасности в соответствии с предлагаемым рабочим процессом заключается в том, что приложение никогда не получает учетные данные, а браузер обеспечивает получение кода только тем веб-сайтом, который указан в ответе о перенаправлении. Это предотвращает кражу ваших учетных данных вредоносным приложением (на шаге 4 выше), поскольку вход в систему происходит на сервере авторизации с доверенным агентом пользователя (вашим браузером).

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