액세스 토큰

보호된 자원에 접근할 때 대신 내미는 문자열입니다. 비밀번호를 넘기지 않고도 남의 프로그램이 내 자원을 쓰게 해 줍니다. 무엇을 얼마 동안 할 수 있는지가 이 문자열에 매여 있습니다.

상세

호텔 프런트에서 받는 카드키와 비슷합니다. 며칠 동안 어느 방을 열 수 있는지만 담겨 있어서, 잃어버려도 그 카드만 못 쓰게 만들면 됩니다.

액세스 토큰은 보호된 자원에 접근하는 데 쓰이는 자격증명입니다. RFC(Request for Comments) 6749 는 액세스 토큰을 클라이언트에게 발급된 인가를 나타내는 문자열이라고 적습니다. 그 문자열은 대개 클라이언트에게 불투명합니다. 문자열이라 복사됩니다. 남에게 건네도 건넨 쪽에 그대로 남습니다. 토큰은 특정한 범위와 접근 기간을 나타냅니다. 그 범위와 기간은 자원 소유자가 승인하고, 자원 서버와 인가 서버가 강제합니다.

문자열 안에 무엇이 들었는지는 못 박혀 있지 않습니다. 같은 문서는 토큰이 인가 정보를 찾아오는 데 쓰는 식별자를 가리킬 수도 있고, 검증 가능한 방식으로 인가 정보를 자체에 담을 수도 있다고 적습니다. 뒤쪽은 데이터 얼마간과 서명으로 이뤄진 문자열입니다. 클라이언트가 토큰을 쓰려면 추가 인증 자격증명이 필요할 수도 있습니다. 그 자격증명은 이 명세의 범위 밖입니다.

액세스 토큰은 추상화 레이어를 제공합니다. 사용자 이름과 비밀번호 같은 서로 다른 인가 구성물을 자원 서버가 이해하는 토큰 하나로 갈음합니다. 이 추상화 덕분에 토큰을 얻는 데 쓴 인가 그랜트보다 더 제한적인 액세스 토큰을 발급할 수 있습니다. 자원 서버가 여러 인증 방식을 이해할 필요도 없어집니다.

형식과 구조와 이용 방식은 자원 서버의 보안 요구에 따라 달라질 수 있습니다. RFC 6749 는 토큰의 속성과 보호된 자원에 접근하는 방법이 이 명세의 범위 밖이라고 적습니다. 그것은 RFC 6750 같은 동반 명세가 정한다고 덧붙입니다.

배경

전통적인 클라이언트-서버 인증 모델에서 클라이언트는 자원 소유자의 자격증명으로 서버에 인증해서 접근이 제한된 자원을 요청합니다. 서드파티 애플리케이션에 그 자원을 열어 주려면 자원 소유자가 자기 자격증명을 서드파티와 공유해야 했습니다. RFC 6749 는 여기서 생기는 문제와 한계를 이렇게 적습니다.

서드파티 애플리케이션은 나중에 쓰려고 자원 소유자의 자격증명을 저장해야 합니다. 대개 평문 비밀번호입니다.
서버는 비밀번호에 본래 있는 보안 약점에도 불구하고 비밀번호 인증을 지원해야 합니다.
서드파티 애플리케이션이 과도하게 넓은 접근을 얻습니다. 자원 소유자에게는 기간을 제한하거나 자원 일부로 접근을 좁힐 방법이 남지 않습니다.
자원 소유자는 서드파티 하나만 골라 접근을 취소할 수 없습니다. 전부 취소해야 합니다. 그러려면 서드파티의 비밀번호를 바꿔야 합니다.
서드파티 애플리케이션 하나가 침해되면 최종 사용자의 비밀번호와 그 비밀번호로 보호되던 모든 데이터가 침해됩니다.

OAuth 는 인가 레이어를 도입합니다. 클라이언트의 역할도 자원 소유자의 역할과 분리합니다. 그렇게 이 문제들을 다룹니다. 클라이언트는 자원 소유자가 통제하고 자원 서버가 호스팅하는 자원에 접근을 요청합니다. 그리고 자원 소유자의 것과는 다른 자격증명 한 벌을 발급받습니다.

자원 소유자의 자격증명으로 보호된 자원에 접근하는 대신 클라이언트는 액세스 토큰을 얻습니다. 특정한 범위와 수명과 그 밖의 접근 속성을 나타내는 문자열입니다. 액세스 토큰은 자원 소유자의 승인을 받아 인가 서버가 서드파티 클라이언트에게 발급합니다. 토큰을 받은 클라이언트는 그 뒤로 자원 서버에 이 토큰 하나를 내밉니다.

