OAuth란? OAuth 1.0 흐름으로 이해하기

OAuth는 사용자의 비밀번호를 제삼자 애플리케이션에 넘기지 않고 보호 자원에 대한 접근 권한을 위임하는 프로토콜이다. 예를 들어 사진 인쇄 앱이 사용자의 사진을 읽어야 한다면, 사진 서비스에서 사용자가 권한을 승인하고 앱은 허용된 범위의 토큰을 받는다. OAuth 자체는 사용자 신원을 증명하는 로그인 규격이 아니다. 소셜 로그인에서 사용자 신원을 확인하려면 별도의 사용자 정보 API나 OpenID Connect 같은 규격을 함께 사용한다.

이 글은 그림과 함께 OAuth 1.0의 흐름을 설명한다. OAuth 2.0은 토큰 발급 흐름과 서명 모델이 달라 다음 글에서 다룬다.

참여자와 자격 증명

이름	이 글의 역할
사용자(Resource Owner)	사진에 대한 권한을 가진 사람
소비자(Consumer, Client)	사진 인쇄 앱
서비스 공급자(Service Provider)	사진 API와 사용자 승인 화면을 제공하는 곳
Request Token	사용자 승인 전, 클라이언트가 받는 임시 토큰
Access Token	승인 후 보호 자원 요청에 사용하는 토큰

클라이언트는 사전에 서비스 공급자에 등록해 oauth_consumer_key와 비밀값을 받는다. 1.0에서는 요청 토큰과 접근 토큰에 각각 대응하는 토큰 비밀값도 사용한다. 토큰 문자열 하나만 알면 모든 요청을 만들 수 있는 구조가 아니라, 요청마다 서명을 붙여 보낸다.

그림을 따라가는 발급 흐름

1. A → B, 임시 토큰: 클라이언트가 서명된 요청을 보내 Request Token과 해당 토큰의 비밀값을 받는다. 이 단계에는 사용자의 동의가 없다.
2. C → D, 사용자 승인: 브라우저를 서비스 공급자의 승인 화면으로 보내 사용자가 로그인하고 권한을 승인한다. 서비스 공급자는 등록된 callback으로 oauth_token과 oauth_verifier를 돌려준다. 화면에서 거절하면 다음 단계로 진행하지 않는다.
3. E → F, 접근 토큰: 클라이언트가 Request Token과 verifier를 사용해 Access Token과 새 토큰 비밀값을 요청한다. verifier는 앞의 사용자 승인과 토큰 교환을 연결한다.
4. G, 보호 자원 요청: 클라이언트가 Access Token을 포함한 요청에 다시 서명해 사진 API를 호출한다. 서비스 공급자는 서명, 토큰의 권한, 요청 범위를 확인한다.

callback이 없는 클라이언트를 위한 oob 방식은 구형 서비스 설명에서 볼 수 있지만, 새 연동에서는 공급자의 현재 정책과 안전한 리다이렉트 방식을 확인해야 한다.

요청 서명은 무엇을 보호하나?

OAuth 1.0의 oauth_signature는 단순히 매개변수들을 암호화한 값이 아니다. 양쪽이 같은 서명 기본 문자열(signature base string)을 만들고, 키로 서명해 요청의 무결성과 자격 증명 소유를 확인한다. RFC 5849는 HMAC-SHA1, RSA-SHA1, PLAINTEXT 방법을 정의한다. 이전 글의 HMAC-MD5는 표준 방법 목록에 없다.

HMAC-SHA1의 절차를 요약하면 다음과 같다.

1. 요청의 OAuth 매개변수와 URL 쿼리 매개변수를 모은다. 조건에 맞는 application/x-www-form-urlencoded 본문 매개변수도 포함한다. oauth_signature 자체와 다른 본문 형식은 제외한다.
2. 각 이름과 값을 RFC 3986 방식으로 인코딩한 뒤 이름, 값 순으로 정렬하고 name=value 쌍을 &로 연결한다. 먼저 인코딩한 후 정렬해야 같은 입력에서 같은 문자열이 나온다.
3. 대문자 HTTP 메서드, 정규화한 기본 URL, 정규화한 매개변수 문자열을 각각 인코딩하여 &로 연결한다. URL의 쿼리는 기본 URL에 넣지 않고 앞 단계 매개변수에 넣는다.
4. 클라이언트 비밀값과 해당 토큰 비밀값을 각각 인코딩해 &로 연결한 키로 HMAC-SHA1을 계산하고 Base64로 표현한다. Request Token 발급 요청처럼 토큰 비밀값이 아직 없으면 빈 문자열을 사용한다.

예를 들어 쿼리의 page=2를 서명에서 빼면 공격자가 페이지를 바꿔도 같은 서명이 통과할 수 있다. 반대로 클라이언트와 서버의 인코딩 방식이 다르면 정상 요청도 거절된다. oauth_nonce와 oauth_timestamp는 재전송 공격을 탐지하는 데 쓰이며 서버는 허용 시간 범위와 이미 본 nonce를 정책에 따라 확인해야 한다. 서명은 전송 중 내용의 기밀성을 제공하지 않으므로 HTTPS도 사용해야 한다.

구현 시 확인할 점

Request Token을 Access Token으로 바꾸는 요청에는 oauth_token과 oauth_verifier를 포함한다. 이후 보호 자원 요청에는 Access Token과 그 토큰 비밀값을 사용한다. Request Token의 비밀값을 계속 사용하면 서명이 맞지 않는다. 토큰과 비밀값은 로그·URL·클라이언트 노출 영역에 남기지 않고, 권한 철회와 만료 정책도 공급자 문서에서 확인한다.

이 글은 OAuth 1.0의 구조를 읽기 위한 설명이다. 새 서비스의 인증·인가 방식을 선택할 때는 공급자가 지원하는 OAuth 2.0/OIDC 흐름과 최신 보안 지침을 먼저 확인한다.

참고: RFC 5849: The OAuth 1.0 Protocol