[프로젝트] 🔎 OAuth 더 자세히 알아보기

OAuth 개요

방끗 팀 프로젝트에서는 카카오 로그인을 통해 사용자의 인증/인가를 구현한다. 카카오 로그인은 카카오 계정을 사용해 다양한 서비스에 로그인할 수 있도록 하는 OAuth 2.0 기반의 소셜 로그인 서비스이다. 단순히 카카오에서 제공하는 문서에 따라 구현하는 것을 넘어 OAuth 기술에 대한 이해도를 높이고자 글을 작성한다.

OAuth 프로토콜은 클라이언트에게 리소스 오너를 대신해 서버의 리소스에 접근할 수 있는 방법을 제공하는 기술이다.

OAuth 프로토콜은 보호되어있는 리소스에 대한 접근 권한을 위임하는 과정에서 발생하는 공통의 문제를 해결하기 위해 다양한 웹사이트 및 인터넷 서비스의 웹 개발자들로 구성된 소규모 커뮤니티에서 만들어졌다. OAuth 프로토콜의 첫 번째 버전(1.0)은 2007년에 안정화되었고 OAuth 2.0은 2012년에 표준화되었다.

OAuth 용어 정리

OAuth 용어는 OAuth 개념이나 동작 흐름을 이해할 때 중요한 부분이기 때문에 정리하고 넘어간다.

용어	설명
Protected Resource(보호된 리소스)	OAuth 인증 요청을 사용해서 서버에서 가져올 수 있는 제한된 리소스 → 카카오 서버에 저장되어있는 사용자 정보를 뜻한다
Resource Owner(리소스 소유자)	보호된 리소스에 접근하거나 통제할 수 있는 주체 → 서비스를 이용하고자하는 사용자를 뜻한다
Client(클라이언트)	OAuth 인증 요청을 보내는 HTTP 클라이언트 → 우리가 구현한 서비스를 뜻한다
Server(서버)	OAuth 인증 요청을 수락하는 HTTP 서버 → 카카오 서버를 뜻한다
Credentials(자격 증명)	애플리케이션 또는 사용자 권한을 증명하는 정보
Token(토큰)	서버에 의해 발행되고 클라이언트에 의해 사용되는 고유한 식별자

OAuth 등장 배경

전통적인 클라이언트-서버 인증 모델에서는 클라이언트가 서버에 리소스 소유자의 인증 정보를 제공하여 보호된 리소스에 접근하는 방식이 사용되었다. 예를 들어 사용자가 클라이언트에 비밀번호 정보를 제공하고 클라이언트를 이를 이용해 사용자 정보를 요청했다. 이 방식은 여러 문제가 있다.

서드파티(Third-Party) 애플리케이션이 리소스 소유자의 인증 정보를 저장해야 하며 대부분이 경우 이 정보를 평문으로 저장해 보안 문제가 발생할 수 있다. 서드파티 애플리케이션이 리소스 소유자로부터 지나치게 많은 접근 권한을 부여받게 되어 필요 이상으로 많은 권한을 행사할 수 있다. 그리고 서드파티 애플리케이션에서 보안 문제가 발생해 비밀번호가 유출되면그 비밀번호로 보호되는 모든 데이터가 노출될 위험이 있다.

이러한 보안 문제를 해결하기 위해 OAuth 기술이 도입되었다. OAuth는 권한 부여 계층을 도입해 클라이언트와 리소스 소유자의 역할을 분리한다. OAuth를 통해 클라이언트는 리소스 소유자의 인증 정보를 직접 사용하는 대신 액세스 토큰이라는 인증 수단을 사용하게 딘다. 액세스 토큰은 리소스 소유자의 승인 하에 서드파티 애플리케이션에 발급되며 이 토큰을 통해 서드파티 애플리케이션은 리소스에 접근할 수 있다.

OAuth 1.0과 OAuth 2.0 차이

