베어러 토큰이란 무엇인가요?

거의 모든 현대 앱의 로그인이나 API 요청 뒤에는 조용한 일꾼, 바로 베어러 토큰이 있습니다. 우리는 이를 자주 인식하지 못하지만, 서비스를 연결하거나, 로그인하거나, 클라우드에서 데이터를 불러올 때마다 항상 함께합니다.

이 가이드는 베어러 토큰이 무엇을 하는지, 왜 중요한지, 그리고 어떻게 안전하게 다루는지 설명합니다.

베어러 토큰이란?#

베어러 토큰은 리소스에 접근할 수 있다는 것을 증명하는 데이터 조각으로, 보통 문자열 형태입니다. 중요한 점은 이 토큰을 소지한 사람이라면, 추가적인 증명 없이도 사용할 수 있다는 것입니다.

비행기 탑승권을 떠올려 보세요. 탑승권을 손에 쥐고 있으면, 보안을 통과하고 비행기에 탈 수 있습니다. 탑승권이 유효하다면, 더 이상 신분증을 보여줄 필요가 없습니다. 베어러 토큰도 마찬가지로, 앱이 매번 신원을 다시 확인받지 않고도 "API에 탑승"할 수 있도록 해줍니다.

예시로, 휴대폰에서 Spotify에 로그인한 후에는 노래를 재생할 때마다 비밀번호를 입력할 필요가 없습니다. 대신, 앱은 베어러 토큰을 저장해 두고 Spotify 서버에 "이 요청은 인증된 사용자로부터 왔다"고 알립니다.

베어러 토큰의 실제 동작 방식#

베어러 토큰의 흐름은 몇 단계로 나뉩니다:

1. 사용자 로그인

   예를 들어, 뱅킹 앱에 사용자 이름과 비밀번호로 로그인합니다.

2. 아이덴티티 제공자가 토큰 발급

   인증 서버가 정보를 확인한 후, 베어러 토큰을 반환합니다. 예시는 다음과 같을 수 있습니다:

3. 클라이언트가 토큰 사용

   "잔액 확인"이나 "송금" 버튼을 누를 때마다 앱은 HTTP 요청에 토큰을 포함합니다:

4. API 검증

   서버는 토큰이 아직 유효한지, 만료되지 않았는지, 올바른 권한(예: read:balance, write:transfer)을 포함하는지 확인합니다.

5. 접근 허용

   모든 체크를 통과하면 서버가 요청한 정보를 반환합니다.

이 모델은 개발자가 매번 자격 증명을 입력하지 않고 베어러 토큰으로 인증하는 GitHub API 등 다양한 서비스에서 널리 사용되고 있습니다.

베어러 토큰이 인기있어진 이유#

베어러 토큰은 웹 보안의 일반적인 문제를 해결해 주었기 때문에 널리 사용됩니다. 서버 기반 세션과 달리, 각 로그인 사용자마다 데이터를 저장할 필요가 없습니다. 대신, 토큰 자체에 서버가 요청을 검증하는 데 필요한 정보가 들어 있습니다.

예를 들어, 마이크로서비스 아키텍처에서는 여러 서비스가 서로 통신합니다. 중앙에서 세션을 유지하는 것은 복잡하고 비효율적입니다. 베어러 토큰을 사용하면 각 서비스가 독립적으로 요청을 검증해 시스템이 가볍고 확장성 있게 유지됩니다.

예시로, Slack의 API는 베어러 토큰에 크게 의존합니다. Slack 봇을 만들 때, 여러분은 봇이 모든 엔드포인트에 세션 없이 호출할 수 있는 토큰을 받게 됩니다.

베어러 토큰 내부에는 무엇이 들어있는가?#

많은 베어러 토큰은 JWT (JSON Web Tokens)로 구현됩니다. JWT는 사용자 정보와 권한 정보가 포함된 인코딩된 문자열입니다.

샘플 JWT를 해석해봅시다:

각 항목의 의미는 다음과 같습니다:

• sub: 사용자 고유 ID(주체)
• name: 사용자의 이름
• iat: 발급된 시각
• exp: 만료 시각(토큰이 만료되는 시간)
• scope: 권한, 여기서는 메시지 읽기 및 쓰기

실제 사용에서 Jane의 토큰이 read:messages만 있다면, 앱은 메시지 읽기만 가능하고 새 메시지를 보낼 수 없습니다.

베어러 토큰 vs. 액세스 토큰: 차이점은?#

베어러 토큰과 **액세스 토큰**을 혼동하기 쉽습니다. 두 용어가 종종 함께 나타나기 때문인데, 둘은 관련 있으나 동일하지 않습니다.

액세스 토큰: "허가증"#

