Skip to main content

왜 Authorization "Bearer"인가요?

멀지 않은 과거에 XHR 클라이언트 Authorization 헤더에 Bearer 토큰을 넣기 위해 클라이언트 스토리지(localStorage, et cetera...)에 스크립트 접근 가능한 옵션으로 엑세스 토큰과 리프레시 토큰을 저장하는 코드를 발견했습니다.

스크립트 접근 불가능하도록 수정하고, 요청량이 많지 않아 리모트 프록시에서 Auth header를 셋업해서 중개하는 작업을 하는 도중 들었던 궁금증입니다.

왜 Authorization 헤더는 'Bearer'일까?


이 글에서 다루는 내용​

이 글에서는 Bearer 토큰이 왜 현대 웹 인증에서 표준처럼 자리 잡았는지, 그리고 이를 활용하는 방법에 대해 다룹니다. 단순한 HTTP 헤더 속 문자열처럼 보이지만, Bearer 토큰은 API 보안, OAuth 2.0, OpenID Connect 등 다양한 기술에서 핵심적인 역할을 합니다.

특히, JWT(JSON Web Token)를 기반으로 한 인증 흐름과 SPA(Single Page Application)에서의 보안 구현, 토큰의 한계와 이를 보완하는 기술들에 대해 간략히 풀어 설명합니다.




1. 서론: Authorization Bearer 토큰이란 무엇인가?​

Bearer 토큰은 오늘날 웹 애플리케이션과 API 통신에서 가장 흔히 사용되는 인증 방식 중 하나입니다. 클라이언트가 서버에 요청을 보낼 때, 사용자의 인증 상태를 나타내기 위해 HTTP의 Authorization 헤더에 Bearer 토큰이 포함됩니다. 이 단원에서는 Bearer 토큰이 무엇인지 간략히 소개하고, JWT(JSON Web Token)와의 관계를 살펴보겠습니다.


Authorization 헤더의 역할​

Authorization 헤더는 HTTP 프로토콜에서 클라이언트가 서버에 인가된 상태임을 전달하는 수단으로 사용됩니다. 이는 사용자 인증을 거친 후, 서버에 자신의 신원을 증명하기 위해 필수적입니다. 일반적으로 다음과 같은 구조를 가집니다.

Authorization: <스키마> <자격 증명>

여기서 <스키마>는 인증 방식(예: Basic, Bearer)을 나타내고, <자격 증명>은 클라이언트의 인증 정보를 포함합니다. Bearer는 이러한 인증 방식 중 하나로, OAuth 2.0에서 널리 사용되는 스키마입니다.

Bearer 토큰이란?​

Bearer 토큰은 클라이언트가 특정 리소스에 접근할 수 있는 권한을 증명하기 위해 서버에 전달하는 토큰입니다. 토큰은 HTTPS를 통해 전송되어야 하며, 이를 통해 토큰이 네트워크에서 탈취되는 것을 방지할 수 있습니다.

Authorization: Bearer <토큰>

더 자세한 내용은 다음 단원에서 설명합니다.

JWT(JSON Web Token)의 정의와 Bearer 토큰과의 관계​

JWT는 Bearer 토큰에서 자주 사용되는 토큰 포맷 중 하나입니다. JWT는 self-contained token으로, 다음과 같은 구조를 가집니다.

  1. Header: 토큰의 타입과 서명 알고리즘 정보를 포함합니다.
  2. Payload: 사용자 정보와 클레임(Claims, 권한 정보 등)을 담습니다.
  3. Signature: 토큰의 무결성을 보장하기 위한 서명입니다.
JWT 구조 이미지

출처: https://jwt.io/introduction

JWT는 Bearer 토큰으로 자주 사용되며, 서버가 별도의 세션 상태를 관리하지 않아도 인증을 수행할 수 있도록 해줍니다. 이 덕분에 RESTful API와 같은 stateless 아키텍처에서 효율적으로 사용됩니다.


Recap​