OAuth 2.0 프로토콜은 OAuth 1.0과 하위 호환되지 않으며 매우 다른 구현 세부 사항을 가지고 있다. 카카오를 비롯해 대부분의 서비스에서 OAuth 2.0을 지원한다. 두 버전 간의 몇 가지 중요한 차이점을 살펴보며 OAuth 2.0 프로토콜의 특징을 이해하고자 한다.

복잡도와 사용 편의성

OAuth 1.0은 요청마다 암호화된 서명을 요구하는 복잡한 방식이었다. 클라이언트는 HMAC-SHA1 또는 RSA-SHA1과 같은 서명 알고리즘을 사용해 각 요청을 암호화해야 했다. 반면 OAuth 2.0에서는 서명을 요구하지 않고 TLS/SSL을 통해 통신 보안을 보장함으로써 인증 절차를 단순화했다. OAuth 2.0의 구현과 사용이 훨씬 간편해졌다.

Scope 기능

Scope 기능이 추가되면서 클라이언트가 리소스 서버에 요청하는 권한을 세분화해서 정의할 수 있다. 리소스 소유자가 서드파티 애플리케이션에 필요한 최소한의 권한만을 위임할 수 있다. 이 기능은 보안 측면에서 매우 중요하다. 애플리케이션이 필요한 권한만 요청함으로써 리소스 소유자의 불필요한 권한 노출을 방지할 수 있다.

서버의 역할 변화

서버의 중요한 역할 변화가 있었다. Authorization Server(권한 서버)와 Resource Server(리소스 소버)의 역할이 명확하게 분리되었다. OAuth 1.0에서는 서버가 모든 역할을 담당했다. OAuth 2.0에서는 권한 서버가 주로 인증과 권한 부여를 담당하며 리소스 소유자의 인증 정보와 클라이언트의 요청을 검증한 후 그 요청에 맞는 액세스 토큰을 발급한다. 또한 리소스 서버는 클라이언트로부터 받은 액세스 토큰의 유효성을 확인하고 유효한 토큰이라면 요청된 리소스를 제공하게 된다. 이를 통해 보안, 확장성, 유연성을 높였으며 다양한 클라이언트 및 서비스 환경에 더 나은 인증/인가 경험을 제공할 수 있게 한다.

토큰 탈취 문제 개선

액세스, 리프레시 토큰 개념을 많이 들어봤을 것이다. OAuth로부터 파생된 개념이다. 액세스 토큰은 기본적으로 시소스에 접근할 수 있는 인증 수단이다. 클라이언트가 보호된 리소스에 접근하려면 이 토큰을 사용해 인증을 받아야 한다. OAuth 1.0에서는 주로 액세스 토큰을 긴 시간 동안 사용하거나 갱신없이 재사용했다. OAuth 2.0부터는 리프레시 토큰 개념이 도입되면서 액세스 토큰의 만료 시간을 짧게 설정하고 시간이 만료되면 리프레시 토큰을 통해 새로운 액세스 토큰을 받을 수 있게 했다.

권한 요청 방식

OAuth 2.0은 OAuth 1.0에 비해 더 유연하고 다양한 사용 환경에 적용될 수 있도록 많은 개선이 이루어졌다. OAuth 1.0에서는 한 가지 방식의 권한 부여만 지원했다. 모든 클라이언트가 동일한 방식으로 권한을 요청하고 리소스에 접근하는 방식이었기 때문에 상황에 맞는 최적화된 권한 요청 방식을 선택할 수 없었다. OAuth 2.0에서는 Authorization Code, Implicit, Resource Owner Password Credentials, Client Credentials라는 권한 부여 방식을 도입해 다양한 시나리오에 맞는 권한 부여가 가능해지도록 했다.

OAuth 2.0 동작 메커니즘

A. 클라이언트가 리소스 소유자에게 권한을 요청한다.
B. 클라이언트는 권한 부여를 받는다. 권한 부여는 리소스 소유자의 권한을 나타내는 자격 증명으로 4가지의 권한 부여 유형이 있지만 이는 클라이언트가 권한을 요청하는 방식과 권한 서버에서 지원하는 유형에 따라 달라진다.
C. 클라이언트는 인증 서버에 인증을 하고 권한 부여를 제출하여 액세스 토큰을 요청한다.
D. 권한 서버는 클라이언트를 인증하고 권한 부여를 검증한 후 유효하면 액세스 토큰을 발급한다.
E. 클라이언트는 리소스 서버에 보호된 리소스를 요청하고 액세스 토큰을 제시하여 인증을 진행한다.
F. 리소스 서버는 액세스 토큰을 검증하고 유효하면 요청한 리소스를 제공한다.

