28  /  36

Автоматическое продление авторизации OAuth 2.0

Просмотров: 1618 (Статистика ведётся с 06.02.2017)

Сохранив на своей стороне значение токена продления авторизации refresh_token, приложение может в дальнейшем использовать его для получения доступа к REST API уже без участия пользователя. Время жизни refresh_token - 28 дней или до первого использования.

В любой момент до истечения refresh_token приложение может совершить следующий запрос:

https://oauth.bitrix.info/oauth/token/?
    grant_type=refresh_token
    &client_id=app.573ad8a0346747.09223434
    &client_secret=LJSl0lNB76B5YY6u0YVQ3AW0DrVADcRTwVr4y99PXU1BWQybWK
    &refresh_token=nfhxkzk3gvrg375wl7u7xex9awz6o3k8

Параметры (все - обязательные):

  • grant_type - параметр, показывающий тип авторизационных данных, подлежащих валидации. Должен иметь значение refresh_token;
  • client_id - код приложения, получаемый в партнерском кабинете при регистрации приложения либо на портале в случае локального приложения;
  • client_secret - секретный ключ приложения, получаемый в партнерском кабинете при регистрации приложения либо на портале в случае локального приложения;
  • refresh_token - значение сохраненного токена продления авторизации

В ответ приложение получит json следующего вида:

GET /oauth/token/

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "ydtj8pho532wydb5ixk78ol7uqlb7sch",  
    "client_endpoint": "http://portal.bitrix24.com/rest/",  
    "domain": "oauth.bitrix.info",  
    "expires_in": 3600,  
    "member_id": "a223c6b3710f85df22e9377d6c4f7553",  
    "refresh_token": "3s6lr4kr3cv2od4v853gvrchb875bwxb",  
    "scope": "app",  
    "server_endpoint": "http://oauth.bitrix.info/rest/",  
    "status": "T"
}

Значимые параметры:

  • access_token - основной авторизационный токен, требуемый для доступа к REST API (Время жизни - 1 час.);
  • refresh_token - новое значение дополнительного авторизационного токена, служащего для продления сохраненной авторизации;
  • client_endpoint - адрес REST-интерфейса портала;
  • server_endpoint - адрес REST-интерфейса сервера;
  • status - статус приложения на портале.

Внимание! После совершения указанного запроса refresh_token и выданный вместе с ним access_token становятся невалидными! Для совершения запросов к REST API и для продления авторизации следует использовать новые access_token и refresh_token. При этом параллельно может существовать неограниченное количество таких цепочек продления авторизации для одного пользователя портала и одного приложения, но каждая должна инициироваться одним из вышеперечисленных способов получения авторизации, без возможности ветвления.

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

{
    "error": "PAYMENT_REQUIRED",  
    "error_description": "Payment required"
}

Если сценарий вашего приложения требует постоянного фонового обмена данными с Битрикс24 без участия пользователя, то необходимо продумать хранение refresh-токенов и механизм их использования. Как уже было указано выше, refresh_token сохраняет свою актуальность в течение 28 дней. Это значит, что если ваше приложение по каким-то причинам не обращается к Битрикс24 чаще "само по себе" для реализации функционала приложения, то вам достаточно раз в 28 дней обращаться к серверу авторизации, только чтобы обновить сохраненные токены.

Мы сталкивались со случаями, когда разработчики приложений "на всякий случай" перед каждым обращением к REST сначала "дергали" сервер авторизации для обновления токена. Это неправильный сценарий, создающий лишнюю нагрузку. Тоже самое касается сценариев с автоматическим "обновлением токенов" раз в час, или раз в сутки - это лишнее.

Если вы сохраняете пару токенов - access_token и refresh_token - на стороне приложения, то вы просто делаете запрос к REST, указав сохраненный access_token (предположим, что вы, сохранив access_token, не сохранили дату и время его "протухания"). Если токен уже неактуален, в ответ вы получите соответствующую ошибку. Вот в этот момент надо сделать запрос с сохраненным refresh_token на сервер авторизации для получения нового access_token, и получив в ответ оба новых токена - сохранить их на стороне приложения, а затем выполнить свой REST запрос с новым access_token

0
Курсы разработаны в компании «1С-Битрикс»

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