Bearer 토큰은 클라이언트가 서버에 자신을 인증하기 위해 사용하는 간단하고 효과적인 방식입니다. 특히 JWT는 Bearer 토큰의 구현 방식으로 널리 활용되며, 클라이언트-서버 간의 인증을 효율적이고 안전하게 처리할 수 있는 기반을 제공합니다. 이 방식은 OAuth 2.0과 HTTPS의 조합을 통해 현대 웹 애플리케이션의 핵심적인 인증 방식으로 자리 잡았습니다.



2. 역사적 배경: Authorization 헤더와 Bearer 스키마의 등장​

Bearer 토큰이 현재와 같은 표준으로 자리 잡기까지는 HTTP 프로토콜의 발전과 OAuth 2.0의 도입, 그리고 RFC 문서들의 정의가 중요한 역할을 했습니다. 이 단원에서는 Authorization 헤더와 Bearer 스키마의 기원과 역사적 맥락을 살펴봅니다.


HTTP 표준과 Authorization 헤더의 시작​

Authorization 헤더는 클라이언트가 서버에 인증 정보를 전달하기 위한 표준화된 방법으로, HTTP/1.1 표준에서 처음 정의되었습니다.

1. HTTP/1.1 RFC 2616​

RFC 2616은 HTTP/1.1에서 Authorization 헤더를 정의하며, 클라이언트가 서버에 자격 증명을 제공할 수 있는 메커니즘을 명확히 했습니다. 초기에는 아래와 같은 두 가지 주요 인증 방식을 제안했습니다.

RFC2616

RFC 2616에 명시된 Authorization 헤더

  • Basic Authentication: 사용자 이름과 비밀번호를 Base64로 인코딩하여 전송. 매우 간단하지만 보안 취약점이 큼.
GET /protected-resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
# dXNlcm5hbWU6cGFzc3dvcmQ=는 Base64로 인코딩된 username:password입니다.
  • Digest Authentication: 암호화 해시를 사용해 Basic Auth보다 보안을 강화.

이러한 방식들은 클라이언트와 서버 간의 지속적인 상태 관리를 필요로 하거나, 민감한 정보를 전송하는 데 있어 한계가 있었습니다.

2. OAuth 2.0의 등장 (RFC 6749, 2012)​

OAuth 2.0은 클라이언트가 리소스 소유자를 대신하여 서버에 접근할 수 있는 인증과 권한 위임 방식을 표준화한 프레임워크입니다. 이 프레임워크는 민감한 사용자 정보를 직접 전송하지 않고, 대신 액세스 토큰(access token)을 사용하여 인증을 수행합니다.

이 과정에서 Authorization 헤더는 토큰 기반 인증의 전달 수단으로 채택되었고, Bearer 스키마가 OAuth 2.0의 핵심 인증 방식으로 자리 잡았습니다.

“Bearer”라는 단어의 기원​

Bearer 스키마는 RFC 6750 (2012)에서 정의되었으며, OAuth 2.0에서 액세스 토큰을 전달하는 표준 방식으로 사용됩니다.

RFC2616

RFC 6750에 등장하는 "Bearer"

1. RFC 6750의 정의와 역할​

RFC 6750은 Bearer 토큰의 사용법과 동작 원리를 명확히 규정했습니다. 핵심 내용은 다음과 같습니다:

  • Bearer 토큰은 요청의 Authorization 헤더에 포함됩니다.
  • 별도의 암호화 서명이나 추가 인증이 필요하지 않으며, 토큰을 소지한 사람은 인증된 것으로 간주합니다.
Authorization: Bearer <토큰>

2. “Bearer”의 의미와 철학​

“Bearer”라는 용어는 영어 단어의 뜻 그대로 “소지자(bearer)”라는 의미를 가집니다. 즉, 토큰을 가지고 있는 자가 인증된 사용자로 간주되는 구조를 나타냅니다.

이러한 설계는 인증 절차를 단순화하고 클라이언트-서버 간의 상태를 유지할 필요 없이(stateless) 인증을 수행할 수 있는 효율적인 방법을 제공합니다.


Recap​

