들어가며
JWT를 인증 방법으로 활용하면서, 헤더 값으로 bearer + token 값을 받아서 사용했습니다. 이때 bearer가 무엇인지, 제대로 모르고 사용했습니다. 이번 기회에 토큰 값에 붙어있는 bearer가 무엇인지 알아야겠다고 생각했습니다. 토큰 기반 인증에서 bearer는 무엇인지에 대해 정리하겠습니다. 이 글은 토큰 기반 인증 Bearer Authentication 글과 토큰 기반 인증에서 bearer는 무엇일까? 글을 참고했습니다.
토큰은 어떻게 보내지는가?
일반적으로 토큰은 아래처럼 요청 헤더의 Authorization 필드에 담아져 보내집니다.
Authorization: <type> <credentials>
여기서 bearer는 위 형식에서 type에 해당합니다. 토큰에는 많은 종류가 있고, 서버는 다양한 종류의 토큰을 처리하기 위해 전송받은 type에 따라 토큰을 다르게 처리합니다. type에는 아래와 같은 타입들이 존재합니다.
Basic
사용자 아이디와 암호를 Base64로 인코딩한 값을 토큰으로 사용한다. (RFC 7617)
Bearer
JWT 혹은 OAuth에 대한 토큰을 사용한다. (RFC 6750)
Digest
서버에서 난수 데이터 문자열을 클라이언트에 보낸다. 클라이언트는 사용자 정보와 nonce를 포함하는 해시값을 사용하여 응답한다 (RFC 7616)
HOBA
전자 서명 기반 인증 (RFC 7486)
Mutual
암호를 이용한 클라이언트-서버 상호 인증 (draft-ietf-httpauth-mutual)
AWS4-HMAC-SHA256
AWS 전자 서명 기반 인증 (링크)
위의 인증 타입들 중에서, bearer는 JWT와 OAuth를 나타내는 인증 타입입니다. 그럼 왜 bearer를 사용하게 됐을까요? 이에 대해 알아보겠습니다.
왜 Bearer인가?
세션 기반 인증에서 토큰 기반 인증으로 넘어가는 과도기에는 많은 Scheme들이 존재했다고 합니다. 예를 들면 아래와 같을 수 있습니다.
Authorization: <type> <credentials>
ex1) Authorization : apikey xH3m-H/jGnv5
ex2) Authorization : Token AKV1...token.value...UEFJ
서비스 개발의 입장에서, Scheme을 무엇을 사용하더라도, Token이라는 값이 제대로 서버와 클라이언트에 전달되고, 인증 인가만 잘 동작한다면 괜찮을 수 있다고 생각할 수 있습니다. 하지만 이 방식은 다른 써드 파티, OAuth 같은 공개 표준 규약에서 사용하려면 토큰 인증 형태가 다르기 때문에 다시 로그인을 해야 하는 형태가 될 수밖에 없었다고 합니다. 그래서 W3C는 형태가 표준이 없다고 생각하고, 토큰 기반 인증에 대해서 표준 내용을 제정하게 되었고, 토큰 기반 인증이라면 Bearer라는 Scheme을 사용하도록 제시했다고 합니다.
즉 bearer가 아닌, 다른 키워드를 사용할 수 있지만 Bearer를 활용하는 것이 JWT 혹은 OAuth에 대한 토큰을 활용할 때 사용하기로 한 일종의 약속이라는 것을 알 수 있었습니다.
마치며
공부를 하며 그동안 아주 기초적인 것들을 제대로 공부하지 않았다는 것을 깨닫습니다. 좋은 기술을 배우는 것도 좋지만, 기술의 기반이 되는 기초적인 지식을 먼저 쌓는 것이 중요하다는 것을 다시금 깨달았습니다. 기초가 튼튼한 개발자가 되고 싶습니다.
출처
'Web' 카테고리의 다른 글
[Web] Proxy를 알아보자 (0) | 2022.06.12 |
---|---|
[Web] Web Server와 WAS (0) | 2022.06.12 |
[Web] 안전하게 로그인 처리하기 (0) | 2022.02.04 |
[Web] JWT 토큰을 알아보자 (0) | 2022.01.14 |
[Web] 다중 서버에서 세션을 관리해보자 - 4 (feat Redis, Memcached) (0) | 2022.01.11 |