вероятно, число, которое вы получите после шага авторизации, является строкой oauth_verifier , которую необходимо отправить вместе с токеном REQUEST для получения токена ACCESS.
Это обязательная частьРеализации oAuth 1.0a (которые, на мой взгляд, являются наиболее распространенной реализацией, используемой в настоящее время, потому что 2.0 все еще является черновиком и не так много библиотек, которые его реализуют).
Я полагаю, что вы не отправляете URL обратного вызовапровайдеру, и он не знает, куда перенаправить пользователя после авторизации.Когда поставщик не знает URL-адрес обратного вызова, он не может перенаправить пользователя обратно в ваше (потребительское) приложение.В этом случае спецификация гласит, что она должна напечатать строку верификатора на экране, чтобы вы (пользователь) могли взять ее вручную и передать в свое (потребительское) приложение, и, таким образом, построить запрос на ACCESS TOKEN.
Если вы действительно предоставите URL обратного вызова (в первом запросе токена REQUEST), то, скорее всего, вы не получите экран с этим номером, но вместо этого вы (пользователь) будете перенаправлены на URL обратного вызова с ним автоматически.
Например, если ваш URL обратного вызова: http://myapp.com/oauth/callback
, тогда провайдер перенаправит пользователя на ваш URL обратного вызова с правильными значениями в строке запроса.
redirect: http://myapp.com/oauth/callback?oauth_token=xxxx&oauth_verifier=yyyy
Тогда ваше приложение должно взять строку верификатора и добавить ее в качестве параметра в запрос на ACKESS TOKEN (как вы делали это ранее с другими параметрами, такими как nonce, timestamp, oauth_token и т. Д.)
В ответ на этот последний запрос (включая строку oauth_verifier ) вы должны получить ACKESS TOKEN.
Вот хорошее объяснение о строке oauth_verifier и почему она была введена в протокол: http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/