Authorization 헤더는 HTTP 프로토콜의 초창기부터 존재했지만, OAuth 2.0과 함께 Bearer 스키마가 정의되면서 간단하고 확장 가능한 토큰 기반 인증 방식으로 발전했습니다. “Bearer”라는 이름은 토큰을 소지한 자가 인증된 것으로 간주된다는 철학에서 비롯되었으며, 현대 웹 인증의 핵심 요소로 자리 잡게 되었습니다.



3. Bearer 토큰이 표준으로 자리 잡은 이유​

Bearer 토큰이 현대 웹 인증의 표준으로 자리 잡은 데에는 보안, 편의성, 그리고 표준화 측면에서의 이점이 컸습니다. 기존 인증 방식의 한계를 극복하고, 간단하면서도 확장 가능한 구조를 제공한다는 점에서 개발자와 시스템 모두에게 매력적인 선택지가 되었습니다.


보안 측면​

기존의 인증 방식, 예를 들어 Basic Authentication이나 Cookie-based Authentication은 다음과 같은 문제점이 있었습니다.

  • Basic Auth는 사용자 자격 증명을 평문으로 전송하거나 낮은 수준의 암호화만 적용되어 보안에 취약했습니다.
GET /resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
  • Cookie-based Auth는 서버가 세션 상태를 유지해야 했고, 클라이언트-서버 간 상태 동기화가 필요해 복잡성이 증가했습니다.
GET /resource HTTP/1.1
Host: example.com
Cookie: session_id=abc123

이에 비해 Bearer 토큰은 Stateless 인증 방식을 채택하여 서버가 상태를 관리하지 않아도 되고, HTTPS와 결합해 데이터 탈취 위험을 크게 줄일 수 있었습니다.

GET /resource HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

HTTPS는 토큰 자체를 암호화된 통신 경로로 보호하므로, Bearer 토큰의 주요 보안 취약점을 보완하는 핵심 요소로 작용합니다.


인증 방식주요 특징보안 위험개선 사항
Basic Auth사용자 인증 정보를 Base64로 인코딩하여 전송평문 전송으로 HTTPS 없이는 매우 취약HTTPS 사용 필수
Cookie-based Auth서버가 세션 상태를 유지하며 인증 수행세션 탈취, XSS 공격에 취약SameSite 쿠키, HTTP-only 쿠키 사용
Bearer TokenStateless 인증, 토큰 자체로 인증 수행탈취된 토큰 악용 가능HTTPS 사용, 짧은 만료 시간, Scope 제한

사용 편의성​

Bearer 토큰은 인증 과정을 단순화하여 클라이언트와 서버 간 통신을 더 효율적으로 만듭니다.

  • 클라이언트는 요청 시 Authorization 헤더에 토큰만 추가하면 되므로 추가적인 인증 절차가 필요 없습니다.
  • Stateless 구조 덕분에 서버가 상태를 유지할 필요 없이 확장 가능한 인증 시스템을 구현할 수 있습니다.

표준화와 상호운용성​

OAuth 2.0의 등장과 함께 Bearer 토큰은 API 설계에서 사실상의 표준으로 자리 잡았습니다. Bearer 토큰은 다음과 같은 점에서 표준화와 상호운용성을 강화했습니다:

  • 다양한 플랫폼에서 쉽게 구현할 수 있는 일관된 인증 방식 제공.
  • JWT(JSON Web Token)와 결합하여 클라이언트와 서버 간의 인증 정보를 효율적으로 전달.
  • RESTful API 설계에서 간결성과 확장성을 보장.

Recap​

Bearer 토큰은 기존 인증 방식의 보안 및 복잡성 문제를 해결하면서, 간단하고 표준화된 방식으로 시스템 간 상호운용성을 가능하게 했습니다. 특히 OAuth 2.0과 HTTPS, JWT와의 결합을 통해, Bearer 토큰은 현대 API 설계에서 필수적인 인증 요소로 자리 잡았습니다.



4. Bearer 토큰의 한계와 보완책​