카카오 로그인으로 살펴보는 OAuth 2.0 메커니즘

Kakao Developers 문서가 친절하고 꼼꼼하게 작성되어 있어 이해하기 쉽다.

1. 사용자 클라이언트에서 사용자가 카카오 로그인 버튼을 선택하면, 서비스는 카카오 API 플랫폼 서버로 인가 코드 발급을 요청합니다. 인가 코드는 자격 증명에 해당한다.

   // 요청 예시
   https://kauth.kakao.com/oauth/authorize?response_type=code&client_id=${REST_API_KEY}&redirect_uri=${REDIRECT_URI}

2. 카카오 API 플랫폼 서버는 사용자에게 인증을 요청하고 성공 시 사용자에게 동의 화면으로 인가를 요청한다. 사용자는 ID/PW를 제공해 리소스 소유자임을 인증하고 동의 화면을 통해 서비스에 권한을 인가한다.

3. 인가 완료 후 카카오 API 플랫폼 서버는 인가 코드를 포함한 Redirect URI로 사용자를 리다이렉트 한다.

   // 응답 예시
   HTTP/1.1 302 Found
   Content-Length: 0
   Location: ${REDIRECT_URI}?code=${AUTHORIZE_CODE}

4. 서비스가 Redirect URI에 포함된 인가 코드로 토큰 발급을 요청하면 카카오 API 플랫폼은 사용자와 서비스 앱을 연결하고 서비스에 사용자의 토큰을 발급합니다.

   // 요청 예시
   curl -v -X POST "https://kauth.kakao.com/oauth/token" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -d "grant_type=authorization_code" \
    -d "client_id=${REST_API_KEY}" \
    --data-urlencode "redirect_uri=${REDIRECT_URI}" \
    -d "code=${AUTHORIZE_CODE}"

   // 응답 예시
   HTTP/1.1 200 OK
   Content-Type: application/json;charset=UTF-8
   {
       "token_type":"bearer",
       "access_token":"${ACCESS_TOKEN}",
       "expires_in":43199,
       "refresh_token":"${REFRESH_TOKEN}",
       "refresh_token_expires_in":5184000,
       "scope":"account_email profile"
   }

5. 서비스가 발급받은 사용자의 토큰으로 사용자 정보 가져오기 API를 요청하면, 카카오 API 플랫폼 서버에서 해당 사용자의 정보를 응답합니다.

   // 요청 예시
   curl -v -G GET "https://kapi.kakao.com/v2/user/me" \
     -H "Authorization: Bearer ${ACCESS_TOKEN}"

   // 응답 예시
   HTTP/1.1 200 OK
   {
       "id":123456789,
       "connected_at": "2022-04-11T01:45:28Z",
       "kakao_account": { 
           "profile_nickname_needs_agreement": false,
           "profile": {
               "nickname": "홍길동"
           }
       },  
       "properties":{
           "${CUSTOM_PROPERTY_KEY}": "${CUSTOM_PROPERTY_VALUE}",
           ...
       }
   }

프론트와 백엔드 구현 영역

1 - 3번까지는 프론트에서 4 - 5번까지는 백엔드에서 구현했다. 사용자와 소통해서 리소스 소유자임을 인증하고 권한을 인가하는 과정은 프론트에서 진행했고 이후 토큰으로 정보를 가져오는 것은 백엔드에서 구현했다. 토큰으로 정보를 가져오는 부분까지 모두 프론트에서 구현해도 되지 않을까?라는 의문이 있었다. 하지만 인증 서버에서 토큰을 브라우저를 통해 전달하는 과정에서 데이터가 곧바로 노출될 수 있다는 위험이 있다. 이러한 보안 사고를 방지하기 위해 프론트와 백엔드의 구현을 나눴다.

