Пользователь вводит код на Яндекс.OAuth

На некоторых устройствах (например, на телевизорах) вводить код подтверждения может быть неудобно. В этом случае можно предложить пользователю ввести код на странице Авторизация на устройстве.

Полученный токен можно сохранить в приложении и использовать для запросов к API до истечения времени его жизни. Токен должен быть доступен только вашему приложению, поэтому не рекомендуется сохранять его в куках браузера, открытых конфигурационных файлах и т. п.

Запрос кодов подтверждения

Приложение должно запросить коды подтверждения с помощью HTTP-метода POST

POST /device/code
Host: oauth.yandex.ru

client_id=<идентификатор приложения>
[& device_id=<идентификатор устройства>]
[& device_name=<имя устройства>]
[& scope=<запрашиваемые необходимые права>]

Ответ с кодами подтверждения

Яндекс.OAuth возвращает код для пользователя и информацию для запроса токена:

HTTP 200 OK

Content-type: application/json

{
  "device_code": "3e2a5a5c0e02439aa78a23442721848c",
  "user_code": "h5nbcr6c",
  "verification_url": "https://oauth.yandex.ru/device",
  "interval": 5,
  "expires_in": 300
}

Ввод кода пользователя

Пользователь должен ввести код из свойства user_code на странице по адресу из свойства verification_url. Если код введен корректно, Яндекс.OAuth предложит разрешить или запретить доступ приложению.

Пример такой страницы:

Запрос токена с кодом устройства

Приложение отправляет код устройства, а также свой идентификатор и пароль в POST-запросе.

POST /token HTTP/1.1
Host: oauth.yandex.ru
Content-type: application/x-www-form-urlencoded
Content-Length: <длина тела запроса>
[Authorization: Basic <закодированная строка client_id:client_secret>]

   grant_type=device_code
   code=<код устройства, полученный предыдущим запросом>
[& client_id=<идентификатор приложения>]
[& client_secret=<пароль приложения>]

Идентификатор и пароль приложения также можно отправить в заголовке Authorization, закодировав строку <client_id>:<client_secret> методом base64. Если Яндекс.OAuth получает заголовок Authorization, параметры client_id и client_secret в теле запроса игнорируются.

Ответ с OAuth-токеном

Яндекс.OAuth возвращает OAuth-токен, refresh-токен и время их жизни в JSON-формате:

200 OK
Content-type: application/json

{
  "token_type": "bearer",
  "access_token": "AQAAAACy1C6ZAAAAfa6vDLuItEy8pg-iIpnDxIs",
  "expires_in": 124234123534,
  "refresh_token": "1:GN686QVt0mmakDd9:A4pYuW9LGk0_UnlrMIWklkAuJkUWbq27loFekJVmSYrdfzdePBy7:A-2dHOmBxiXgajnD-kYOwQ",
  "scope": "login:info login:email login:avatar"
}

Время жизни refresh-токена совпадает с временем жизни OAuth-токена.

Если выдать токен не удалось, то ответ содержит описание ошибки:

{
  "error_description": "<описание ошибки>",
  "error": "<код ошибки>"
}

Возможные коды ошибок:

• authorization_pending — пользователь еще не ввел код подтверждения.
• bad_verification_code — переданное значение параметра code не является 7-значным числом.
• invalid_client ― приложение с указанным идентификатором (параметр client_id) не найдено или заблокировано. Этот код также возвращается, если в параметре client_secret передан неверный пароль приложения.
• invalid_grant ― неверный или просроченный код подтверждения.
• invalid_request ― неверный формат запроса (один из параметров не указан, указан дважды, или передан не в теле запроса).
• invalid_scope — права приложения изменились после генерации кода подтверждения.
• unauthorized_client — приложение было отклонено при модерации или только ожидает ее.
• unsupported_grant_type ― недопустимое значение параметра grant_type.
• Basic auth required — тип авторизации, указанный в заголовке Authorization, отличен от Basic.
• Malformed Authorization header — заголовок Authorization не соответствует формату <client_id>:<client_secret>, или эта строка не закодирована методом base64.