[oauth] OAuth 2.0의 동작원리

구글, 트위터, 페이스북 계정으로 다른 사이트에 로그인하는 것은 무척 편리하다. 하지만 편리함이 전부가 아니다. 서드 파티 사이트에 새 계정을 생성하거나 SNS 계정의 아이디, 비밀번호를 입력하는 것보다 안전하다.

 

OAuth란?

OAuth의 개념에 대해 알아보기 전에 OAuth의 동작 시나리오부터 살펴보자!
 

OAuth는 어떻게 동작할까?

구글 계정으로 서드 파티 어플리케이션 A에 로그인하는 상황을 가정하겠다. A가 구글 계정의 프로필을 사용하기 위해서는, 사전에 A가 구글 계정에 대한 접근 권한을 가지고 있어야 한다.
 
과거에는 서드 파티 어플리케이션에 구글 아이디와 패스워드를 전달해야 구글 서비스에 접근할 수 있었다. 하지만 이는 굉장히 큰 도박이다. 서드 파티 어플리케이션이 구글 계정을 악의적인 용도로 사용하지 않길 믿어야 한다. 

🥺 : 내 구글 계정 정보야. 남용하면 안돼..
😈 : 당연하지~~ (겠냐?)

반면, OAuth는 특정 자원에 대해서만 접근 권한을 부여하여 해당 문제를 해결한다.

1. A 어플리케이션은 사전에 구글로부터 두 개의 토큰을 얻어와 구글 간의 연결을 생성한다. (일종의 등록 과정!!)
2. 사용자가 A 서비스에 방문하여 `구글 계정으로 로그인` 버튼을 누르면, 구글로 리다이렉트된다.
3. 구글은 사용자에게 A 어플리케이션을 승인할지 여부를 묻고, A에게 어떤 권한을 부여하는지 알려준다. 사용자가 `승인` 버튼을 클릭하면 access token과 access token secret이 생성된다.

이처럼 OAuth는 구글 계정에 대한 모든 권한을 제공하는 대신, 특정 자원에만 접근할 수 있는 특수한 키를 제공한다. 즉, A 어플리케이션이 해킹 당하더라도 구글 비밀번호는 안전하다. 해커가 A를 이용하여 구글의 특정 자원을 이용할 수 있지만, 구글 설정에서 A 어플리케이션에 대한 접근을 취소하면 해결된다. 
 

OAuth의 장점

• 편의성 : 사용자는 각 서비스에 로그인할 필요 없이 하나의 인증 서버를 통해 여러 어플리케이션을 이용할 수 있다.
• 비밀번호 공유 방지 : 서드 파티 어플리케이션이 사용자의 실제 비밀번호를 저장하지 않는다.
• 권한 제어 : 사용자의 승인을 받은 제한된 권한만을 부여하기 때문에 서드 파티 어플리케이션이 사용자의 데이터를 마음대로 사용하는 것을 방지한다.

 

---

OAuth 2.0

OAuth는 서드 파티 어플리케이션의 접근 권한을 제한하기 위한 표준 인증 프로토콜이다.
 

Roles

OAuth에는 네 가지 역할이 존재한다. (클라이언트는 우리가 아는 클라이언트가 아니다..!!)
 

resource owner

자원의 소유자로, 자원에 접근 권한을 부여하는 주체다.
 

resource server

자원을 가지고 있는 서버로, 액세스 토큰을 바탕으로 자원 요청에 대해 응답한다.
 

client

자원에 접근하는 서드 파티 어플리케이션이다.
 

authorization server

사용자의 신원을 확인한 후, 클라이언트에게 액세스 토큰을 발급하는 서버다. 별도의 서버로 구성될 수 있고, 리소스 서버와 같은 서버에 존재할 수도 있다.

 

---

동작원리

이제 OAuth의 동작 과정에 대해 자세히 알아보자.

A & B : authorization grant 발급

클라이언트는 리소스 오너에게 자원에 대한 권한을 요청한다. 그러면 리소스 오너는 클라이언트에게 권한을 나타내는 자격 증명인 authorization grant를 전송한다.
 

C & D : access token 발급

클라이언트는 인가 서버에게 자신을 인증하고, authorization grant를 보여줘 access token의 발급을 요청한다. 인가 서버는 authorization grant을 검증한 후, access token을 발급한다.
 

E & F : 자원 접근

클라이언트는 리소스 서버에게 access token을 제시하며 자원을 요청한다. 리소스 서버는 access token을 검증하고 요청을 처리한다.
 

---

다양한 자격 증명

앞에서 나왔던 자격 증명에 대해 좀 더 자세히 알아보자.
 

authorization grant

from 리소스 오너 to 클라이언트

리소스 오너의 권한을 나타내는 자격 증명으로, 액세스 토큰을 발급 받기 위해 사용된다.
 

access token

from 인가 서버 to 클라이언트

자원에 접근할 때 사용하는 자격 증명으로, 클라이언트에게 발급된 권한을 나타내는 문자열이다. 접근할 수 있는 자원 범위와 기간에 대한 정보를 담고 있다. 리소스 서버의 보안 요구사항에 따라 다양한 형식, 구조 및 이용 방법을 가진다.
액세스 토큰은 자원에 접근할 수 있는 자격 증명이기 때문에 악의적인 사용자에게 노출되지 않도록 보안에 신경써야 한다. 이러한 보안 취약점을 최소화하기 위해 수명이 짧은 액세스 토큰을 발급하고 있다. 

refresh token

from 인가 서버 to 클라이언트

인가 서버에서 발급하는 자격 증명으로, 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 얻기 위해 사용된다. 액세스 토큰을 갱신하기 위한 용도로 사용되기 때문에 리소스 서버에 전달되지 않는다.

리프레시 토큰이 추가된 버전

액세스 토큰이 만료되면 사용자는 다시 로그인 해야 한다. 이러한 사용자 경험 저하를 방지하고자 리프레시 토큰을 사용한다. 하지만 리프레시 토큰만 있으면 언제든지 액세스 토큰을 발급 받을 수 있기 때문에 리프레시 토큰을 안전하게 보호하는 것이 중요하다.
리프레시 토큰은 액세스 토큰을 요청할 때마다 새롭게 발급된다. (refresh token rotation) 즉, 아직 유효기간이 남아있더라도 새로운 토큰으로 교체하여 재생 공격을 예방한다. 
 

---

참고자료

• https://lifehacker.com/understanding-oauth-what-happens-when-you-log-into-a-s-5918086
• https://datatracker.ietf.org/doc/html/rfc6749
• https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/