액세스 토큰
액세스 토큰 (Access Token)
OAuth 2.0에서 클라이언트가 보호된 리소스에 실제로 접근할 때 쓰는 자격 증명이 바로 **액세스 토큰(access token)**이에요. 사용자 이름이나 비밀번호를 매번 보내는 대신, 이 토큰을 리소스 서버 요청에 실어 보내면 서버가 그 토큰이 유효한지 판단해서 요청을 허락하죠. 공식 스펙은 이 토큰이 어떤 특별한 포맷이어야 한다고 강제하지 않아요. 실제로도 서버마다 16진수 문자열, 구조화된 토큰, 또 다른 형태를 제각각 쓸 수 있어요. 그래서 액세스 토큰을 만들기보다 어떻게 다뤄야 안전한지가 더 중요한 주제예요.
토큰은 클라이언트가 해석하지 않아요
액세스 토큰에 대한 오해가 하나 있어요. 많은 사람이 토큰 안에 사용자 정보가 담겨 있다고 생각하지만, OAuth의 보안 모델상 클라이언트는 토큰을 읽거나 해석해서는 안 돼요. 토큰의 의도된 독자가 클라이언트가 아니라는 점이 핵심이에요. 토큰은 리소스 서버가 검증하고 해석하는 값이지, 클라이언트가 내용을 뜯어볼 대상이 아니에요.
또한 액세스 토큰은 사용자 신원이나 그 외 사용자 정보를 클라이언트에 전달하는 수단이 아니에요. 만약 서버가 사용자 정보를 클라이언트에 알려주고 싶다면 ID 토큰 같은 별도 경로를 써요. 그리고 액세스 토큰은 오직 리소스 서버에 대한 요청에만 사용해야 해요. 서로 다른 용도(예: 사용자 식별)로 재사용하면 보안 경계가 무너지니까요.
베어러 토큰과 sender-constrained 토큰
액세스 토큰은 크게 두 가지로 나뉘어요.
- 베어러 토큰(bearer token) — 토큰을 소지한 사람이면 누구나 쓸 수 있는, 가장 널리 쓰이는 형태예요. 사용법이 단순하지만, 토큰이 유출되면 그대로 남용될 위험이 있어요.
- sender-constrained 토큰 — 클라이언트가 비밀키를 실제로 보유하고 있음을 증명해야 토큰을 쓸 수 있는 형태예요. 토큰 자체만으로는 쓸 수 없도록 묶어 두는 거죠. 따라서 토큰이 유출돼도 공격자가 그 토큰만으로는 악용하기 어려워요.
실제로는 어떻게 쓰나요
HTTP 요청에서도 토큰은 특정 헤더나 파라미터로 전달돼요. 가장 흔한 방식은 Authorization 헤더에 베어러 토큰을 싣는 것이에요. 예를 들어 리소스 서버로 보내는 요청은 대략 이런 모양이 돼요.
Authorization: Bearer <access_token>
이렇게 토큰을 어디에, 어떻게 담는지는 각 토큰의 타입(RFC 6750의 베어러, RFC 8693의 교환 토큰 등)에 따라 정해진 규약을 따르게 돼요.