sequenceDiagram
    participant 소유자 as 자원 소유자
    participant 클라이언트
    participant 인가서버 as 인가 서버
    participant 자원서버 as 자원 서버
    소유자->>인가서버: 접근을 승인한다
    인가서버-->>클라이언트: 액세스 토큰을 발급한다
    클라이언트->>자원서버: 토큰을 제시하고 자원을 요청한다
    자원서버-->>클라이언트: 보호된 자원

예시

RFC 6749 의 토큰 응답

인가 서버는 액세스 토큰과 선택적인 리프레시 토큰을 발급합니다. 파라미터는 HTTP(HyperText Transfer Protocol) 응답 본문에 넣어 200(OK) 상태 코드로 돌려줍니다. access_token 은 필수입니다. 인가 서버가 발급한 액세스 토큰입니다. token_type 도 필수입니다. 값은 대소문자를 가리지 않습니다. expires_in 은 권장입니다. 액세스 토큰의 수명을 초로 적습니다. 값이 3600 이면 응답이 만들어진 시점부터 한 시간 뒤에 액세스 토큰이 만료된다는 뜻입니다. refresh_token 은 선택입니다.

명세에 실린 예제는 이렇습니다.

http

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}

토큰은 2YotnFZFEjr1zCsicMWpAA 라는 문자열 하나입니다. 클라이언트가 하는 일은 이 값을 받아 두었다가 요청에 실어 보내는 것입니다.

RFC 6750 의 Bearer 헤더

실어 보내는 자리는 Authorization 요청 헤더 필드입니다. RFC 6750 은 이 필드로 액세스 토큰을 보낼 때 클라이언트가 Bearer 인증 스킴을 쓴다고 적습니다.

http

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

mF_9.B5f-4.1JqM 가 액세스 토큰 값입니다. 클라이언트는 이 방식으로 인증된 요청을 보내는 것이 권장됩니다. 자원 서버는 이 방식을 반드시 지원해야 합니다. 같은 문서는 bearer 토큰을 가진 쪽은 누구든 그 토큰으로 연결된 자원에 접근할 수 있다고 적습니다. 암호 키를 가졌음을 증명하지 않고도 그렇게 됩니다. 그래서 저장할 때와 전송할 때 노출되지 않도록 보호해야 한다고 덧붙입니다.

GitHub REST API

제품 쪽 실물입니다. GitHub 의 REST(Representational State Transfer) API(Application Programming Interface) 문서는 토큰을 만든 뒤 요청의 Authorization 헤더에 그 토큰을 실어 보내 인증한다고 적습니다. 아래 요청에서 YOUR-TOKEN 자리를 자기 토큰으로 바꾸라고 안내합니다.

터미널

curl --request GET \
--url "https://api.github.com/octocat" \
--header "Authorization: Bearer YOUR-TOKEN" \
--header "X-GitHub-Api-Version: 2026-03-10"

같은 문서는 대부분의 경우 Authorization: Bearer 나 Authorization: token 으로 토큰을 넘길 수 있다고 적습니다. 다만 JWT(JSON Web Token)를 넘길 때는 Authorization: Bearer 를 반드시 써야 합니다.

경계

토큰 응답에 함께 담겨 오는 리프레시 토큰도 액세스 토큰인가. 아닙니다.

RFC 6749 는 리프레시 토큰을 액세스 토큰을 얻는 데 쓰이는 자격증명이라고 적습니다. 인가 서버가 클라이언트에게 발급합니다. 현재 액세스 토큰이 무효가 되거나 만료됐을 때 새 액세스 토큰을 얻는 데 씁니다. 같거나 더 좁은 범위의 액세스 토큰을 추가로 얻는 데 쓰기도 합니다. 리프레시 토큰을 발급할지는 인가 서버의 재량이고 선택 사항입니다.

둘은 생김새가 닮았습니다. 리프레시 토큰도 자원 소유자가 클라이언트에게 부여한 인가를 나타내는 문자열입니다. 그 문자열도 대개 클라이언트에게 불투명합니다. 가르는 선은 내미는 상대입니다. 같은 문서는 액세스 토큰과 달리 리프레시 토큰이 인가 서버에서만 쓰도록 의도됐고 자원 서버에는 절대 보내지지 않는다고 적습니다. 보호된 자원 앞에 제시하는 쪽이 액세스 토큰입니다.

액세스 토큰

상세

배경

예시

RFC 6749 의 토큰 응답

RFC 6750 의 Bearer 헤더

GitHub REST API

경계

관련 항목