인증 서버 리팩토링 : OAuth 인증 시나리오와 PKCE

배경

최근 국내 서비스들에 보안 이슈가 많았다.

전사적으로 보안 점검을 진행했고, 연동 서비스의 인증 서버 역시 주요 대상이 되었다.

요청 수 제한, 애플리케이션 키 관리, 로그 마스킹, 개인정보 보관 방법 등을 점검하고 개선했다.

기능적으로는 '구글 연동 로그인'과 '2FA 강제'를 위한 추가 개발이 필요했다.

 

추가 기능을 개발하고 보안을 점검하기 위해선, OAuth 2.0으로 구현된 인증 서버를 먼저 이해해야 했다.

아래는 그 과정에서 재밌었던 부분을 정리한다.

 

OAuth 2.0 가 필요했던 이유

지금까지의 경우와는 달리, 이번엔 내가 OAuth 서버를 운영하는 입장이 되었다.

연동 서비스에서 OAuth 서버를 운영하는 이유부터 이해해야 했다.

 

연동 서비스는 삼성, LG와 같은 외부 IoT 플랫폼에서 자사 기기 연동 기능을 지원한다.

그중 인증 서버는 외부 플랫폼에서 계정을 인증하고, 제어하는 기기의 소유자가 맞는지 확인하는 역할을 한다.

 

인증을 위해 연동 플랫폼에서 사용자 ID/PW를 직접 입력받아선 안된다.

유저 정보가 외부 서비스에 직접 노출된다는 보안 문제가 있고,

이번 정책 강화처럼 2FA나 로그인 방법을 추가해야 할 때 외부 서비스에 직접 의존된다는 제어권의 문제가 생긴다.

 

OAuth는 제어 관리하는 페이지에서 유저 정보를 입력하고,

인증된 외부 사용처로 토큰을 안전하게 전달할 수 있는 틀을 제공한다.

 

대략적인 흐름

내가 이해한 OAuth의 전체 흐름은 아래 4단계이다.

처음엔 헷갈렸는데, 한 두 번 그려보니 이해된다.

 

1. 외부 클라이언트에 고유한 ID와 Secret을 발급하고, 인증 성공 후 코드를 전달받을 경로를 미리 등록한다.

2. 사용자가 로그인 페이지에서 인증에 성공하면 임시 인가 코드를 발급하고, 미리 등록된 리다이렉트 경로로 전달한다.

3. 코드를 전달받은 외부 서비스는 코드와 함께 자신의 Client ID, Client Secret을 인증 서버로 다시 제출한다.

4. 인증 서버는 이 정보들을 검증하고, 서비스 접근 토큰을 발급한다.

 

 

인증 코드 탈취 공격 / PKCE

위 처리 흐름에서도 놓칠 수 있는 위험 포인트가 남아 있다.

OAuth 서버에서 사용자로 전달한 인증 Code 코드가 탈취되는 경우이다.

이 코드가 탈취당한다면 공격자는 클라이언트 서버에 그 코드를 전달하여 토큰을 요청할 수 있게 된다.

 

이를 방어하기 위해 OAuth 코드 요청자와 토큰 요청자가 동일한지 여부를 검증하는 키를 숨겨둔다.

1. 최초 로그인 요청 시에 클라이언트 앱은 임의의 값을 앱에 저장한다.

2. OAuth 코드를 요청할 때, 이 값을 해싱하여 전달한다.

3. 후에 토큰을 요청할 때는 앞선 임의의 값을 원본으로 전달한다.

4. OAuth 서버는 똑같은 방법으로 해싱하여 전과 비교하는 것으로, 코드 요청자와 토큰 요청자가 동일한지 검증한다.

만약 해커가 해싱된 값을 탈취한다고 하더라도, 원본 값은 알 수 없으니 동일 사용자인 척하기는 것은 불가능한다.

 

이 방어 방식을 PKCE (Proof Key for Code Exchange)라고 한다.

인가 코드를 요청할 때는 해싱한 값으로 원본 값을 노출하지 않은 채 소통을 오가고,

최종적으로 토큰을 요청할 때는 원본 값을 전달하여 OAuth 서버에서 그 값을 검증하는 것으로, 두 요청자가 동일한지 증명한다.

 

정리

연동 서비스의 OAuth 인증 서버 점검 

- 보안 점검 : 요청 수 제한, 애플리케이션 키 관리, 로그 마스킹, 개인정보 보관 방법 확인 등

- 기능 개발 : 구글 연동 로그인, 2FA 강제

 

OAuth2.0 개념 학습

- 연동 서비스에서 OAuth 서버 운영이 필요한 배경

- OAuth 2.0 인증 흐름 이해

- 인증 코드 탈취 공격과 PKCE를 사용한 방어