Bearer 토큰은 간단하고 효율적인 인증 방식이지만, 설계 특성상 몇 가지 보안 취약점을 내포하고 있습니다. 이를 보완하기 위한 다양한 방법과 대안 기술을 살펴보겠습니다.


보안 취약점​

Bearer 토큰의 가장 큰 약점은 토큰 자체가 인증 자격 증명이라는 점입니다.

  • 토큰 탈취 위험: Bearer 토큰은 소지자가 인증된 것으로 간주되기 때문에, 탈취된 토큰이 악의적으로 사용될 수 있습니다.
  • MITM(중간자 공격): HTTPS가 적용되지 않은 경우, 네트워크를 가로채어 토큰이 노출될 가능성이 있습니다.

보완 방법​

Bearer 토큰의 보안 취약점을 줄이기 위해 다음과 같은 방법을 사용할 수 있습니다:

  • HTTPS 사용: 모든 통신에서 HTTPS를 강제하여 토큰이 암호화된 채로 전송되도록 해야 합니다.
  • 토큰 만료 시간 설정: 짧은 만료 시간을 가진 액세스 토큰과 함께, 만료된 토큰을 갱신할 수 있는 Refresh Token을 사용하는 방식이 일반적입니다.
  • Scope와 Permission 제한: 토큰이 특정 리소스와 작업에만 접근하도록 제한(Scope 설정)하면, 토큰 탈취의 피해를 최소화할 수 있습니다.

대안 인증 방식​

Bearer 토큰의 한계를 보완하거나 대체하기 위해 다음과 같은 인증 방식을 고려할 수 있습니다:

  • Proof-of-Possession (PoP) 토큰: Bearer 토큰과 달리, 토큰 소지 여부만으로 인증하지 않고, 요청에 서명하여 토큰의 정당성을 추가로 검증합니다. 이 방식은 탈취된 토큰이 유효하지 않도록 만듭니다.
  • Mutually Authenticated TLS (MTLS): 클라이언트와 서버가 서로를 인증하는 TLS 인증 방식으로, 통신 양측의 신뢰성을 보장합니다. 이 방법은 높은 수준의 보안을 요구하는 환경에서 유용합니다.

Recap​

Bearer 토큰은 간단하고 널리 사용되는 인증 방식이지만, 탈취와 악용에 취약한 단점이 있습니다. HTTPS, 토큰 만료 관리, Scope 제한 등을 통해 보안을 강화할 수 있으며, PoP 토큰이나 MTLS와 같은 대안을 활용하면 더 높은 수준의 보안이 가능합니다. 상황에 맞는 보완책과 대안 기술을 적절히 조합하여 Bearer 토큰의 약점을 효과적으로 극복할 수 있습니다.



5. 실무에서의 Bearer 토큰 사용 사례​

Bearer 토큰은 RESTful API와 같은 현대 웹 애플리케이션의 인증 방식에서 핵심적인 역할을 합니다. 실무에서 Bearer 토큰이 사용되는 구체적인 사례와 그 구조를 살펴보겠습니다.


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 요청 시 사용합니다.
  • 보안 위험을 줄이기 위해, 토큰은 HTTP-only 쿠키로 전달하는 방식이 점점 선호되고 있습니다.
HTTP/1.1 200 OK
Set-Cookie: access_token=JWT_TOKEN; HttpOnly; Secure; SameSite=Strict
Content-Type: application/json

{
  "message": "Logged in successfully"
}

백엔드 간 통신​

  • 백엔드 서비스 간 통신에서도 Bearer 토큰이 사용됩니다. 예를 들어, 서비스 A가 서비스 B의 리소스에 접근하려면 서비스 A의 토큰을 전달해 인증을 수행합니다.

OpenID Connect에서의 Bearer 토큰 역할​

OpenID Connect는 OAuth 2.0의 확장 프로토콜로, 인증과 사용자 정보를 처리합니다. 이 과정에서 Bearer 토큰이 중요한 역할을 합니다:

  • Access Token: 사용자 권한을 인증하고, API 요청 시 인증 정보를 전달합니다.
  • ID Token: 사용자의 ID 정보(예: 이메일, 이름)를 JSON Web Token 형식으로 포함해 클라이언트에 전달합니다.
  • Refresh Token: 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용됩니다.

