Bearer

베어러(Bearer)는 유효한 토큰을 가진 쪽이 그 토큰에 부여된 범위에서 접근할 수 있는 토큰의 성질을 나타내는 말이자 HTTP 인증 방식입니다. 사용할 때 별도의 암호 키를 소유한다는 증명을 요구하지 않으므로 토큰의 노출을 막는 것이 중요합니다. API 요청에서 Bearer는 인증 방식의 이름이며, 그 뒤에 붙는 문자열이 실제 접근 토큰입니다.

토큰 소지에 기반한 접근

RFC 6750은 베어러 토큰을 가진 누구나 같은 토큰을 가진 다른 쪽과 같은 방식으로 사용할 수 있다고 정의합니다. 서버에 토큰을 제시할 때 별도 암호 키의 소유를 입증하는 절차가 필요 없다는 뜻입니다. 서버가 토큰을 검사하지 않는다는 뜻은 아니며, 토큰 자체의 유효성과 허용 범위는 여전히 확인 대상입니다.

이 성질 때문에 토큰을 훔친 쪽도 유효 기간과 권한 범위 안에서 사용할 수 있습니다. 토큰을 처음 발급받은 사람인지 매번 비밀번호로 다시 증명하는 구조와 다릅니다. 토큰을 복사할 수 없게 만드는 기능이 Bearer라는 이름에 포함되어 있는 것도 아닙니다. 접근에 쓰는 값 자체를 보호해야 하므로 보관 중 유출과 전송 중 노출을 함께 막아야 합니다.

OAuth 2.0 명세에서 접근 토큰은 특정 접근 범위와 수명 등을 나타내는 자격 증명입니다. 클라이언트는 이를 이용해 보호된 자료를 요청하고 서버는 유효한 요청인지 판단합니다. 따라서 토큰을 가졌다고 모든 자료를 무제한으로 읽거나 수정할 수 있는 것은 아닙니다. 읽기만 허용된 토큰이라면 그 허용 범위가 접근의 경계가 됩니다.

인증 방식과 토큰 형식의 차이

HTTP 요청에서는 Authorization 헤더에 Bearer라는 방식 이름과 접근 토큰을 함께 전달합니다. Bearer 명세는 이 헤더 방식을 권장하며 리소스 서버가 지원하도록 요구합니다. Bearer라는 단어는 서버에 토큰의 사용 방식을 알리는 표지입니다. 단어 자체가 비밀번호이거나 사용자의 개별 토큰 값인 것은 아닙니다.

토큰을 어떻게 얻는지와 얻은 토큰을 어떻게 사용하는지도 구별됩니다. OAuth는 접근 권한을 얻고 토큰을 발급받는 흐름을 다루며, Bearer는 토큰을 제시해 보호된 자료에 접근하는 방식입니다. 따라서 API 설명에 Bearer가 등장했다는 이유만으로 모든 발급 절차를 알 수는 없습니다. 어느 서버에서 어떤 조건으로 토큰을 받는지는 해당 서비스의 인증 절차를 따릅니다.

Bearer는 토큰 내부의 데이터 형식을 하나로 정하지 않습니다. OAuth 2.0 명세는 접근 토큰에 여러 형식과 구조가 있을 수 있다고 설명합니다. 토큰 안에 권한 정보가 들어 있을 수도 있고, 서버가 별도로 보관한 정보를 찾는 식별자일 수도 있습니다. 따라서 토큰 문자열의 겉모양만으로 권한을 추측하거나, 모든 Bearer 토큰을 같은 방식으로 해독할 수 있다고 가정해서는 안 됩니다.

유효성 검사와 노출 방지

토큰이 만료됐거나 사용할 수 없는 경우와 토큰의 권한이 요청에 부족한 경우는 다릅니다. RFC 6750은 이를 invalid_token과 insufficient_scope로 구분합니다. 앞의 경우에는 새 토큰이 필요할 수 있고, 뒤의 경우에는 요청한 작업이 허용 범위에 포함되는지 확인해야 합니다. 같은 값을 그대로 다시 보내는 일만으로 두 문제를 모두 해결할 수는 없습니다.

전송 중 토큰을 보호하기 위해 Bearer 명세는 TLS 사용을 요구합니다. 또한 URL에 토큰을 넣으면 방문 기록이나 서버 로그 등에 남을 수 있어 노출 위험이 커집니다. Authorization 헤더에 넣더라도 값을 외부에 공개해도 된다는 뜻은 아닙니다. 전송 암호화는 통신 경로를 보호하며, 토큰이 다른 경로로 복사되거나 공개되는 문제까지 없애 주지는 않습니다.

접근 토큰과 갱신 토큰도 역할이 다릅니다. OAuth 2.0 명세의 갱신 토큰은 새 접근 토큰을 얻는 데 쓰며, 리소스 서버로 보내는 값이 아닙니다. 갱신 토큰의 발급 자체도 선택 사항입니다. 두 값을 모두 토큰이라고 부르더라도 서로 바꾸어 API 요청에 넣을 수는 없으며, 각각 발급받은 목적과 전송 대상을 지켜야 합니다.