OAuth 2.0 구성요소와 플로우: JWT 연계

임채령·2024년 10월 28일

최근 프로젝트에서 Payco OAuth 2.0을 구현했었는데 직접 구현했던 기술이 아니라서 OAuth 2.0에 대해 아주 간단하게만 알고있었다. 하지만 지금 사이드 프로젝트에서 OAuth 2.0을 사용한 카카오, 구글 소셜 로그인 및 자체 회원가입을 구현해야한다. 워낙 관심이 많았던 부분이기도 했기에 OAuth 2.0을 알아보고 이어서 JWT와 접목시켜서도 포스팅 해보려한다 !

간단한 OAuth2.0에 대한 내용은 벨로그에 포스팅해뒀으니 참고하면 될거같습니다 !

OAuth를 이겨보자 !!

이번 포스팅에서는 다음 목차로 이루어져있다.

OAuth 2.0을 구성하는 주요 엔티티
OAuth 2.0에서 로그인이 되는 플로우
OAuth 2.0에서의 토큰 관리
OAuth 인증 후 JWT 활용방법

시작!!

OAuth 2.0의 주요 엔티티

OAuth 2.0에서 주요하게 다루는 역할들은 각기 다른 기능을 가지고 있으며, 이들의 상호작용이 전체 로그인 플로우를 이끌어간다.

Resource Owner (자원 소유자)
- 사용자로서, 자신의 데이터에 대한 접근 권한을 가지고 있는 사람을 의미
- 예를 들어, 구글 계정 사용자나 페이스북 사용자 등이 자원 소유자가 된다. 자원 소유자는 자신이 소유한 데이터를 타사 애플리케이션에 접근할 수 있도록 권한을 부여할 수 있다.
Client (클라이언트 애플리케이션)
- 사용자 대신 자원 서버에 접근하려고 하는 애플리케이션
- 예를 들어, 사용자가 구글 계정을 이용해 로그인하려는 외부 앱이나 웹사이트이다. 클라이언트는 자원 소유자로부터 데이터 접근 권한을 받아 데이터를 요청한다.
Authorization Server (인증 서버)
- 클라이언트의 자격을 검증하고, Access Token(액세스 토큰)을 발급하는 서버
- 예를 들어, 구글의 로그인 페이지에서 사용자 인증을 처리한 후, 클라이언트에게 액세스 토큰을 제공하는 서버가 이에 해당한다.
Resource Server (자원 서버)
- 사용자의 데이터를 저장하고 있는 서버로, 클라이언트가 접근하려고 하는 실제 리소스를 관리
- 예를 들어, 구글의 API 서버가 자원 서버로서 사용자의 이메일, 연락처 등의 데이터에 대한 접근을 제공

이제 각 역할을 설명한 상태에서 OAuth 2.0의 로그인 플로우를 다시 정리해보겠다 !!

OAuth 2.0에서 로그인 되는 플로우

OAuth 2.0의 로그인 과정은 기본적으로 사용자(자원 소유자)가 자신의 자원에 대한 접근을 제3의 애플리케이션(클라이언트)에게 위임하는 방식으로 이루어진다. 밑의 이미지는 참고하면 좋을거같습니다 !

1. 사용자 로그인 요청 및 리다이렉트

Resource Owner(사용자)는 Client(클라이언트 애플리케이션)을 사용하여 로그인을 시도
- 예를 들어, 사용자가 웹사이트에서 "구글로 로그인" 버튼을 클릭
Client는 사용자를 Authorization Server(인증 서버)로 리다이렉트하여 사용자가 인증하도록 유도
- 이때 클라이언트는 인증 서버에게 client_id, redirect_uri, scope, response_type=code 등의 정보를 전달하여 요청을 시작

근데 여기서 client_id, redirect_uri, scope, response_type=code 는 무엇일까 ?

client_id: 어떤 앱이 요청하는지 알려주는 아이디
redirect_uri: 로그인 후 사용자를 되돌려 보낼 주소
scope: 앱이 어떤 정보에 접근하려고 하는지 범위를 지정
response_type=code: 인증 코드를 받아서 나중에 액세스 토큰을 요청하기 위해 사용하는 코드

2. 사용자의 인증 및 승인

사용자는 Authorization Server(인증 서버)의 인증 페이지에서 자신의 자격 증명을 입력하고, 애플리케이션이 요청한 데이터에 대한 접근 권한을 부여
인증이 완료되면, Authorization Server는 Authorization Code (인증 코드)를 생성하여 Client의 리다이렉트 URI로 전달
- 예를 들어, 구글의 경우 사용자가 계정 정보로 로그인하면 인증 서버는 인증 코드를 생성하여 클라이언트에게 전달

3. 인증 코드로 토큰 요청

Client는 Authorization Server의 토큰 엔드포인트에 인증 코드를 포함하여 Access Token (액세스 토큰)을 요청
- 요청 시에는 client_id, client_secret, code, redirect_uri 등의 정보가 포함
- 인증 서버는 이를 확인하여 유효한 인증 코드라면 액세스 토큰과 Refresh Token을 클라이언트에게 발급

4. 액세스 토큰으로 자원 요청

Client는 발급받은 Access Token을 사용해 Resource Server의 API에 접근하여 사용자 데이터를 요청
- 예를 들어, 사용자의 이메일 정보를 얻기 위해, 클라이언트는 구글 API의 리소스 서버에 액세스 토큰을 포함하여 요청을 보다.
Resource Server는 액세스 토큰을 검증하고, 유효하다면 클라이언트에게 요청한 자원을 제공