보안 고려사항

Authorization Code Grant

앞에서 OAuth 2.0의 특징을 설명하며 권한 요청 방식에 대해 설명했다. Authorization Code Grant는 권한 서버로부터 인가 코드를 먼저 받고 이 코드를 이용해 권한 서버와 직접 통신하여 액세스 토큰을 교환한다. 클라이언트가 인증된 사용자를 통해 서버와 직접 통신하므로 서버 측에서 액세스 토큰을 안전하게 획득할 수 있다. 이와 비교하여 Implicit Grant 방식은 권한 서버가 액세스 토큰을 직접 클라이언트에 전달한다. 클라이언트는 이 토큰을 URL에서 파싱해 사용한다. 이때 액세스 토큰이 브라우저 URL을 통해 직접 전달되므로 토큰이 유출될 가능성이 높다. 현재 Implicit Grant 방식은 권장되지 않으며 Authorization Code Grant에 PKCE를 결합한 방식을 사용하는 것이 일반적이다. 카카오 로그인에서는 Grant Type을 authorization_code로 고정한다.

Redirect URI

클라이언트는 인가 서버에 토큰을 요청할 때 사용자 인증에 필요한 다양한 정보를 매개변수로 포함해 전송한다. 이 과정에서 Redirect URI가 검증없이 전달된 경우 공격자가 이를 악용해 악성 사이트로 리다이렉션되도록 할 수 있다. 따라서 인가 서버는 클라이언트 애플리케이션별로 명확하게 허용된 Redirect URI만을 등록하고 인가 요청을 철저히 검증해야 한다. 또한 와일드 카드 패턴의 사용은 보안 문제를 야기할 수 있으므로 사용을 최소화하여 보안성을 강화해야 한다. 카카오에서는 카카오 디벨로퍼스에 미리 등록된 값과 일치해야 기능이 정상 동작한다.

또한 OAuth 2.0에서는 보안을 위해 Redirect 앤드포인트에 TLS(Transport Layer Security)를 권장한다. TLS를 사용하지 않으면 민감한 정보가 노출될 위험이 매우 커지며 특히 OAuth를 사용해 사용자 인증을 대리 수행하는 서비스에서 보안 문제가 심각해질 수 있다. 이에 카카오는 인가 코드 및 토큰 발급 요청에 사용되는 Redirect URI는 특별한 이유가 없는 한 HTTPS를 사용하도록 강제하고 있다.

Client Secret 코드 발급

토큰 받기와 토큰 갱신하기 API 요청시 미리 발급받은 Client Secret코드를 파라미터에 포함한 경우에만 성공 응답하도록 설정하는 보안 기능이다. Client ID 외에도 인증 수단을 하나 더 추가함으로써 보안을 강화한다.

허용 IP 주소

앱 키 유출과 같은 보안 사고에 대비해 카카오 API 서버가 등록된 IP 주소의 요청만 허용하도록 설정하는 기능이다.

State 파라미터 사용

CSRF는 공격자는 사용자의 의도와는 무관하게 악의적인 요청을 서버에 보내도록 유도하는 공격 방식이다. CSRF 공격이 클라이언트의 Redirect URI를 대상으로 할 경우 공격자는 자신의 인증 코드나 액세스 토큰을 클라이언트가 사용하도록 주입할 수 있다. 이렇게 되면 클라이언트는 피해자가 아닌 공격자의 보호된 리소스와 연관된 액세스 토큰을 사용하게 될 위험이 있다.

state 파라미터를 사용해 CSRF 공격을 방지할 수 있다. 로그인을 시도하는 각 사용자의 로그인 요청에 대한 state 값을 중복되지 않는 고유한 난수로 설정하고, Redirect URI에 전달된 값과 일치하는지 검증하는 방식으로 사용한다.

📝 OpenID Connect 개념 추가 공부 예정

참고
The OAuth 2.0 Authorization Framework
OAuth 2.0 개념과 동작원리
Kakao Developers
Spring Security