Пользовательское использование заголовка авторизации в REST API


10

Я создаю REST API, где клиенты проходят проверку подлинности с использованием клиентских сертификатов. Клиент в этом случае - это не отдельный пользователь, а своего рода уровень представления. Аутентификация пользователей осуществляется с использованием нестандартного подхода, и уровень представления отвечает за то, чтобы это было сделано правильно (примечание: я знаю, что это неправильный подход, но API не является общедоступным).

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

Ответы:


21

Использование заголовка авторизации кажется правильным. Это вся цель заголовка авторизации.

С http://tools.ietf.org/html/rfc7235#section-4.2 :

Поле заголовка «Авторизация» позволяет агенту пользователя аутентифицироваться на сервере происхождения - обычно, но не обязательно, после получения ответа 401 (Несанкционированный). Его значение состоит из учетных данных, содержащих информацию об аутентификации агента пользователя для области запрашиваемого ресурса.

Если у вас есть собственная схема аутентификации, запишите это, но нет необходимости заново изобретать колесо.


3
Это не просто , кажется , как правильно, это есть правильно. (Я занимался этим весь день) Раздел 4.1 в RFC 7235 однозначно демонстрирует использование пользовательской схемы «Newauth» в «Например», наряду со стандартной схемой «Basic», позволяющей клиенту использовать выбор любой из этих схем. , Тем не менее, если вы используете «стандартную» схему, вы должны использовать ее правильно. Ответ Зака ​​правильный, а Филипа неправильный .
Стивен П

3

Я не рекомендовал бы использовать нестандартное использование стандартного заголовка HTTP. В первую очередь потому, что это может вводить в заблуждение других разработчиков, которые знают, как Authoriziationпредполагается использовать заголовок в HTTP-аутентификации, но также избегают любых потенциальных проблем с другими частями вашего стека, имеющими противоречивую информацию об одном и том же заголовке запроса.

В любом случае, ничто не мешает вам использовать нестандартный нестандартный X-Authorization-Userзаголовок специально для ваших целей.


100% согласились. Если вы хотите сделать что-то нестандартное, для этого X-нужны префиксные заголовки. Если вы собираетесь использовать стандартный заголовок, не используйте его для чего-то необычного или неожиданного.
Carson63000

2
Просто подумал, что должен упомянуть, что "X-" устарел: stackoverflow.com/questions/3561381/…
Matsen75

Согласно этому ответу, означает ли это, что Amazon S3 делает это неправильно? docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
Том Лианза,

4
-1. Как упомянул Зак Деннис, в отличие от большинства других заголовков HTTP, заголовок авторизации предназначен для расширения, и существует четко определенный способ определения собственной схемы авторизации. В ореховой оболочке, просто убедитесь, что вы используете имя схемы пользовательской авторизации.
Ложь Райан
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.