5. 클라이언트와 사용자 간 상호작용

Client는 Resource Server로부터 받은 데이터를 바탕으로 사용자에게 서비스나 기능을 제공
예를 들어, 클라이언트는 사용자의 이메일 주소를 받아 이를 화면에 표시하거나, 다른 서비스를 제공할 수 있다.

각 엔티티 간의 연결

사용자(Resource Owner)는 자신의 구글 계정 정보로 애플리케이션에 로그인하며, 인증 및 승인을 통해 클라이언트(Client)에게 데이터를 접근할 수 있는 권한을 부여
클라이언트(Client)는 사용자의 요청에 따라 Authorization Server로부터 인증을 받고, 이후 Access Token을 사용해 Resource Server에 접근
Authorization Server는 클라이언트의 자격을 확인하고, 유효한 경우 Access Token과 Refresh Token을 발급
Resource Server는 Access Token을 검증하여 데이터 접근을 허용하거나 거부

엔드포인트 개요

Authorization Endpoint (인증 엔드포인트): 사용자가 로그인하고 승인하는 과정에서 호출되는 엔드포인트
- 예: https://accounts.google.com/o/oauth2/auth
Token Endpoint (토큰 엔드포인트): 인증 코드나 리프레시 토큰을 사용하여 Access Token을 발급받기 위해 호출하는 엔드포인트
- 예: https://oauth2.googleapis.com/token
Resource Endpoint (자원 엔드포인트): Access Token을 사용하여 자원 서버에 접근하기 위한 엔드포인트
- 예: https://www.googleapis.com/gmail/v1/users/me/messages

OAuth 2.0에서의 토큰 관리

OAuth 2.0의 토큰 관리는 두 가지 중요한 토큰인 액세스 토큰과 리프레시 토큰을 사용해 이루어진다. 각 토큰의 역할과 사용 전략이다 !

1. Access Token (액세스 토큰)

역할: 클라이언트는 액세스 토큰을 Resource Server의 API에 포함하여 요청을 보내며, 서버는 이를 통해 사용자의 인증을 확인하고 요청한 데이터를 제공
수명: 액세스 토큰은 보안상의 이유로 유한한 수명을 가지며, 일반적으로 몇 분에서 몇 시간 동안만 유효합니다.

2. Refresh Token (리프레시 토큰)

역할: 클라이언트는 리프레시 토큰을 사용해 Authorization Server로부터 새로운 액세스 토큰을 발급받아 지속적인 데이터 접근을 유지
수명: 리프레시 토큰은 액세스 토큰보다 더 긴 수명을 가지며, 보통 사용자가 로그아웃하지 않는 한 유효하게 유지된다.

OAuth에서 JWT 사용 사례

OAuth 2.0에서 Access Token을 JWT 형식으로 발급하면, 토큰 자체에 인증 정보가 포함
이를 통해 서버는 추가적인 데이터베이스 조회 없이 JWT의 서명을 검증하여 사용자의 신원을 확인
JWT는 자체적으로 서명되어 있기 때문에 Resource Server는 별도의 Authorization Server와 통신하지 않고도 토큰의 유효성을 확인할 수 있다. 이로 인해 서버 간 의존성을 줄이고 성능을 향상시킬 수 있다.

OAuth 인증 후 JWT 활용

사용자가 OAuth 인증을 통해 Access Token을 발급받은 후, Client는 이 JWT를 사용하여 보호된 리소스에 접근
클라이언트는 보호된 자원을 요청할 때 HTTP 요청 헤더에 JWT를 포함하여 전송
```
Authorization: Bearer {JWT}
```

OAuth 2.0에서는 제공자의 엑세스 토큰을 발급하여 사용자의 정보를 가져오는 데 사용한다. 이 엑세스 토큰은 Google, Kakao 등 제공자의 서버에서 사용자 정보를 조회하기 위한 용도로만 사용되며, 내 서버에서 직접 인증과 권한 부여를 위해 사용할 수는 없다. 내 서버는 이 엑세스 토큰을 사용해 사용자 정보를 가져온 후, 해당 사용자가 기존 사용자라면 사용자 정보를 바탕으로 내가 직접 구현해놓은 JWT 토큰을 발급한다. 만약 사용자가 처음 로그인한 경우라면, 새로운 사용자를 생성하고 JWT 토큰을 발급하는것이다. 최종적으로 발급된 내 서버의 JWT 토큰은 이후 사용자 요청을 인증하고 권한을 부여하는 데 사용된다.

OAuth 2.0에서 발급하는 JWT 토큰은 카카오나 구글 같은 제공자의 서버에서 사용자 정보를 가져오기 위한 용도이다. 이 토큰을 사용해 사용자의 정보를 가져오고, 내 서버에서 이 정보를 바탕으로 사용자 조회를 진행한 뒤, 내 서버에서 사용할 JWT 토큰을 새로 발급해주는 것이다. 즉, OAuth 제공자의 토큰은 사용자 정보 접근에만 사용하고, 이후 인증과 권한 부여는 내가 발급한 JWT 토큰을 사용하게 된다.

즉, OAuth 2.0을 인증했을때 나오는 JWT토큰과 내 서버에서 로그인했을때 발급해주는 토큰은 다른 것이다 !