OpenID Connect는 Bearer 토큰과 함께 동작하여, 인증과 권한 관리를 간소화하고 표준화된 방식으로 제공합니다.

Access Token 및 ID Token 발급:

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

Response:

{
  "access_token": "ACCESS_TOKEN",
  "id_token": "ID_TOKEN",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "REFRESH_TOKEN"
}

Recap​

Bearer 토큰은 RESTful API, 모바일 앱, SPA, 백엔드 서비스 등 다양한 플랫폼에서 인증의 기본 요소로 사용되고 있습니다. 또한 OpenID Connect와 결합하여, 인증과 권한 관리를 위한 강력한 도구로 자리 잡았습니다. 실무에서는 보안 강화를 위해 HTTPS와 만료 관리, 저장 방식에 대한 신중한 선택이 필수적입니다.



6. Bearer 토큰의 현재와 미래​

Bearer 토큰은 현재 웹과 API 통신에서 가장 널리 사용되는 인증 방식으로, 간결성과 효율성을 통해 표준으로 자리 잡았습니다. 특히, OAuth 2.0과 JWT를 활용한 Bearer 토큰은 RESTful API와 같은 stateless 시스템에서 인증의 핵심 요소로 기능하며, 현대 웹 아키텍처의 기반을 이루고 있습니다.


Bearer 토큰의 의의​

  • 간단한 구조와 폭넓은 호환성을 제공하여 다양한 플랫폼과 서비스 간 상호운용성을 지원합니다.
  • HTTPS와 결합하여 기본적인 보안 요구 사항을 충족하면서도, 서버의 상태를 유지하지 않는 stateless 인증을 가능하게 합니다.

현재 기술 트렌드와 Bearer 토큰의 지속 가능성​

기술 발전과 보안 요구의 증가 속에서도 Bearer 토큰은 여전히 중요한 역할을 수행하고 있습니다. 하지만, 탈취에 취약하다는 본질적인 한계는 완전히 해결되지 않았습니다. 이에 따라 다음과 같은 보완 기술과 대안이 주목받고 있습니다:

  • Proof-of-Possession(PoP) 토큰: 토큰 사용 시 추가 검증 절차를 통해 보안을 강화.
  • Mutually Authenticated TLS(MTLS): 서버와 클라이언트 간 양방향 인증을 통해 신뢰성을 높임.

미래의 인증 방식​

Bearer 토큰은 여전히 중요한 인증 수단이지만, 더 안전하고 효율적인 방식으로의 전환이 논의되고 있습니다. WebAuthn, Zero Trust 보안 모델 등은 비밀번호와 토큰을 넘어서는 차세대 인증 방식을 제안하며, 사용자와 리소스를 더욱 안전하게 보호하려는 방향으로 진화하고 있습니다.


Recap​

Bearer 토큰은 간결함과 유연성 덕분에 오늘날 웹 표준으로 자리 잡았지만, 보안 강화를 위한 개선과 새로운 인증 방식의 도입이 병행되고 있습니다. 기술 환경과 보안 요구가 발전함에 따라, Bearer 토큰은 중요한 역할을 유지하면서도 새로운 인증 모델과 공존하게 될 것입니다.



References​

JWT(JSON Web Token)

  1. Official JWT Website
  2. RFC 7519: JSON Web Token (JWT)

OAuth 2.0

  1. RFC 6749: The OAuth 2.0 Authorization Framework
  2. OAuth 2.0 Simplified (Aaron Parecki)

OpenID Connect

  1. OpenID Connect Official Specification
  2. OpenID Connect Developer Primer

HTTP-only 쿠키와 보안

  1. MDN Web Docs: HTTP Cookies
  2. OWASP: Cross-Site Scripting Prevention
  3. SameSite Cookies Explained

General References

  1. RFC 2616: HTTP/1.1
  2. RFC 6750: Bearer Token Usage
  3. REST API Best Practices