Отладка процесса авторизации в Postman

#authentication #debugging #oauth-2.0 #postman

Вопрос:

Я тестирую поток аутентификации OAuth 2.0 в postman.

  • Я использовал Authorisation вкладку, New Access Token кнопку, чтобы запустить процесс аутентификации.

введите описание изображения здесь

  • Добавил информацию в форму и нажал Requested Token кнопку. Это открыло экземпляр браузера, в котором я ввел необходимые учетные данные для аутентификации пользователя.
  • Как только шаги проверки подлинности завершены, я перенаправлен на страницу localhost в экземпляре браузера, который был открыт для шагов проверки подлинности. (Обратите внимание, что URL-адрес перенаправления указан при заполнении формы для токена запроса и является частью спецификаций OAuth 2.0.
  • Вот тут-то все и становится странным. На перенаправленной странице на локальном хосте я по-прежнему показываюсь как не-вошедший, так как в файле cookie/ локальном хранилище нет JWT (веб-токена JSON).

введите описание изображения здесь

  • Однако вернемся к основному интерфейсу почтальона. Если я нажму Request Token еще раз, я получу JWT, а это то, что я хочу.

введите описание изображения здесь

вопрос:

Почему я должен снова нажать request token кнопку, чтобы получить токен JWT. Предположительно, токен JWT не был возвращен сервером аутентификации, следовательно, экземпляр браузера все еще не вошел в систему? Делает ли нажатие кнопки request token сделать еще POST один запрос на сервер аутентификации для получения токена JWT. Каков здесь процесс?

И как я могу это отладить?

Редактировать:

Повторное нажатие sign-in кнопки в веб-приложении приведет к странице ошибки сервера проверки подлинности. Я подозреваю, что это связано с тем, что сервер имеет токен аутентификации для пользователя, поэтому не позволяет пользователю снова войти в систему?

Ответ №1:

Как отлаживать токен на предъявителя Вы можете отлаживать токен, полученный по идентификатору клиента и секрету клиента, с помощью https://jwt.ms когда вы получаете токен, пожалуйста, имейте в виду свойства:Выпущено в, Истекло в, Выдано и эмитенту и т. Д.

Теперь, возвращаясь к вашим общим данным, я сомневаюсь в значении URL-адреса токена доступа, это должен быть URL поставщика токенов. Конечная точка Azure token выглядит следующим образом: https://login.microsoftonline.com//oauth2/token

Как только вы получите токен, он проверяет авторизацию, поэтому сначала вы должны получить токен, а затем он должен попасть в конечную точку авторизации. https://login.microsoftonline.com//oauth2/authorize

Кроме того, когда вы передаете токен, существует другой поток, и с почтальоном, я считаю, что это упрощает использование неявного потока. Пожалуйста, обратитесь к другому потоку здесь: https://datatracker.ietf.org/doc/html/rfc6749#page-8

Пошаговый подход к выпуску токена с помощью Azure AD см. в разделе: https://docs.microsoft.com/en-us/rest/api/servicebus/get-azure-active-directory-token#use-postman-to-get-the-azure-ad-token

Надеюсь, это поможет вам получить токен и продолжить вашу дальнейшую работу.

Комментарии:

1. Я не понимаю, как это относится к моему вопросу. Я спрашиваю, как отладить процесс в postman, чтобы проверить мои предположения о проблеме с токенами.

2. понял. Если вас больше беспокоит отладка трафика почтальона, чтобы понять, откуда он звонит, являются ли запросы новыми и их результат, вы можете сделать это с помощью Fiddler, но для этого вам необходимо отключить проверку SSL-сертификата в Postman. Отключите проверку сертификата скрипача с помощью инструментов скрипача: