OAUTH2.0 токен на предъявителя не работает

Question

Я использую модификацию 2.0 для сборки REST-клиента Bitbucket на Android.

Насколько мне известно, OAUTH2.0 предоставляет "неявное предоставление", которое дает клиенту токен Bearer для доступа сразу же, когда пользователь входит в свою учетную запись при появлении соответствующего запроса.

Токены на предъявителя - это токены, которые можно использовать для доступа к защищенному ресурсу. Любой, у кого есть токен на предъявителя, имеет право доступа к защищенному ресурсу, как и любой другой, у кого также есть токен на предъявителя. (согласно этому документу от IETF)

Пожалуйста, исправьте меня, если я ошибаюсь, но я подумал, что используя неявное предоставление, после входа пользователей в свою учетную запись Bitbucket у меня будет токен доступа на предъявителя. После этого я могу использовать этот токен доступа для доступа к защищенному ресурсу в Bitbucket (например, создать новый репозиторий).

Итак, я построил свой Android с использованием неявного предоставления OAUTH2.0, как описано в документе Bitbucket. Обратите внимание, что они описали ответ будет иметь #access_token={token}&token_type=bearer

И это то, что я на самом деле получил от Bitbucket после входа в систему:

your://redirecturi#access_token=lEuvneW39onVrnNR-jvZfirI43fwi5Wdc0YaaMROBk5YKJsd2ulXm20vJDdOBjf8I-Ne2r2vC8-_FHECSLw%3D&scopes=pipeline%3Awrite+webhook+snippet%3Awrite+wiki+issue%3Awrite+pullrequest%3Awrite+repository%3Adelete+repository%3Aadmin+project%3Awrite+team%3Awrite+account&expires_in=3600&token_type=bearer

Мой первый вопрос: что такое токен доступа на предъявителя из приведенного выше ответа?

Является ли часть lEuvneW39onVrnNR-jvZfirI43fwi5Wdc0YaaMROBk5YKJsd2ulXm20vJDdOBjf8I-Ne2r2vC8-_FHECSLw токен доступа на предъявителя? Нужно ли включать "%3D" (который является символом "=", закодированным в ASCII)? Разве документ Bitbucket не означает, что все, кроме последнего "&token_type=bear", является токеном доступа Bear?

Это не все. Инструкция Bitbucket doc, чтобы сделать запрос следующим образом:

Отправьте его в заголовке запроса: Авторизация: Bearer {access_token}

Поэтому я настроил этот запрос на создание нового репозитория в соответствии с API Bitbucket:

@POST("repositories/{username}/{repo_slug}")
    Call<Repository> createRepository(
            @Header("Authorization") String auth,
            @Path("username") String userName,
            @Path("repo_slug") String repoSlug);

Но каждый раз я получал ответы с кодом состояния 401 и сообщением об ошибке:

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

Когда я попытался отправить тот же запрос с помощью DHC с помощью Restlet (расширение Chrome, такое как Postman), появляется всплывающее окно, требующее от меня входа в Bitbucket. Если я отказываюсь сделать это, я получаю ту же ошибку 401 ответ. Если я делаю логин, то это работает.

Мой второй вопрос: почему я должен предоставить свои учетные данные снова?

Я думаю, что здесь что-то не так. Я подумал, что с токеном доступа Bearer я смогу получить доступ к защищенному ресурсу без необходимости входа в систему до того, как истечет время истечения токена доступа. Почему я должен ввести свои учетные данные во второй раз? Это не то, что описано в подходе "неявного предоставления" здесь IETF.

Answer 1

Значение access_token начинается после access_token= и заканчивается перед следующим параметром scopes так раньше &scopes=, Форматирование фрагмента указано в https://tools.ietf.org/html/rfc6749, который в свою очередь указывает на https://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html, где говорится:

[...] Имя отделяется от значения = и пары имя / значение отделены друг от друга & [...]

Таким образом, ваше значение токена доступа по спецификации lEuvneW39onVrnNR-jvZfirI43fwi5Wdc0YaaMROBk5YKJsd2ulXm20vJDdOBjf8I-Ne2r2vC8-_FHECSLw%3D но я согласен что концовка %3D является подозрительным и может быть ошибкой со стороны отправителя.

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