[위클리 페이퍼] 세션, 토큰 기반 인증과 OAuth 2.0

이번주 위클리 페이퍼의 주제는

세션 기반 인증과 토큰 기반 인증의 차이점과 각각의 보안 고려사항에 대해 설명해보자

OAuth 2.0의 주요 컴포넌트와 Authorization Code Grant 흐름을 설명해보자

 

세션 기반 인증

세션이란?

세션(Session)은 서버 측에서 사용자의 상태 정보를 저장하는 매커니즘이다. 클라이언트는 세션 ID만 보관하고, 실제 데이터는 서버에서 관리한다.

세션 기반 인증의 흐름

1. 로그인 시 서버가 세션 생성 후 세션 ID를 클라이언트에게 쿠키로 전달
2. 이후 요청마다 쿠키에 있는 세션 ID로 인증
3. 서버는 세션 저장소에서 사용자 정보 조회

세션의 장단점

세션은 민감한 데이터가 클라이언트에게 노출되지 않아 보안성이 높고, 클라이언트는 용량이 작은 세션 ID만 저장하기 때문에 부담도 적다. 그리고 서버에서 언제든지 세션을 무효화 시킬 수 있다는 점도 장점이다.

하지만 세션 데이터를 서버에서 관리해야 하기 때문에 부하가 생길 수 있고, 여러 서버에서 세션 공유가 복잡하기에 확장성이 낮다.

 

세션 저장소는 메모리 기반과 외부 저장소 기반이 있다.

메모리 기반 세션 저장 시 빠른 접근 속도가 장점이고, 서버 재시작 시 세션이 손실된다는 점이 단점이다.

외부 저장소 기반은 데이터베이스, Redis, MongoDB 같이 외부에 저장하는 것이다.

 

토큰 기반 인증

토큰이란?

토큰(Token)은 사용자의 인증 정보와 권한을 포함한 암호화 데이터이다.

사용자가 로그인을 하면 서버는 사용자의 정보와 권한을 담은 토큰을 생성한다. 그리고 클라이언트가 서버에 요청을 할 때 헤더에 토큰을 함께 보내어 유효성 검사를 진행한다. 

토큰 기반 인증의 흐름

1. 로그인 시 서버가 JWT 같은 토큰을 발급하여 클라이언트에 전달
2. 클라이언트는 이후 요청 시 Authorization 헤더에 토큰을 첨부
3. 서버는 토큰의 서명을 검증하고 사용자 정보를 추출

토큰의 장단점

토큰은 그 자체에 사용자의 정보와 권한이 포함되어 있는 자체 포함성의 특징을 가지고 있다. 또한 인가 정보를 서버가 추적하지 않고 발급한 토큰을 클라이언트가 소지하는 방식의 무상태성(Stateless)도 가지고 있다.

 

하지만 토큰은 정보와 권한을 포함하고 있는 만큼 세션에 비해 용량이 훨씬 크다. 서버에서 인증 정보를 처리하는 세션이 토큰보다 보안 측면에서 유리하다고 한다. 그럼에도 토큰 기반 인증이 요즘 자주 사용되는 이유는 확장성 때문이라고 한다. 클라이언트가 인증 데이터를 가지고 있으니 서버에 부담도 적게 준다.

 

토큰 기반 인증의 경우 탈취될 위험이 있기 때문에 유효 기간이 짧은 액세스 토큰과 유효 기간이 긴 리프레시 토큰을 발급하여 혹여 액세스 토큰이 탈취 되어도 피해를 줄일 수 있도록 한다. 

 

OAuth란?

OAuth("Open Authorization")는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.

위키피디아에 작성되어 있는 OAuth의 정의이다.

 

현대의 웹 환경에선 다양한 외부 서비스 (페이스북, 구글, 깃허브 등)의 데이터를 여러 애플리케이션에 활용하고자 한다,

만약 접근 권한 위임이 없을 경우, 사용자가 어떤 서비스에 자신의 google drive 파일을 불러오고 싶을 때, 사용자는 google 계정의 ID와 비밀번호를 해당 서비스에 입력해야 한다. 이는 비밀번호가 제 3자에게 노출되고, 비밀번호 변경 시 연결된 모든 서비스가 끊어지게 된다. 또한 제3자 애플리케이션이 모든 권한을 위임받게 되어 과도한 접근을 허용하게 된다.

따라서 접근 권한 위임은 현대에 필수적이라고 볼 수 있다.

 

OAuth 2.0은 제3자 애플리케이션(클라이언트)이 사용자 리소스에 제한적으로 접근할 수 있게 해주는 권한 위임 프로토콜이다.

인증(Authentication)보다는 인가(Authorization)에 초점이 맞춰져 있다.

 

OAuth 2.0의 주요 컴포넌트는 아래와 같다.

출처: https://en.wikipedia.org/wiki/OAuth

Resource Owner (리소스 소유자)	일반적으로 사용자. 자신의 리소스에 대한 접근 권한을 부여함
Client (클라이언트)	리소스에 접근하려는 제3자 애플리케이션 (예시: 카카오 로그인 연동 앱)
Authorization Server (인가 서버)	사용자 인증 및 권한 부여를 담당. Access Token을 발급
Resource Server (리소스 서버)	보호된 리소스를 보관하고 Access Token을 통해 접근 허용 (예시: Google API)

 

위의 그림 중 Authorization Grant은 Access Token을 얻는 방법이다. 여러 방법이 존재하는데 아래의 표와 같다.

OAuth 2.0의 4가지 주요 인가 방식

Grant Type	설명	주요 사용 환경
1. Authorization Code Grant	가장 안전하고 일반적인 방식. 인가 코드를 통해 Access Token을 교환	서버 기반 웹 애플리케이션, SPA + PKCE
2. Implicit Grant (deprecated)	Access Token을 브라우저에서 직접 발급 (보안 취약)	예전의 순수 클라이언트 웹 앱 (현재는 사용 지양)
3. Resource Owner Password Credentials Grant	사용자 ID/비밀번호를 직접 클라이언트에 입력해서 토큰 발급	신뢰할 수 있는 클라이언트 (내부 앱 등)
4. Client Credentials Grant	사용자 없이 클라이언트 자신만 인증 (기계 간 통신)	백엔드 API 서버 간 인증, 배치 작업 등

Authorization Code Grant란?

OAuth 2.0에서 가장 널리 사용되는 인가 방식 중 하나이다.

Authorization Code Grant는 사용자 인증 이후, Authorization Code(인가 코드)를 클라이언트가 받아서, 이 코드를 서버에서 Access Token(접근 토큰)으로 교환하는 방식이다.

 

흐름을 시퀀스 다이어그램으로 나타낸 모습이다.