사용자 지정 HTTP 인증 헤더

124

HTTP 인증 헤더에 사용자 지정 데이터를 넣는 것이 허용되는지 궁금합니다. RESTful API를 설계하고 있으며 사용자 지정 권한 부여 방법을 지정하는 방법이 필요할 수 있습니다. 예를 들어 FIRE-TOKEN인증 이라고합시다 .

이것이 유효하고 사양에 따라 허용됩니까? Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

두 번째 문자열의 첫 번째 부분 ( ':'앞)은 API 키이고 두 번째 부분은 쿼리 문자열의 해시입니다.

— NRaf
소스

133

RFC2617에 정의 된 형식 은 credentials = auth-scheme #auth-param. 그래서 fumanchu에 동의하면 수정 된 인증 체계가 다음과 같을 것이라고 생각합니다.

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

FIRE-TOKEN스키마는 어디에 있고 두 개의 키-값 쌍은 인증 매개 변수입니다. 따옴표는 선택 사항이라고 생각하지만 (p7-auth-19의 Apendix B에서) ...

auth-param = token BWS "=" BWS ( token / quoted-string )

나는 이것이 최신 표준에 적합하고 이미 사용 중이며 (아래 참조) 간단한 확장을위한 키-값 형식을 제공한다고 생각합니다 (추가 매개 변수가 필요한 경우).

이 auth-param 구문의 몇 가지 예는 여기에서 볼 수 있습니다.

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub

— StarTrekRedneck
소스

4

Amazon의 단순 스토리지 API 는 또 다른 예를 제공합니다.

— bishop

18

별도의 사용자 정의 헤더에 넣으십시오.

표준 HTTP 헤더를 오버로딩하면 가치가있는 것보다 더 많은 혼란을 야기 할 수 있으며 최소 놀라움 의 원칙을 위반하게됩니다 . 또한 표준 형식의 일반적인 HTTP 헤더 (예 :) 만 처리 할 수있는 기성 도구 키트를 사용하려는 API 클라이언트 프로그래머에게 상호 운용성 문제가 발생할 수 있습니다 Authorization.

— 브라이언 켈리
소스

3

이것은 보이는 것보다 제대로하기가 더 어려울 수 있습니다. fumanchu가 제공하는 링크 (그의 답변에 대한 주석에서)는 사용자 정의 헤더를 도입하면 이제 Cache-Control을 올바르게 수동으로 설정 해야하는 추가 부담이 추가되는 이유를 설명합니다.

— Jon-Eric

4

또한 브라우저를 통해 교차 출처 요청을하는 경우, 사용자 지정 헤더 때문에 이제는 피할 수 있었던 사용자 지정 헤더 때문에 비행 전 영역에 있습니다. 특정 애플리케이션의 경우 이러한 요청이 추가됩니다.

— Wil Moore III

31

사용자 지정 인증 헤더는 거의 없습니다. Authorization고유 한 사용자 지정 스키마가있는 사양 표준 헤더면 충분합니다. 또한 @wilmoore가 나타내는 것처럼 비행 전 Origin 요청을 피할 수 있습니다. 사용자 지정 체계는 내가 아는 합리적으로 최신 HTTP 서버를 방해하지 않으며, 자체 체계를 사용하는 경우 직접 구문 분석해야합니다. 라이브러리가 충돌하지 않아야합니다 (그렇지 않으면 라이브러리가 잘못 작성 됨).

— Les Hazlewood

7

Authorization사용자 지정 헤더가 아닌 헤더 에서 자격 증명을 전송하는 좋은 이유 는 프록시와 로거가 정보를 민감한 정보로 취급하는 것을 알고 있기 때문입니다.

— Eron Wright

15

아니요, 이는 RFC 2617 의 "자격 증명"정의에 따라 유효한 프로덕션이 아닙니다 . 유효한 auth-scheme을 제공하지만 auth-param 값은 형식이어야하며 token "=" ( token | quoted-string )(섹션 1.2 참조) 예제에서는 그런 식으로 "="를 사용하지 않습니다.

— 후 만추
소스

1

정답이 아닙니다. 예제 형식은 문서의 5 페이지를 참조하십시오. Authorization : Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

— NRaf

11

사실입니다. 그러나 tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1에 따르면 ""b64token "표기법은 기존 인증 체계와의 호환성을 위해 도입되었으며 한 번만 사용할 수 있습니다. 따라서 새로운 체계는 "auth-param"구문을 대신 사용해야합니다. 그렇지 않으면 향후 확장이 불가능하기 때문입니다. " 커스텀 헤더에서 인증을 수행하는 것과 관련된 캐시 토론도 참조하십시오.

— fumanchu

9

내가 아는 오래된 질문이지만 호기심 많은 사람들을 위해 :

믿거 나 말거나,이 문제는 base64로 인코딩 된 사용자 이름 : 암호로 값을 전달하는 HTTP BASIC을 사용하여 20 년 전에 해결되었습니다. ( http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side 참조 )

동일한 작업을 수행 할 수 있으므로 위의 예는 다음과 같습니다.

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

— 마이크 마르카 치
소스

4

여기에 다른 답변에 대한 의견에 따라 여기 에 사용 된 표기법은 기존 체계와의 호환성을위한 것이며 새로운 확장에는 권장되지 않으므로이 답변에 반대 하는 것이 좋습니다.

— Whymarrh 2017