콘텐츠로 이동

OAuth2 스코프 — "얼마나" 허락할지 정하기

사용자가 "이 앱이 내 데이터에 접근해도 돼"라고 할 때, 묻지도 않고 전부 열어주는 건 아니에요. 스코프(scope)가 "어디까지"를 좁혀서 정해줍니다. 못 보게 하려는 게 아니라, "볼 수 있는 것과 없는 것"을 승인 시점에 분명히 나눠 두는 거죠.

개요

스코프는 OAuth의 권한 위임 범위를 나타내는 값이에요. 예를 들어 "문서 읽기", "파일 쓰기"처럼 범위 단위로 정의되고, 앱이 요청한 스코프와 사용자가 동의한 스코프가 실제 토큰에 남아서 접근 제어의 기준이 됩니다.

핵심 개념

스코프는 문자열(보통 공백으로 구분)로 표현돼요. 앱이 인가 요청에 scope=read write처럼 원하는 범위를 담아 보내고, 인증 서버는 사용자 동의 후 이 범위만 담긴 토큰을 발급해요. 토큰에 없는 스코프는 리소스 서버가 거부하죠.

권한의 범위를 "최소한"으로. 스코프 설계의 핵심 원칙은 최소 권한이에요. 기능이 "읽기만" 필요하다면 쓰기 스코프를 요청하지 않아요. 스코프를 넓게 잡을수록 토큰 하나가 유출됐을 때 피해가 커지니까요.

스코프 이름은 단순히 표시용이 아니에요. "read", "write" 같은 이름이 실제로 어떤 데이터·행동을 가리키는지, API 쪽이 그 스코프를 어떻게 해석하는지가 중요해요. 스코프 이름과 실제 권한 해석이 어긋나면 보안 구멍이 생겨요.

서버는 "승인된 것만" 실행하고, "요청된 대로" 실행하면 안 돼요. 스코프는 단지 요청의 표시가 아니라, 인증 서버가 검증하고 토큰에 기록한 허가의 결과라서, API 쪽은 요청에 실린 주장이 아니라 토큰에 기록된 스코프를 기준으로 판단해야 해요.

스코프 vs 클레임. 스코프는 "토큰이 가진 권한 범위"이고, 클레임은 "토큰이 가진 정보 항목"이에요. 헷갈리기 쉬운데, 스코프는 접근 범위, 클레임은 주장하는 속성으로 구분하면 됩니다.

스코프를 하나의 "권한 단위"로 설계해요. 스코프는 단순한 문자열이지만, 실제로는 API가 내부적으로 권한 판단에 쓰는 단위예요. 그래서 "read", "write"처럼 기능 단위로 나누고, 기능이 세분화되면 스코프도 함께 다듬어요. 스코프 하나가 너무 넓으면(예: "전체 관리") 최소 권한 원칙이 무너지니까, 기능 단위로 잘게 나누는 편이 관리하기 좋아요.

미지의 스코프는 거부해야 해요. 인증 서버가 요청받은 스코프 중 모르는 값이나 허용할 수 없는 값을 발견하면, 토큰을 발급하지 않고 오류(invalid_scope)로 응답해야 해요. "일단 다 발급해 두자"는 식은 권한 범위가 의도치 않게 넓어지는 지름길이에요.

실제 적용(데이터스케쳐스)

외부 서비스 연동에서 우리는 필요한 스코프만 최소로 요청해요. 예를 들어 문서를 읽어 분석하는 기능이라면 읽기 스코프만 요청하고 쓰기·삭제 스코프는 요청하지 않는 식이에요. 요청 화면에서 사용자에게도 "어디까지 허락하는지"가 투명하게 보이도록 해요.

서비스 간 통신에서도 스코프를 좁게 유지해요. 토큰마다 할 수 있는 일을 스코프로 기록하고, API 쪽은 "이 스코프면 이 기능 허용"처럼 토큰에 기록된 스코프를 기준으로 판단하는 게 원칙입니다. 이렇게 하면 토큰이 탈취돼도 그 토큰이 가진 좁은 범위 밖으로는 손을 뻗지 못해요.

더 알아보기