JWT를위한 최고의 HTTP 인증 헤더 유형

JWT 토큰에 가장 적합한 AuthorizationHTTP 헤더 유형 이 무엇인지 궁금합니다 .

아마 가장 인기있는 유형 중 하나는 Basic입니다. 예를 들어 :

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

로그인 및 비밀번호와 같은 두 가지 매개 변수를 처리합니다. 따라서 JWT 토큰과 관련이 없습니다.

또한 Bearer 유형에 대해 들었습니다 .

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

그러나 나는 그 의미를 모른다. 곰과 관련이 있습니까?

HTTP Authorization헤더 에서 JWT 토큰을 사용하는 특별한 방법이 있습니까? 우리를 사용해야합니까 Bearer, 아니면 단순화하고 사용해야합니까?

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

감사.

편집하다:

아니면 JWTHTTP 헤더 일 수도 있습니다.

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

클라이언트가 액세스 토큰 (JWT 또는 다른 토큰)을 보내는 데 가장 적합한 HTTP 헤더 Authorization는 Bearer인증 체계 가있는 헤더입니다 .

이 체계는 RFC6750에 의해 설명됩니다 .

예:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ

보다 강력한 보안 보호가 필요한 경우 다음 IETF 초안 ( https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture) 도 고려할 수 있습니다 . 이 초안은 https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac에 대한 좋은 대안으로 보입니다 .

이 RFC 및 위의 사양이 OAuth2 Framework 프로토콜과 관련되어 있어도 클라이언트와 서버 간의 토큰 교환이 필요한 다른 컨텍스트에서 사용될 수 있습니다.

사용자 정의와는 달리 JWT당신이 당신의 질문에 언급 방식 하나는 IANA에 등록됩니다 .Bearer

에 관한 Basic및 Digest인증 체계, 그들은 사용자 이름과 비밀 (참조하여 인증하기 위해 최선을 다하고 있습니다 RFC7616 및 RFC7617를 ) 그 상황에서 그렇게 적용되지합니다.

짧은 답변

Bearer인증 방식은 당신을 위해 무엇을 찾고 있습니다.

긴 대답

곰과 관련이 있습니까?

어 ... 아니요 :)

Oxford Dictionaries 에 따르면 , bearer 의 정의는 다음과 같습니다.

무기명 _{^{/ ˈbɛːrə /}}
명사

1. 무언가를 운반하거나 보유하는 사람이나 물건.

2. 수표 나 돈을 지불하라는 명령을 내린 사람.

첫 번째 정의에는 메신저 , 에이전트 , 컨베이어 , 사절 , 캐리어 , 공급자 동의어가 포함됩니다 .

RFC 6750 에 따른 베어러 토큰 의 정의는 다음과 같습니다.

1.2. 술어

무기명 토큰

토큰을 소유 한 당사자 ( "소지자")가 소유 한 다른 당사자가 토큰을 소유 할 수있는 속성을 가진 보안 토큰. 베어러 토큰을 사용하면 베어러가 암호화 키 자료 (소지 증명)를 소유하고 있음을 증명할 필요가 없습니다.

Bearer인증 방식입니다 IANA에 등록 하고 원래 정의 RFC 6750 의 OAuth 2.0 인증 프레임 워크,하지만 아무것도 사용에서 당신을 멈추지 Bearer의 OAuth 2.0을 사용하지 않는 응용 프로그램에 액세스 토큰에 대한 계획을.

가능한 한 표준을 고수하고 자체 인증 체계를 만들지 마십시오.

인증 체계를 Authorization사용하여 요청 헤더 에 액세스 토큰을 보내야합니다 Bearer.

2.1. 권한 부여 요청 헤더 필드

AuthorizationHTTP / 1.1에 의해 정의 된 요청 헤더 필드 에서 액세스 토큰을 전송할 때 클라이언트는 Bearer인증 체계를 사용 하여 액세스 토큰을 전송합니다.

예를 들면 다음과 같습니다.

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

[...]

클라이언트는 HTTP 인증 체계 Authorization와 함께 요청 헤더 필드를 사용하여 베어러 토큰으로 인증 된 요청을 작성해야합니다 Bearer. [...]

토큰이 유효하지 않거나 누락 된 경우 Bearer스킴이 WWW-Authenticate응답 헤더에 포함되어야합니다 .

3. WWW 인증 응답 헤더 필드

보호 자원 요청에 인증 신임 정보가 포함되어 있지 않거나 보호 자원에 액세스 할 수있는 액세스 토큰이없는 경우, 자원 서버는 반드시 HTTP WWW-Authenticate응답 헤더 필드 [...]를 포함해야합니다 .

이 사양으로 정의 된 모든 문제는 반드시 auth-scheme 값을 사용해야합니다 Bearer. 이 체계 뒤에는 하나 이상의 auth-param 값이 와야합니다. [...].

예를 들어 인증없이 보호 된 리소스 요청에 대한 응답으로 :

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

만료 된 액세스 토큰을 사용한 인증 시도로 보호 된 자원 요청에 응답하여 다음을 수행하십시오.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                         error="invalid_token",
                         error_description="The access token expired"