베어러 토큰이란 무엇인가요?
베어러 토큰이 무엇인지, OAuth 2.0 및 JWT에서 어떻게 동작하는지, 액세스 토큰과의 차이점, 그리고 모범 사례에 대해 알아보세요.
베어러 토큰이 무엇인지, OAuth 2.0 및 JWT에서 어떻게 동작하는지, 액세스 토큰과의 차이점, 그리고 모범 사례에 대해 알아보세요.
거의 모든 현대 앱의 로그인이나 API 요청 뒤에는 조용한 일꾼, 바로 베어러 토큰이 있습니다. 우리는 이를 자주 인식하지 못하지만, 서비스를 연결하거나, 로그인하거나, 클라우드에서 데이터를 불러올 때마다 항상 함께합니다.
이 가이드는 베어러 토큰이 무엇을 하는지, 왜 중요한지, 그리고 어떻게 안전하게 다루는지 설명합니다.
베어러 토큰은 리소스에 접근할 수 있다는 것을 증명하는 데이터 조각으로, 보통 문자열 형태입니다. 중요한 점은 이 토큰을 소지한 사람이라면, 추가적인 증명 없이도 사용할 수 있다는 것입니다.
비행기 탑승권을 떠올려 보세요. 탑승권을 손에 쥐고 있으면, 보안을 통과하고 비행기에 탈 수 있습니다. 탑승권이 유효하다면, 더 이상 신분증을 보여줄 필요가 없습니다. 베어러 토큰도 마찬가지로, 앱이 매번 신원을 다시 확인받지 않고도 "API에 탑승"할 수 있도록 해줍니다.
예시로, 휴대폰에서 Spotify에 로그인한 후에는 노래를 재생할 때마다 비밀번호를 입력할 필요가 없습니다. 대신, 앱은 베어러 토큰을 저장해 두고 Spotify 서버에 "이 요청은 인증된 사용자로부터 왔다"고 알립니다.
베어러 토큰의 흐름은 몇 단계로 나뉩니다:
사용자 로그인
예를 들어, 뱅킹 앱에 사용자 이름과 비밀번호로 로그인합니다.
아이덴티티 제공자가 토큰 발급
인증 서버가 정보를 확인한 후, 베어러 토큰을 반환합니다. 예시는 다음과 같을 수 있습니다:
클라이언트가 토큰 사용
"잔액 확인"이나 "송금" 버튼을 누를 때마다 앱은 HTTP 요청에 토큰을 포함합니다:
API 검증
서버는 토큰이 아직 유효한지, 만료되지 않았는지, 올바른 권한(예: read:balance, write:transfer)을 포함하는지 확인합니다.
접근 허용
모든 체크를 통과하면 서버가 요청한 정보를 반환합니다.
이 모델은 개발자가 매번 자격 증명을 입력하지 않고 베어러 토큰으로 인증하는 GitHub API 등 다양한 서비스에서 널리 사용되고 있습니다.
베어러 토큰은 웹 보안의 일반적인 문제를 해결해 주었기 때문에 널리 사용됩니다. 서버 기반 세션과 달리, 각 로그인 사용자마다 데이터를 저장할 필요가 없습니다. 대신, 토큰 자체에 서버가 요청을 검증하는 데 필요한 정보가 들어 있습니다.
예를 들어, 마이크로서비스 아키텍처에서는 여러 서비스가 서로 통신합니다. 중앙에서 세션을 유지하는 것은 복잡하고 비효율적입니다. 베어러 토큰을 사용하면 각 서비스가 독립적으로 요청을 검증해 시스템이 가볍고 확장성 있게 유지됩니다.
예시로, Slack의 API는 베어러 토큰에 크게 의존합니다. Slack 봇을 만들 때, 여러분은 봇이 모든 엔드포인트에 세션 없이 호출할 수 있는 토큰을 받게 됩니다.
많은 베어러 토큰은 JWT (JSON Web Tokens)로 구현됩니다. JWT는 사용자 정보와 권한 정보가 포함된 인코딩된 문자열입니다.
샘플 JWT를 해석해봅시다:
각 항목의 의미는 다음과 같습니다:
sub: 사용자 고유 ID(주체)name: 사용자의 이름iat: 발급된 시각exp: 만료 시각(토큰이 만료되는 시간)scope: 권한, 여기서는 메시지 읽기 및 쓰기실제 사용에서 Jane의 토큰이 read:messages만 있다면, 앱은 메시지 읽기만 가능하고 새 메시지를 보낼 수 없습니다.
베어러 토큰과 **액세스 토큰**을 혼동하기 쉽습니다. 두 용어가 종종 함께 나타나기 때문인데, 둘은 관련 있으나 동일하지 않습니다.
액세스 토큰은 사용자가 리소스에 접근할 수 있도록 허가하는 자격 증명입니다. 다음과 같은 정보를 담고 있습니다:
학교에서 교장 선생님이 서명한 허가증과 같은 역할입니다. 이 허가증을 통해 선생님(API)은 여러분이 소풍(리소스 접근)에 갈 수 있음을 확인합니다.
예로, 클라우드 저장소 서비스에 로그인하면 시스템에서 read:files 스코프가 있는 액세스 토큰을 발급합니다. 이 토큰을 통해 API는 "이 사용자가 파일을 읽을 수 있지만, 삭제할 수는 없다"라고 판단합니다.
베어러 토큰은 액세스 토큰의 한 종류입니다. 베어러라는 단어는 토큰이 어떻게 사용되는지를 설명하며, 토큰을 소지한 자가 별도의 추가 신원 확인 없이 리소스에 접근할 수 있습니다.
정리하면:
또 다른 토큰 유형으로는 holder-of-key 토큰이 있는데, 이는 토큰 외에 암호화 키를 소유하고 있음을 증명해야 합니다. 베어러 토큰은 그 과정을 생략하여 간단하지만, 도난 시 더 위험할 수 있습니다.
<token> 헤더로 사용하는 액세스 토큰을 반환합니다.따라서 OAuth 관련 튜토리얼에서 "액세스 토큰"이 나오면, 별도 언급이 없다면 거의 항상 베어러 토큰을 의미합니다.
차이를 더 명확히 하기 위해, 베어러 토큰이 다른 일반적 토큰 유형과 어떻게 다른지 살펴봅시다:
베어러 토큰과 액세스 토큰은 대립 관계가 아니라 연결된 개념입니다:
베어러 토큰 검증은 API와 비허가 접근을 구분하는 중요한 관문입니다. 토큰이 JWT라면, 검증은 로컬에서 빠르고 효율적으로 이루어집니다. API가 매번 발급처에 질의하지 않아도 토큰을 확인할 수 있습니다.
API 게이트웨이나 미들웨어에 적용할 때 아래 내용을 점검하세요.
서명(Signature)
헤더에 명시된 알고리즘(예: RS256)으로 서명을 검증합니다. 발급자의 JWKS 엔드포인트에서 kid에 맞는 키를 가져와 캐싱하세요.
발급자(iss)
토큰의 iss가 신뢰할 수 있는 발급자 URL과 정확히 일치하는지(프로토콜 포함) 확인합니다.
수신인(aud)
토큰이 내 API용으로 발급된 것인지 확인합니다. 예를 들어 https://api.example.com 또는 로직상 audience 값과 비교하세요.
만료(exp) & 유효 시작(nbf)
만료된 토큰을 거부합니다. nbf를 존중해, 시작 전에는 토큰을 사용할 수 없도록 합니다. 보통 30~60초 정도의 클록 오차를 허용합니다.
발급 시각(iat)
디버깅이나, 엄격한 환경에서 지나치게 오래된 토큰을 거부할 때 사용됩니다.
토큰 종류
반드시 액세스 토큰이어야 합니다. 일부 제공자는 typ: "at+jwt" 등으로 명시합니다. API 접근에 ID 토큰을 허용하지 마세요.
스코프/권한
스코프 혹은 제공자별 claim(permissions, roles 등)을 확인하고, 모든 엔드포인트에서 최소 권한 원칙을 적용하세요.
주체(sub)
안정적인 사용자 또는 클라이언트 ID입니다. 리소스 연결 및 감사에 활용하세요.
재생(replay) 및 취소(선택적이지만 권장)
민감 엔드포인트의 경우, jti 값 짧은 denylist 체크/활성 세션 기록 확인을 고려하세요. 로그아웃이나 침해 의심 시 유용합니다.
베어러 토큰은 "누구든 이를 가진 자가 쓸 수 있다"는 특성이 강하므로 집 열쇠처럼 조심해야 합니다. 누가 내 열쇠를 훔치면, 자물쇠를 바꿀 때까지 내 집을 마음대로 드나들 수 있습니다.
흔한 위험으로는 다음과 같은 것이 있습니다:
실제로 개발자가 베어러 토큰을 실수로 공개 GitHub 저장소에 커밋해 유출된 사고도 있습니다. 공격자는 자동화된 스캔으로 이런 토큰을 찾아 즉시 권한 없는 접근을 시도할 수 있습니다.
베어러 토큰을 안전하게 사용하려면 아래와 같은 모범 사례를 따라야 합니다. 예제와 함께 살펴봅시다.
항상 HTTPS 사용
토큰을 공공 와이파이에서 평문 HTTP로 전송한다고 상상해 보세요. 네트워크 패킷을 엿보는 누구라도 토큰을 복사해 여러분인 척 로그인할 수 있습니다.
단명 액세스 토큰 사용
대부분의 플랫폼은 1시간 이내 만료되는 토큰을 발급합니다. 예를 들어, Google OAuth 토큰은 1시간 후 새로고침이 필요합니다.
리프레시 토큰 신중 관리
리프레시 토큰은 사용자가 다시 로그인하지 않고도 새 액세스 토큰을 받을 때 사용됩니다. 하지만 보안 저장소(예: 서버의 암호화 DB)에 보관하고, 클라이언트 측 저장소는 피해야 합니다.
최소 권한 스코프 사용
앱이 사용자의 캘린더 읽기만 필요하다면 write:calendar 권한까지 요청하지 마세요. 토큰 유출 시 피해를 최소화합니다.
필요 시 토큰 즉시 폐기
많은 SaaS 앱은 사용자에게 현재 활성 세션을 보여주고 취소할 수 있게 합니다. GitHub도 언제든지 개인 액세스 토큰을 즉시 취소할 수 있습니다.
사용 모니터링
토큰 사용 로그는 이상 활동을 파악하는 데에 도움이 됩니다. 예를 들어, 같은 토큰이 몇 분 차이로 런던과 뉴욕에서 사용된다면 의심 신호입니다.
베어러 토큰을 다른 인증 방식들과 비교해 보면 유용합니다:
쿠키 & 세션
전통적인 웹사이트는 서버에 저장된 세션을 쿠키로 식별합니다. 브라우저 앱이라면 잘 맞지만, API나 모바일 앱에는 비효율적일 수 있습니다. 예를 들어, 데스크톱 Facebook 로그인은 주로 쿠키를 사용하지만, 모바일 API는 토큰을 활용합니다.
API 키
API 키는 애플리케이션을 인증하는 정적인 문자열입니다. 예를 들어, 날씨 앱은 API 키로 데이터를 불러오지만, 이 키만으로는 요청한 사용자를 알 수 없습니다. 베어러 토큰은 사용자 정보도 담을 수 있어 더 유연합니다.
Mutual TLS (mTLS)
보안이 매우 중요한 시스템에서 클라이언트와 서버 모두 인증서를 사용합니다. 매우 안전하지만, 대규모 배포는 어렵습니다. 대부분의 SaaS 플랫폼에서 베어러 토큰은 사용성과 보안의 균형을 잘 맞춥니다.