Почему схема аутентификации заголовка авторизации GitHub Oauth2 является "токеном", а не "носителем"?

#http #oauth-2.0 #github-api #http-authentication

#http #oauth-2.0 #github-api #http-аутентификация

Вопрос:

Согласно RFC6750, схема аутентификации HTTP должна быть «носителем». Но этот документ GitHub использует «токен» в качестве схемы. Я пробовал оба варианта, и кажется, что оба из них работают.

Мой вопрос:

Есть ли какая-либо причина, по которой GitHub использует «токен», а не стандарт?
Может ли эта схема быть любой, если сервер может понять?

Ответ №1:

Протокол (например, RFC6750) — это просто общий стандарт, с которым согласны несколько сторон, поэтому, по сути, да, это может быть что угодно, если клиент и сервер согласны с этим.

OAuth, в частности, имеет множество расширений — разработчики делают вещи, которые не совсем соответствуют спецификации, или, возможно, оставлены неоднозначными или открытыми в спецификации. Обработка токенов обновления — это область, где вы часто это видите.

Что касается GitHub, я подозреваю, что они поддерживают token заголовок, потому что они позволяют использовать этот заголовок для других видов токенов, помимо токенов OAuth, в частности, токенов личного доступа и токенов приложений GitHub.

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

1. Такая непоследовательность действительно сбивает с толку. :-/ В любом случае, я решаю придерживаться Bearer, потому что мне приходится поддерживать несколько поставщиков OAuth2. :-/ Спасибо за ваш ответ.

2. Я согласен, что несоответствие расстраивает, но я думаю, что вы делаете правильный призыв придерживаться стандарта (если вы не вынуждены отклоняться от него). Это упрощает обработку нескольких реализаций.