Ошибка файл с oauth токеном не найден

Обновлено: 04.07.2024

В данном разделе приводится описание ошибок, возникающих при выполнении запросов в рамках протокола OAuth 2.0 и OpenId Connect 1.0.

В случае возникновения ошибок сервер возвращает информацию в двух полях:

  • error - код ошибки.
  • error_description - описание ошибки.

Далее будет представлена информация по кодам ошибок.

Ошибки конечной точки /authorize

invalid_request

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

Возможные причины

unauthorized_client

Возможные причины

unsupported_response_tpe

Тип ответа не поддерживается.

Указанный в запросе response_type не поддерживается.

Возможные причины

  • В запросе указан параметр response_type со значениями отличными от
    • code ,
    • token ,
    • id_token ,
    • id_token token ,
    • code id_token
    • code token
    • code id_token token .

    invalid_scope

    Неправильная область использования.

    Возможные причины

    login_required

    Запрос не может быть выполнен в интерактивном режиме (с указанием параметра prompt со значением none ).

    Возможные причины

    • Запрос не может быть выполнен в неинтерактивном режиме, так как требуется аутентификация пользователя.

    Ошибки конечной точки /token

    invalid_request

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

    Возможные причины

    invalid_client

    Не удалось осуществить аутентификацию клиента.

    Возможные причины

    invalid_grant

    Разрешение, используемое клиентом, не является действительным.

    Возможные причины

    • Не передан параметр password в сценарии с использованием учётных данных владельца ресурсов.
    • Сервер не настроен на обработку сценария с использованием учётных данных владельца ресурсов.
    • Не удалось аутентифицировать пользователя по переданным username и password .
    • Сценарий с использованием учётных данных владельца ресурсов не может быть использован для данной учётной записи пользователя из-за включенной вторичной аутентификации.
    • Не передан код авторизации в сценарии с кодом авторизации.
    • Переданный код авторизации истёк или не действителен.
    • Переданный код авторизации был получен другим клиентом.

    unauthorized_client

    Я хочу получить токен доступа от Google. Google API сообщает, что для получения токена доступа отправьте код и другие параметры на страницу создания токена, и ответом будет объект JSON, подобный следующему:

    Однако я не получаю токен обновления. Ответ в моем случае:

    Предоставляется refresh_token только при первой авторизации от пользователя. Последующие авторизации, такие как те, которые вы делаете при тестировании интеграции OAuth2, больше не вернутся refresh_token . :)

    Это побудит пользователя снова авторизовать приложение и всегда вернет refresh_token .

    Вам нужно access_type=offline во всех случаях, когда вы хотите refresh_token . Но как мне обновить токен после его истечения в этом случае? Я получил это работает с $client->setAccessType('offline') . По умолчанию function setApprovalPrompt() уже передано force .

    Чтобы получить токен обновления, вы должны добавить оба, approval_prompt=force и access_type="offline" если вы используете java-клиент, предоставленный Google, он будет выглядеть следующим образом:

    Возмутительно, что Google не учел это в своей документации или, по крайней мере, в документации php или oath2, на которую я смотрел в течение 7 часов. Почему в мире это не выделено жирным шрифтом в их документах

    Я искал долгую ночь, и это делает свое дело:

    Модифицированный user-example.php из admin-sdk

    затем вы получите код по URL-адресу перенаправления и аутентификацию с кодом и получите токен обновления

    Вы должны хранить его сейчас;)

    Когда ваш accesskey истекает, просто сделайте

    Perfect @Norbert, это было именно то, что мне было нужно.

    Это вызвало у меня некоторую путаницу, поэтому я решил поделиться тем, чему научился на своем нелегком пути:

    При запросе доступа с использованием access_type=offline и approval_prompt=force параметров , которые вы должны получить одновременно доступ маркеров и обновление маркеров. Доступа лексема истекает вскоре после вы получите его , и вам нужно будет обновить его.

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

    У меня есть CMS, где разные пользователи используют разные учетные записи Google для подключения к API аналитики. Однако иногда несколько пользователей могут подключаться, используя одну и ту же корпоративную учетную запись Google, но каждый хочет получить доступ к разным учетным записям Google Analytics. Только первый получает токен обновления, в то время как все остальные этого не делают и, следовательно, должны повторно подключаться каждый час. Разве нет способа получить ЖЕ ЖЕ токен обновления для последующих аутентификаций, а не только access_token, срок действия которого истекает в течение часа? Похоже, API создает токен обновления ровно один раз. Любое «разделение» токена должно произойти в вашем коде. Вы должны быть осторожны, чтобы случайно не дать пользователям новые привилегии доступа. Простой способ сделать это - заставить приложение отслеживать токены обновления и связанные учетные записи в своем собственном хранилище (отдельная «таблица» в SQLese). Затем, когда вы хотите получить новый токен доступа, вы проверяете и используете этот, возможно, общий токен оттуда. Реализованный определенным образом, ваш код не должен знать, кто на самом деле получил токен. Я не знаю, как определить, какой токен обновления следует связать с новым токеном доступа, который я только что получил. Существуют разные пользователи, которые выполняют вход, и единственное, что у них общего, - это то, что они используют одну и ту же учетную запись Google (электронную почту) для подключения к API. Но Google не отправляет обратно идентификатор учетной записи или электронной почты, он просто отправляет токен. Так что я не знаю, как связать 2 разных пользователей CMS . Youtube oAuth2 refresh_token показывается только при использовании силы.

    Ответ Рича Саттона, наконец, сработал для меня, после того, как я понял, что добавление access_type=offline выполняется по запросу клиентского интерфейса для кода авторизации, а не по внутреннему запросу, который обменивает этот код на access_token. Я добавил комментарий к его ответу и эту ссылку в Google для получения дополнительной информации об обновлении токенов.

    @ZackMorris Итак . ты хочешь сказать, что я не могу получить refresh_token из бэкэнда, используя токен доступа? @ Никогда Вы не можете получить освежительный токен от самого access_token. Если вы хотите, чтобы ваш сервер обрабатывал обновления, вам нужно будет сначала сохранить refresh_token в вашей базе данных. Также, если вы выполняете поток OAuth-клиента на внешнем интерфейсе, пользователи должны будут отправлять свои refresh_token на сервер, если они хотят, чтобы сервер обновлял их.

    Для того, чтобы получить, refresh_token вам нужно включить access_type=offline в URL-адрес запроса OAuth. Когда пользователь впервые авторизуется, вы получите не ноль, refresh_token а access_token срок действия, срок действия которого истекает.

    Если вы столкнулись с ситуацией, когда пользователь может повторно аутентифицировать учетную запись, для которой у вас уже есть токен аутентификации (как упомянуто выше в @SsjCosty), вам необходимо получить информацию от Google, для которой этот токен предназначен. Для этого добавьте profile в свои рамки. При использовании OAuth2 Ruby gem ваш окончательный запрос может выглядеть примерно так:

    Обратите внимание, что в области есть две записи, разделенные пробелами, одна для доступа только для чтения к Google Analytics, а другая просто profile , что является стандартом OpenID Connect.

    Это приведет к тому, что Google предоставит дополнительный атрибут, называемый id_token в get_token ответе. Чтобы получить информацию из id_token, просмотрите эту страницу в Документах Google. Существует несколько библиотек, предоставленных Google, которые будут проверять и «декодировать» это для вас (я использовал гем Ruby google-id-token ). После того, как вы его проанализируете, этот sub параметр фактически станет уникальным идентификатором учетной записи Google.

    Стоит отметить, что если вы измените область действия, вы снова получите токен обновления для пользователей, которые уже прошли проверку подлинности в исходной области действия. Это полезно, если, скажем, у вас уже есть группа пользователей, и вы не хотите, чтобы они все отключили приложение в Google.

    Да, и последнее замечание: вам не нужно prompt=select_account , но это полезно, если у вас есть ситуация, когда ваши пользователи могут захотеть пройти аутентификацию с использованием нескольких учетных записей Google (т. Е. Вы не используете это для входа / аутентификации) ,

    Я думаю, что ключевым моментом является идентификация пользователей без сохранения личной информации. Спасибо за указание на это, я не видел ссылок на Google Docs об этом.

    1. Как получить «refresh_token»?

    Решение: опция access_type = 'offline' должна использоваться при создании authURL. Источник: Использование OAuth 2.0 для приложений веб-сервера

    2. Но даже с «access_type = offline» я не получаю «refresh_token»?

    Решение: обратите внимание, что вы получите его только при первом запросе, поэтому, если вы храните его где-то и есть возможность перезаписать это в своем коде при получении нового access_token после истечения предыдущего срока действия, убедитесь, что это значение не перезаписано.

    Из Google Auth Doc: (это значение = access_type)

    Это значение указывает серверу авторизации Google возвращать токен обновления и токен доступа при первом обмене кода авторизации вашим приложением для токенов.

    Если вам снова понадобится «refresh_token», то вам нужно удалить доступ к своему приложению, выполнив шаги, описанные в ответе Рича Саттона .

    Получаем API токен Яндекс.Директ

    Сегодня мы подробно разберем процесс получения OAuth-токена для доступа к Яндекс.Директ API. Впервые сталкиваясь с процессом получения токена, будь-то API от Google или Яндекса, я по-началу терялся в заявках, регистрациях и прочей бюрократической вакханалии. Поэтому я, буквально, за руку проведу тебя к заветному апи-токену, который мы сразу и проверим.

    Как следует из справки Яндекс.Директ API, вся процедура делится на два этапа:

    Регистрируем приложение в Яндекс.Директ API

    • Название приложения*: DirectDataDealer
    • Описание приложения: Необязательное. Но я всё таки напишу: Приложение для пробросаданных в системы сквозной аналитики
    • Иконка приложения: Необязательное.
    • Ссылка на сайт приложения: Необязательное.
    • Платформы: Веб-сервисы и в поле Callback Url жмем Подставить URL для разработки.
    • Доступы*: Яндекс.Директ -> Использование API Яндекс.Директа

    Отлично, приложение создано, на выходе получится что-то похожее на это:

    Заявка на доступ к Яндекс.Директ API

    Отлично, пол дела сделано, осталось запросить доступ к API.

    Создаем заявку на доступ к Яндекс.Директ API

    Теперь создадим заявку, тут всё довольно просто. Идём сюда и создаем заявку на доступ. Начинаем заполнять:

    Бум! Всё готово, отправляем на рассмотрение. После прохождения, в итоге получим такую картину:

    Заявка на доступ к Яндекс.Директ API

    Получаем OAuth-токен Яндекс.Директ:

    Существует 2 способа получения API-токена: Ручной и Автоматический

    Можете попробовать прямо здесь. Нажмите "Get code", войдите/выберите свой аккаунт гугл, разрешите доступ, получите код, вставьте полученный код в зеленое поле "code:" и нажмите "Get tokens". Браузер покажет необходимые токены.

    Вкратце на этом всё, процесс закончен.

    Но если пробовать здесь не хотите - можете создать у себя текстовый файл с расширением html следующего содержания:

    Сохраняем html-файл (я назвал его GoogleOauth.html), открываем его в интернет-браузере.


    Первым делом жмем кнопку "Get code". Если в браузере Вы еще не входили в аккаунт гугл - предложат войти. Если входили - откроется страница выбора аккаунта. К данным этого аккаунта мы предоставляем доступ приложению:


    Кликаем аккаунт, отвечаем "Разрешить" на вопросы, откроется экран согласия (consent screen):


    Жмем кнопку "Разрешить" - попадаем на страницу с кодом:


    Копируем полученный код, возвращаемся к странице с нашим файлом GoogleOauth.html, вставляем в зеленое поле "code:" полученный код:


    Наконец, нажимаем кнопку "Get tokens". В итоге браузер перейдет на страницу, где будет выведен текст JSON следующего содержания:


    В результате мы получили "вечный" refresh_token и временный access_token, которые далее используем в запросах к API Google.


    После создания гугл выдаст client_id и client_secret - их и нужно вставить в браузер, в рассмотренную выше форму GoogleOauth.html Обратите внимание, client_id нужно вставить два раза в два одноименных поля. После вставки своих client_id client_secret а также необходимых Вам scope - производим все клики и получаем рабочие токены.

    Немного о scope, которые мы видим в форме. Здесь нужно указать API-scope, необходимые для Вашего приложения. Перечень существующих scope можно посмотреть на странице

    Читайте также: