왜 Authorization "Bearer"인가요?
XHR 요청의 Authorization 헤더에 Bearer 토큰을 넣으려고 액세스 토큰과 리프레시 토큰을
localStorage에 저장한 코드를 본 적이 있습니다.스크립트가 토큰에 접근하지 못하도록 바꾸고 원격 프록시가 Authorization 헤더를 붙이게 하던 중 이름이 눈에 들어왔습니다.
왜 Authorization 헤더는 'Bearer'일까?
이 글에서 다루는 내용
Authorization 헤더에서 Bearer가 뜻하는 바를 HTTP와 OAuth 표준을 따라 확인합니다. Bearer라는 전달 방식과 JWT라는 토큰 형식을 구분하고, 토큰을 탈취당했을 때의 위험과 보완 수단도 정리합니다.
- 서론: Authorization Bearer 토큰이란 무엇인가?
- 역사적 배경: Authorization 헤더와 Bearer 스킴의 등장
- Bearer 토큰이 표준으로 자리 잡은 이유
- Bearer 토큰의 한계와 보완책
- 실무에서의 Bearer 토큰 사용 사례
- References
서론: Authorization Bearer 토큰이란 무엇인가?
클라이언트는 API 요청의 Authorization 헤더에 Bearer 액세스 토큰을 넣어 권한을 제시할 수 있습니다. 이 토큰이 사용자의 로그인 상태를 나타내는지는 발급 목적과 시스템 설계에 달려 있습니다.
Authorization 헤더의 역할
Authorization 헤더는 클라이언트가 서버에 자격 증명을 전달하는 표준 수단입니다. 헤더가 있다는 사실만으로 인가가 끝난 것은 아니며, 서버가 그 자격 증명과 요청 권한을 검사해야 합니다. 일반적인 형태는 다음과 같습니다.
Authorization: <스킴> <자격 증명>
여기서 <스킴>은 인증 방식(예: Basic, Bearer)을 나타내고, <자격 증명>에는 클라이언트의 인증 정보가 들어갑니다. Bearer는 이러한 인증 방식 중 하나로, OAuth 2.0에서 널리 사용되는 스킴입니다.
Bearer 토큰이란?
Bearer 토큰은 클라이언트가 특정 리소스에 접근할 권한을 서버에 제시하는 자격 증명입니다. 네트워크에서 토큰이 노출되지 않도록 HTTPS로 전송해야 합니다.
Authorization: Bearer <토큰>
JWT(JSON Web Token)의 정의와 Bearer 토큰과의 관계
JWT는 Bearer 토큰에서 자주 사용되는 토큰 포맷 중 하나입니다. 흔히 사용하는 서명된 JWT의 Compact JWS 표현은 다음 세 부분으로 구성됩니다. 암호화된 JWT(JWE)는 구조가 다르며, Bearer 토큰이 반드시 JWT여야 하는 것도 아닙니다.
- Header: 토큰의 타입과 서명 알고리즘 정보를 포함합니다.
- Payload: 사용자 정보와 클레임(Claims, 권한 정보 등)을 담습니다.
- Signature: 토큰의 무결성을 보장하기 위한 서명입니다.
서명된 JWT를 Bearer 토큰으로 쓰면 서버가 토큰 자체의 서명과 클레임을 검사할 수 있습니다. 그렇다고 모든 Bearer 토큰이 JWT인 것도, JWT를 쓰면 서버 상태가 전혀 필요 없는 것도 아닙니다. 토큰 폐기와 세션 정책에는 별도 상태가 필요할 수 있습니다.
정리
Bearer는 토큰을 전달하는 인증 스킴이고 JWT는 토큰에 쓸 수 있는 형식입니다. 서버는 전달받은 토큰의 유효성과 권한을 별도로 검사합니다.
역사적 배경: Authorization 헤더와 Bearer 스킴의 등장
Authorization 헤더와 Bearer 스킴이 어떻게 표준화되었는지 HTTP와 OAuth 2.0의 RFC를 따라 살펴봅니다.
HTTP 표준과 Authorization 헤더의 시작
Authorization 헤더는 클라이언트가 서버에 인증 정보를 전달하기 위한 표준화된 방법으로, HTTP/1.0을 정의한 RFC 1945(1996)에서 처음 정의되었습니다.
HTTP/1.1 RFC 2616
RFC 2616은 HTTP/1.1에서 Authorization 헤더를 정의하며, 클라이언트가 서버에 자격 증명을 제공할 수 있는 메커니즘을 명확히 했습니다. 인증 스킴 자체는 별도의 문서로 발전해 왔는데, Basic은 HTTP/1.0을 정의한 RFC 1945(1996)에서, Digest는 RFC 2069(1997)에서 등장했고, HTTP/1.1 시대에는 동반 문서인 RFC 2617(1999)이 아래 두 가지 스킴을 정의했습니다. 참고로 RFC 2616은 이후 개정을 거쳐 폐기되었고, Authorization 헤더의 현행 정의는 RFC 9110 §11.6.2에 있습니다.
RFC 2616에 명시된 Authorization 헤더
- Basic Authentication은 사용자 이름과 비밀번호를 Base64로 인코딩해 전송합니다. Base64는 암호화가 아니므로 반드시 HTTPS와 함께 사용해야 합니다.
GET /protected-resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
# dXNlcm5hbWU6cGFzc3dvcmQ=는 Base64로 인코딩된 username:password입니다.
- Digest Authentication은 서버가 보낸 challenge와 비밀번호 등으로 계산한 해시 응답을 전송합니다.
Basic은 사용자 이름과 비밀번호를 인코딩해 보내고, Digest는 비밀번호 자체 대신 challenge에 대한 해시 응답을 보냅니다. 두 방식 모두 제3자에게 범위와 수명을 제한한 API 권한을 위임하는 프레임워크는 아닙니다.
OAuth 2.0의 등장 (RFC 6749, 2012)
OAuth 2.0은 클라이언트가 리소스 소유자를 대신해 서버에 접근할 권한을 위임하는 프레임워크입니다. 클라이언트는 사용자의 비밀번호를 Resource Server에 반복해서 보내는 대신 액세스 토큰으로 위임받은 권한을 제시합니다.
이 과정에서 Authorization 헤더가 액세스 토큰의 전달 수단으로 채택됐고, Bearer 스킴이 OAuth 2.0의 표준 토큰 전달 방식이 됐습니다. OAuth 2.0은 인가 프레임워크이며 사용자 인증(authentication)은 OAuth 2.0을 기반으로 만든 OpenID Connect가 담당합니다.
“Bearer”라는 단어의 기원
Bearer 스킴은 RFC 6750(2012)에 정의돼 있으며 OAuth 2.0 액세스 토큰을 전달하는 데 쓰입니다.
RFC 6750에 등장하는 "Bearer"
RFC 6750의 정의와 역할
RFC 6750은 Bearer 토큰의 전달 방법과 오류 응답을 규정합니다.
- Bearer 토큰은 요청의 Authorization 헤더에 포함됩니다.
- 요청자는 토큰과 연결된 별도 암호 키의 소유를 증명하지 않습니다. 서버는 여전히 토큰의 유효성과 허용 범위를 검증해야 합니다.
Authorization: Bearer <토큰>
“Bearer”라는 이름의 뜻
“Bearer”는 소지자를 뜻합니다. 유효한 토큰을 가진 쪽이 그 토큰의 권한을 행사하며, 요청자는 토큰과 연결된 별도 키를 가졌다고 증명하지 않습니다.
이러한 설계는 요청자가 토큰을 제시하는 절차를 단순하게 만듭니다. 토큰 검증에 서버 상태가 필요한지는 별개의 선택입니다.
Recap
Authorization 헤더는 여러 인증 스킴을 실어 나릅니다. 그중 Bearer는 유효한 토큰의 소지자가 별도의 키 소유 증명 없이 권한을 행사한다는 성질을 이름에 담았습니다.
Bearer 토큰이 표준으로 자리 잡은 이유
Bearer 스킴은 토큰 형식과 발급 절차를 강제하지 않으면서 HTTP 요청에 자격 증명을 싣는 일관된 방법을 제공합니다. OAuth 2.0을 지원하는 클라이언트와 API가 같은 규칙으로 연동할 수 있다는 점이 널리 쓰이는 이유입니다.
보안 측면
Basic, 쿠키, Bearer를 비교할 때는 자격 증명의 전달 방식과 서버의 상태 관리 방식을 나누어 봐야 합니다.
- Basic Auth는 사용자 자격 증명을 Base64 인코딩만 거쳐 전송하는데, Base64는 인코딩일 뿐 암호화가 아니어서 사실상 평문 노출이나 다름없습니다.
GET /resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
- 쿠키는 자격 증명을 보관·전송하는 수단입니다. 서버 세션 ID를 담을 수도 있고 서명된 토큰을 담을 수도 있으므로 쿠키 자체가 서버 상태 저장을 요구하지는 않습니다.
GET /resource HTTP/1.1
Host: example.com
Cookie: session_id=abc123
Bearer도 무상태 검증을 보장하지 않습니다. 불투명 토큰은 서버 조회가 필요할 수 있고, JWT는 로컬 검증이 가능하지만 즉시 폐기에는 별도 상태가 필요할 수 있습니다. HTTPS는 Bearer뿐 아니라 Basic과 쿠키를 전송할 때도 필요합니다.
GET /resource HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
HTTPS는 전송 구간에서 토큰이 그대로 노출되는 일을 막습니다. 애플리케이션 로그나 브라우저 저장소에서의 유출까지 막아 주지는 않습니다.
| 인증 방식 | 주요 특징 | 보안 위험 | 개선 사항 |
|---|---|---|---|
| Basic Auth | 사용자 인증 정보를 Base64로 인코딩하여 전송 | 평문 전송으로 HTTPS 없이는 매우 취약 | HTTPS 사용 필수 |
| Cookie-based Auth | 쿠키로 세션 ID 또는 토큰 전송 | 세션 탈취, XSS 공격에 취약 | SameSite 쿠키, HttpOnly 쿠키 사용 |
| Bearer Token | 토큰 제시로 권한 행사, 상태 관리 여부는 별개 | 탈취된 토큰 악용 가능 | HTTPS 사용, 짧은 만료 시간, Scope 제한 |
요청 형식의 단순함
- 클라이언트는 요청 시 Authorization 헤더에 토큰만 추가하면 되므로 추가적인 인증 절차가 필요 없습니다.
- 서명된 JWT를 사용하면 요청마다 세션 저장소를 조회하지 않는 검증 구조를 선택할 수 있습니다. Bearer 스킴이 요구하는 조건은 아닙니다.
표준화와 상호운용성
OAuth 2.0을 따르는 구현은 다음 규칙을 공유할 수 있습니다.
- 다양한 플랫폼에서 같은 Authorization 헤더 형식을 사용할 수 있습니다.
- 토큰 형식은 JWT나 불투명 문자열 중 시스템 요구에 맞게 선택할 수 있습니다.
- API마다 별도의 자격 증명 전달 규칙을 만들 필요가 줄어듭니다.
Recap
Bearer 스킴은 토큰 전달 규칙을 표준화합니다. HTTPS와 만료·권한 제한·안전한 보관은 그 토큰을 안전하게 다루기 위한 별도 조건입니다.
Bearer 토큰의 한계와 보완책
Bearer 토큰은 소지 자체로 권한을 행사하므로 유출된 뒤의 악용을 막아 줄 별도 키 증명이 없습니다.
보안 취약점
Bearer 토큰의 가장 큰 약점은 토큰 자체가 인증 자격 증명이라는 점입니다.
- 토큰 탈취: 서버는 Bearer 토큰의 소지자를 권한이 있는 주체로 간주하므로, 공격자가 탈취한 토큰을 그대로 재사용할 수 있습니다.
- 네트워크 노출: HTTPS를 사용하지 않으면 전송 중 토큰이 노출될 수 있습니다.
보완 방법
다음 방법으로 토큰이 노출될 가능성과 노출 뒤의 피해 범위를 줄입니다.
- HTTPS 사용: 모든 통신에서 HTTPS를 강제하여 토큰이 암호화된 채로 전송되도록 해야 합니다.
- 토큰 만료 시간 설정: 짧은 만료 시간을 가진 액세스 토큰과 함께, 만료된 토큰을 갱신할 수 있는 Refresh Token을 사용하는 방식이 일반적입니다.
- Scope와 Permission 제한: 토큰이 특정 리소스와 작업에만 접근하도록 제한(Scope 설정)하면, 토큰 탈취의 피해를 최소화할 수 있습니다.
대안 인증 방식
토큰을 별도 키나 TLS 연결에 묶는 방식도 검토할 수 있습니다.
- Proof-of-Possession (PoP) 토큰: Bearer 토큰과 달리 소지 여부만으로 인증하지 않고 요청에 서명해 토큰의 정당성을 추가로 검증합니다. 토큰에 연결된 개인 키까지 탈취되지 않았다면 토큰만 탈취해서는 사용할 수 없게 합니다. 대표적인 구체 표준으로는 DPoP(RFC 9449, 2023)가 있습니다.
- Mutually Authenticated TLS (MTLS): 클라이언트와 서버가 서로를 인증하는 TLS 인증 방식으로, 통신 양측의 신뢰성을 보장합니다. 이 방법은 높은 수준의 보안을 요구하는 환경에서 유용합니다.
WebAuthn은 사용자 인증에, Zero Trust는 접근을 지속적으로 검증하는 보안 모델에 관한 것입니다. 둘은 Bearer의 직접 대체 방식이 아니라 함께 적용할 수 있는 별도 계층입니다.
실무에서의 Bearer 토큰 사용 사례
Bearer 토큰은 모바일 앱과 브라우저 애플리케이션, 백엔드 서비스가 API를 호출할 때 쓰입니다.
RESTful API에서의 Authorization 헤더 사용
Bearer 토큰은 주로 API 요청의 Authorization 헤더에 포함되어 전달됩니다. 요청과 응답의 기본 구조는 다음과 같습니다.
요청 예제
GET /api/resource HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Authorization은 헤더 이름입니다.Bearer는 인증 스킴입니다.<토큰>자리에는 JWT 또는 다른 형식의 액세스 토큰이 들어갑니다.
응답 예제
HTTP/1.1 200 OK
Content-Type: application/json
{
"data": "protected resource"
}
API 서버는 토큰의 유효성을 검증한 뒤 요청된 리소스를 반환합니다.
다양한 플랫폼에서의 Bearer 토큰 활용
모바일 앱
- Bearer 토큰은 OAuth 2.0을 통해 발급되어 모바일 앱과 백엔드 서버 간 통신에서 사용됩니다.
- 예를 들어, 사용자가 로그인하면 OAuth 서버에서 액세스 토큰을 발급받아 이후 모든 API 요청에 포함시킵니다.
SPA(Single Page Application)
- SPA는 주로 브라우저에서 실행되며, 토큰을 클라이언트 메모리 등에 저장해 API 요청 시 사용합니다.
- 메모리 저장도 XSS로부터 안전한 저장소는 아닙니다. 토큰을 서버에 보관하는 BFF 구조에서는 브라우저에 HttpOnly 세션 쿠키만 보내고 BFF가 API 요청에 Bearer 토큰을 붙일 수 있습니다.
HTTP/1.1 200 OK
Set-Cookie: session_id=SESSION_ID; Path=/; HttpOnly; Secure; SameSite=Strict
Content-Type: application/json
{
"message": "Logged in successfully"
}
백엔드 간 통신
- 백엔드 서비스 간 통신에서도 Bearer 토큰을 사용합니다. 예를 들어 서비스 A가 서비스 B의 리소스에 접근할 때, 서비스 A에 발급된 액세스 토큰으로 권한을 제시할 수 있습니다.
OpenID Connect에서의 Bearer 토큰 역할
OpenID Connect는 OAuth 2.0을 기반으로 사용자 인증과 신원 정보를 다룹니다. 이 흐름에서 발급되는 토큰은 용도가 서로 다릅니다.
- Access Token: API에 접근 권한을 제시합니다. 반드시 사용자의 로그인 결과를 증명하는 것은 아닙니다.
- ID Token: 사용자의 ID 정보(예: 이메일, 이름)를 JSON Web Token 형식으로 포함해 클라이언트에 전달합니다.
- Refresh Token: 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용됩니다.
아래는 openid scope로 시작한 흐름의 코드 교환 예시입니다. client_secret은 서버에서만 보관하는 confidential client용이며 브라우저 코드에 넣으면 안 됩니다. ID 토큰과 리프레시 토큰은 Resource Server에 보내는 Bearer 액세스 토큰과 용도가 다릅니다.
토큰 요청
POST /token HTTP/1.1
Host: identity-provider.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=AUTH_CODE
&redirect_uri=https://client.example.com/callback
&client_id=CLIENT_ID
&client_secret=CLIENT_SECRET
&code_verifier=CODE_VERIFIER
토큰 응답
{
"access_token": "ACCESS_TOKEN",
"id_token": "ID_TOKEN",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "REFRESH_TOKEN"
}
Recap
플랫폼이 달라도 Authorization 헤더의 형식은 같습니다. 대신 발급 흐름과 저장 위치, 만료·회수 정책은 클라이언트 유형과 다루는 정보의 민감도에 맞춰 정해야 합니다.
References
JWT(JSON Web Token)
OAuth 2.0
OpenID Connect
HttpOnly 쿠키와 보안
General References