액세스 토큰은 사용자가 리소스에 접근할 수 있도록 허가하는 자격 증명입니다. 다음과 같은 정보를 담고 있습니다:

• 사용자(그들의 ID)
• 허용된 작업(스코프/권한)
• 토큰 만료 시각

학교에서 교장 선생님이 서명한 허가증과 같은 역할입니다. 이 허가증을 통해 선생님(API)은 여러분이 소풍(리소스 접근)에 갈 수 있음을 확인합니다.

예로, 클라우드 저장소 서비스에 로그인하면 시스템에서 read:files 스코프가 있는 액세스 토큰을 발급합니다. 이 토큰을 통해 API는 "이 사용자가 파일을 읽을 수 있지만, 삭제할 수는 없다"라고 판단합니다.

베어러 토큰: "전달 형식"#

베어러 토큰은 액세스 토큰의 한 종류입니다. 베어러라는 단어는 토큰이 어떻게 사용되는지를 설명하며, 토큰을 소지한 자가 별도의 추가 신원 확인 없이 리소스에 접근할 수 있습니다.

정리하면:

• 모든 베어러 토큰은 액세스 토큰입니다.
• 하지만 모든 액세스 토큰이 반드시 베어러 토큰일 필요는 없습니다.

또 다른 토큰 유형으로는 holder-of-key 토큰이 있는데, 이는 토큰 외에 암호화 키를 소유하고 있음을 증명해야 합니다. 베어러 토큰은 그 과정을 생략하여 간단하지만, 도난 시 더 위험할 수 있습니다.

실제 예시#

• 액세스 토큰(일반적): 암호화된 데이터로, 때로는 클라이언트가 개인 키도 함께 소유하고 있음을 증명해야 할 수 있습니다.
• 베어러 토큰(특정): 대부분의 OAuth 2.0 구현에서는 액세스 토큰이 베어러 포맷으로 발급됩니다. 예를 들어, Google OAuth는 Authorization: Bearer <token> 헤더로 사용하는 액세스 토큰을 반환합니다.

따라서 OAuth 관련 튜토리얼에서 "액세스 토큰"이 나오면, 별도 언급이 없다면 거의 항상 베어러 토큰을 의미합니다.

다른 토큰 유형과 비교#

차이를 더 명확히 하기 위해, 베어러 토큰이 다른 일반적 토큰 유형과 어떻게 다른지 살펴봅시다:

• 리프레시 토큰: 기존 액세스 토큰이 만료됐을 때 새 액세스 토큰을 받는 데 사용됩니다. 리프레시 토큰은 일반적으로 베어러 토큰이 아닙니다, 왜냐하면 직접 API에 전달되지 않고 인증 서버와 안전하게 교환되기 때문입니다.
• ID 토큰: 인가가 아닌 인증 용도로 사용합니다. 이메일, 이름, 사용자 ID 등 사용자 신원 정보를 담고 있습니다. 시스템에 따라 ID 토큰도 베어러 토큰이 될 수 있지만, 목적이 액세스 토큰과 다릅니다.
• API 키: 호출하는 애플리케이션을 식별하는 간단한 자격 증명입니다. 많은 경우 API 키도 베어러 토큰처럼 동작합니다. 키를 가진 자가 API를 호출할 수 있기 때문입니다.

베어러 토큰과 액세스 토큰은 대립 관계가 아니라 연결된 개념입니다:

• 대부분의 액세스 토큰은 베어러 토큰입니다.
• 베어러 토큰은 토큰의 사용 방식(제시하면 접근이 허용됨)을 의미합니다.
• 실무에서는 "액세스 토큰"과 "베어러 토큰" 용어가 혼용되지만, 엄밀히 다루면 강조 지점이 다릅니다.

JWT 액세스 토큰(베어러 토큰) 검증 방법#

베어러 토큰 검증은 API와 비허가 접근을 구분하는 중요한 관문입니다. 토큰이 JWT라면, 검증은 로컬에서 빠르고 효율적으로 이루어집니다. API가 매번 발급처에 질의하지 않아도 토큰을 확인할 수 있습니다.

핵심 아이디어#

1. 토큰을 파싱합니다.
2. 발급자의 공개키로 서명을 검증합니다.
3. 표준 claims(issuer, audience, 만료, not-before 등)를 검사합니다.
4. 앱의 규칙(스코프, 역할, 토큰 타입 등)을 적용합니다.
5. 민감한 행동에 대해서는 필요에 따라 토큰 취소 목록이나 세션 상태도 확인합니다.

검증 체크리스트(JWT)#

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 체크/활성 세션 기록 확인을 고려하세요. 로그아웃이나 침해 의심 시 유용합니다.

베어러 토큰의 보안 위험#

