본 글은 MDN - HTTP 인증, Veloport님의 게시글을 참고하여 작성되었습니다. 자세하게 알고싶으신 분은 해당 링크를 참고해주세요.

---

목차

• 토큰 기반 인증
• 인증 타입
• 마치며

토큰 기반 인증

토큰 기반 인증은 쿠키나 세션을 이용한 인증보다더 보안성이 강하고 효율적인 인증 방법입니다. 쿠키 인증은 쿠키에 아이디나 암호와 같은 사용자 정보를 담아 서버로 보내게 되는데, HTTP 방식의 통신을 사용할 경우 제 3자가 해당 정보를 염탐할 수 있습니다. 세션의 경우 세션ID를 보내므로 쿠키에 비해 보안성이 높다고 볼 수 있지만 서버에 추가적인 데이터베이스 공간이 필요하다는 단점이 있습니다.

이러한 단점들을 해결할 수 있는 방법이 바로 토큰 기반 인증입니다.
토큰에는 암호화 방식과 타입 등을 나타내는 헤더, 전송할 데이터가 담긴 페이로드, 토큰 검증을 위한 서명을 각각 인코딩(해싱)한 값이 포함되어 있습니다.

데이터가 인코딩이 되어있긴 하지만 누구나 디코딩을 할 수 있어서 데이터 유출에 대한 피해가 있을 수 있지만 서명 필드는 헤더와 페이로드를 통해 만들어지기 때문에 데이터 변조 후 재전송하는 것을 막을 수 있습니다.

그럼에도 불구하고 쿠키와 세션을 이용한 인증에 비해 장점이 많아 많은 서비스에서 이 인증 방식을 사용하고 있습니다.

장점

• 헤더와 페이로드를 가지고 서명 필드를 생성하므로 데이터 변조 후 재전송을 막을 수 있습니다.
• stateless 서버를 만들 수 있습니다.
• 모바일 어플리케이션에서도 잘 동작합니다.
• 인증정보를 다른 웹서비스에 전송할 수 있습니다. (OAuth)

단점

• 여전히 누구나 디코딩이 가능하므로 데이터 유출이 발생할 수 있습니다.
• 토큰을 탈취당할 경우, 대처하기 어렵다. (유효기간을 기다리거나 token refresh를 해야한다)
• JWT의 경우, 토큰의 길이가 길기 때문에 요청이 많아질수록 서버 자원의 낭비가 많아진다.

일반적으로 토큰은 요청 헤더의 Authorization 필드에 담아져 보내집니다.
Authorization: <type> <credentials>

우리가 궁금해하던 bearer는 위 형식에서 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를 타나내는 인증 타입입니다.

마치며

우리는 주로 JWT를 통해 토큰 기반 인증 시스템을 구축하기 때문에 bearer라는 키워드를 주로 사용해왔습니다. 별 의미가 없는 키워드로 치부될 수 있지만 서비스가 더 커질수록, 그리고 약속된 틀에서 벗어나지 않기 위해서는 키워드의 의미와 사용 방법에 대해 잘 알아야합니다. 간혹, bearer라는 키워드를 다른 단어로 치환하여 개발하는 경우가 있는데, 아주 좋지 않은 방식이고 약속된 틀을 잘 지키는 것이 중요합니다.