Basic, Digest, OAuth2.0, JWT 및 Bearer Token과 같은 인증에 대해 뭔가를 배우고 있습니다.
이제 질문이 있습니다.
JWT가 OAuth2.0 표준에서 Access_Token으로 사용되고 있다는 것을 알고 있습니다. JWT는 RFC 7519에, Bearer 토큰은 RFC 6750에 있습니다.
예를 들어, Bearer :
Authorization: Bearer <token>
AJAX로 서버에 토큰을 보내거나 URL의 쿼리 문자열에 토큰을 추가했습니다. 요청 헤더에 추가하여 토큰을 보낼 수도 있다는 것을 알고 있습니다. 토큰이 Authorization Bearer 헤더에 추가되어야 함을 의미합니까?
JWT와 Bearer Token의 관계를 말씀해 주시겠습니까? 감사합니다.
답변:
JWT는 서명 및 암호화 할 수있는 JSON 데이터 페이로드가 포함 된 토큰의 인코딩 표준입니다.
JWT는 많은 것들에 사용될 수 있습니다. 그중에는 베어러 토큰, 즉 당신이 그것을 가지고 있기 때문에 (당신이 "보유자"가 됨) 당신에게 무언가에 대한 접근을 허용하는 어떤 서비스에 당신이 제시 할 수있는 정보의 일부입니다.
베어러 토큰은 다양한 방식으로 HTTP 요청에 포함될 수 있으며, 그중 하나 (아마도 선호되는 토큰)는 Authorization 헤더입니다. 그러나 요청 매개 변수, 쿠키 또는 요청 본문에 넣을 수도 있습니다. 그것은 대부분 귀하와 귀하가 액세스하려는 서버 사이에 있습니다.
auth-header최소한의 파서를 원한다면 패키지를 사용하십시오
JWT는 클레임 을 인코딩 하고 확인 하는 편리한 방법입니다. 입니다.
Bearer 토큰은 권한 부여에 사용되는 문자열이며 잠재적으로 임의적입니다.
몇 년 전, JWT 혁명 이전에는 a <token>는 본질적인 의미가없는 문자열이었습니다 (예 : 2pWS6RQmdZpE0TQ93X). 그런 다음 해당 토큰에 대한 클레임 을 보유한 데이터베이스에서 해당 토큰을 조회했습니다 . 이 접근 방식의 단점은 토큰이 사용될 때마다 DB 액세스 (또는 캐시)가 필요하다는 것입니다.
JWT 는 자신의 주장을 인코딩 하고 (서명을 통해) 확인 합니다. 이를 통해 사람들은 상태가없는 단기 JWT를 발행 할 수 있습니다 (읽기 : 자체 포함, 다른 사람에게 의존하지 않음). 그들은 DB를 칠 필요가 없습니다. 이렇게하면 JWT를 발행하는 서비스 만 DB / 지속성 계층 ( 아마도 만났을 것임)에 대해 걱정할 필요가 있기 때문에 DB로드를 줄이고 애플리케이션 아키텍처를 단순화합니다 .refresh_token
JWT는 두 가지 유형의 토큰, 매개 변수 토큰 : 매개 변수로 액세스 토큰 전달과 함께 작동합니다. Bearer Token : 'Bearer'로 헤더를 전달합니다.
다음 질문도 읽어보십시오.