베어러 토큰은 "누구든 이를 가진 자가 쓸 수 있다"는 특성이 강하므로 집 열쇠처럼 조심해야 합니다. 누가 내 열쇠를 훔치면, 자물쇠를 바꿀 때까지 내 집을 마음대로 드나들 수 있습니다.

흔한 위험으로는 다음과 같은 것이 있습니다:

• 토큰 도난 – 해커가 브라우저의 localStorage에서 토큰을 훔칠 경우, 사용자를 위장할 수 있습니다. 2018년에는 일부 브라우저 확장 프로그램이 localStorage의 토큰을 훔쳐 판매하다 적발된 적도 있습니다.
• 재생 공격 – 공격자가 토큰을 가로채서, 만료될 때까지 재사용할 수 있습니다. HTTPS가 없으면 생각보다 쉽게 가능합니다.
• 장기 토큰 – 토큰이 수주~수개월 동안 유효하면, 공격자에게 노출되는 시간이 길어집니다.

실제로 개발자가 베어러 토큰을 실수로 공개 GitHub 저장소에 커밋해 유출된 사고도 있습니다. 공격자는 자동화된 스캔으로 이런 토큰을 찾아 즉시 권한 없는 접근을 시도할 수 있습니다.

베어러 토큰 사용 모범 사례#

베어러 토큰을 안전하게 사용하려면 아래와 같은 모범 사례를 따라야 합니다. 예제와 함께 살펴봅시다.

1. 항상 HTTPS 사용

   토큰을 공공 와이파이에서 평문 HTTP로 전송한다고 상상해 보세요. 네트워크 패킷을 엿보는 누구라도 토큰을 복사해 여러분인 척 로그인할 수 있습니다.

2. 단명 액세스 토큰 사용

   대부분의 플랫폼은 1시간 이내 만료되는 토큰을 발급합니다. 예를 들어, Google OAuth 토큰은 1시간 후 새로고침이 필요합니다.

3. 리프레시 토큰 신중 관리

   리프레시 토큰은 사용자가 다시 로그인하지 않고도 새 액세스 토큰을 받을 때 사용됩니다. 하지만 보안 저장소(예: 서버의 암호화 DB)에 보관하고, 클라이언트 측 저장소는 피해야 합니다.

4. 최소 권한 스코프 사용

   앱이 사용자의 캘린더 읽기만 필요하다면 write:calendar 권한까지 요청하지 마세요. 토큰 유출 시 피해를 최소화합니다.

5. 필요 시 토큰 즉시 폐기

   많은 SaaS 앱은 사용자에게 현재 활성 세션을 보여주고 취소할 수 있게 합니다. GitHub도 언제든지 개인 액세스 토큰을 즉시 취소할 수 있습니다.

6. 사용 모니터링

   토큰 사용 로그는 이상 활동을 파악하는 데에 도움이 됩니다. 예를 들어, 같은 토큰이 몇 분 차이로 런던과 뉴욕에서 사용된다면 의심 신호입니다.

베어러 토큰과 다른 인증 방식 비교#

베어러 토큰을 다른 인증 방식들과 비교해 보면 유용합니다:

• 쿠키 & 세션

  전통적인 웹사이트는 서버에 저장된 세션을 쿠키로 식별합니다. 브라우저 앱이라면 잘 맞지만, API나 모바일 앱에는 비효율적일 수 있습니다. 예를 들어, 데스크톱 Facebook 로그인은 주로 쿠키를 사용하지만, 모바일 API는 토큰을 활용합니다.

• API 키

  API 키는 애플리케이션을 인증하는 정적인 문자열입니다. 예를 들어, 날씨 앱은 API 키로 데이터를 불러오지만, 이 키만으로는 요청한 사용자를 알 수 없습니다. 베어러 토큰은 사용자 정보도 담을 수 있어 더 유연합니다.

• Mutual TLS (mTLS)

  보안이 매우 중요한 시스템에서 클라이언트와 서버 모두 인증서를 사용합니다. 매우 안전하지만, 대규모 배포는 어렵습니다. 대부분의 SaaS 플랫폼에서 베어러 토큰은 사용성과 보안의 균형을 잘 맞춥니다.

주요 요점#

• 베어러 토큰은 단순하지만 강력합니다: 토큰을 가진 자가 리소스 접근 권한을 갖습니다.
• OAuth 2.0과 OIDC에서, 특히 API와 모바일 앱에서 널리 사용됩니다.
• 보안은 관리 방식에 달려 있습니다. 토큰의 짧은 수명, 스코프, HTTPS, 폐기 관리가 중요합니다.
• 언제나 최선의 선택은 아니지만, 대부분의 SaaS와 API 상황에서는 편의성과 보안의 균형을 제공합니다.