[Weekly Paper] 세션 기반 인증과 토큰 기반 인증 비교

1️⃣ 세션 기반 인증과 토큰 기반 인증을 비교해서 설명해 주세요.

세션 기반 인증

 

작동 방식

• 사용자가 로그인하면 서버에서 사용자의 인증 정보를 확인한 뒤, 고유한 세션 ID를 생성합니다.
• 이 세션 ID는 서버에 저장되고, 사용자에게는 쿠키를 통해 전달됩니다.
• 이후 사용자가 서버에 요청을 보낼 때, 쿠키에 포함된 세션 ID를 통해 서버에서 사용자 정보를 조회하여 인증을 처리합니다.

 

특징

• 서버 저장소 필요 : 서버는 활성 세션 ID를 저장하고 관리해야 합니다.
• 상태 유지 : 세션 상태는 서버에서 유지되므로 서버는 stateful로 작동합니다.
• 쿠키 의존성 : 세션 ID는 보통 쿠키에 저장됩니다.
• 보안 : 서버에서 세션 데이터를 관리하므로 제어가 쉽지만, 세션 탈취 공격에 취약할 수 있습니다.

 

장단점

서버에서 사용자 상태를 완전히 제어할 수 있고, 세션 만료 또는 로그아웃 시 즉각적으로 무효화가 가능하지만, 서버 리소스를 많이 사용하며 확장성이 낮아 부하 분산이 어렵다고 합니다.

---

토큰 기반 인증

 

작동 방식

• 사용자가 로그인 하면 서버는 사용자를 확인한 뒤, 암호화된 인증 토큰을 생성하여 클라이언트에 전달합니다.
• 토큰을 클라이언트가 서버에 요청을 보낼 때 헤더에 포함되어 전달됩니다.
• 서버는 요청을 처리할 때 토큰을 검증하여 사용자를 인증합니다.

 

특징

• 서버 저장소 불필요 : 서버는 토큰을 저장하지 않고, 요청 시마다 검증만 수행합니다.
• 무상태 : 서버는 클라이언트의 상태를 유지하지 않습니다.
• 토큰 독립성 : 토큰은 보통 쿠키가 아닌 HTTP 헤더에 저장되며, 쿠키와 독립적으로 작동할 수 있습니다.
• 보안 : 토큰은 자체적으로 암호화되어 있으며, 만료 시간을 포함할 수 있습니다.

 

장단점

서버가 상태를 유지하지 않아 확장성이 높고, API 및 마이크로서비스 환경에 적합하며, 모바일 앱, 웹앱 모두에서 사용이 가능하지만, 토큰 만료 전까지는 서버에서 강제로 무효화하기 어렵습니다.

---

세션 기반 인증

상태를 유지해야 하거나 서버 중심의 제어가 필요한 전통적인 웹 애플리케이션에서 적합합니다.

 

토큰 기반 인증

API 중심의 애플리케이션, 마이크로서비스 아키텍처, 또는 모바일 및 SPA(Single Page Application) 환경에서 더 적합합니다.

 

특징	세션 기반 인증	토큰 기반 인증
상태 관리	서버에서 상태 유지	서버는 상태를 유지하지 않음
저장 위치	서버의 메모리/데이터베이스	클라이언트(브라우저/앱)
확장성	제한적	높음
로그아웃 처리	즉시 무효화 가능	즉시 무효화 어려움
보안	세션 탈취 위험	토큰 탈취 위험
유지 비용	서버 리소스 소모	상대적으로 서버 리소스 절약
사용 사례	전통적인 웹 애플리케이션	SPA, 모바일 앱, API 인증

 

---

2️⃣ Authorization Code를 활용하는 구글 소셜 로그인을 실행하기 까지 유저, 프론트엔드, 백엔드, OpenID Connect 프로바이더 사이에 어떤 과정을 거치는지 설명해 주세요.

1. 유저가 로그인 버튼 클릭

• 주체 : 유저, 프론트엔드
• 과정
  1. 유저는 프론트엔드의 구글로 로그인 버튼을 클릭하고
  2. 프론트엔드는 OpenID Connect 프로바이더(구글)의 인증 엔드포인트를 리디렉션합니다.

---

2. 인증 요청 전송

• 주체 : 프론트엔드 → OpenID Connect 프로바이더(구글)
• 과정
  1. 프론트엔드는 사용자를 구글의 인증 엔드포인트로 리디렉션하며, 아래와 같은 정보를 쿼리 파라미터에 포함합니다.
     • client_id : 프론트엔드가 구글 개발자 콘솔에서 발급받은 클라이언트 ID.
     • redirect_uri : 인증 완료 후 결과를 수신할 URI.
     • response_type : code (Authorization Code 요청을 명시).
     • scope : 요청할 권한(예: openid, email, profile).
     • state : CSRF 공격 방지를 위한 임의의 값.
     • nonce : 토큰 재사용 방지를 위한 임의의 값.
  2. 유저는 구글의 로그인 페이지로 리디렉션됩니다.

---

3. 유저 인증

• 주제 : 유저, OpenID Connect 프로바이더(구글)
• 과정
  1. 유저가 구글 로그인 화면에서 이메일과 비밀번호를 입력하거나 이미 로그인된 상태라면 자동으로 인증됩니다.
  2. 인증 성공 시, 구글은 프론트엔드의 redirect_uri로 Authorization Code와 state를 포함한 리디렉션을 수행합니다.

---

4. Authorization Code 수신

• 주체 : 프론트엔드
• 과정
  1. 프론트엔드는 redirect_uri를 통해 전달된 Authorization Code를 수신합니다.
  2. state 값을 검증하여 요청이 위조되지 않았음을 확인합니다.
  3. Authorization Code를 백엔드에 전달합니다.

---

5. Authorization Code 교환

• 주체: 백엔드 → OpenID Connect 프로바이더(구글)
• 과정
  1. 백엔드는 Authorization Code를 이용하여 구글의 토큰 엔드포인트에 요청을 보냅니다.
     • client_id : 클라이언트 ID.
     • client_secret : 클라이언트 시크릿(구글 콘솔에서 발급).
     • code : 프론트엔드로부터 받은 Authorization Code.
     • redirect_uri : 프론트엔드가 지정한 리디렉션 URI.
     • grant_type : authorization_code.
  2. 구글은 Authorization Code를 검증한 뒤, 아래 정보를 백엔드로 반환합니다.
     • Access Token: 구글 API 호출에 사용할 수 있는 토큰.
     • ID Token: 유저의 인증 정보가 포함된 JWT(Json Web Token).
     • Refresh Token(선택적): Access Token 갱신에 사용되는 토큰.

---

6. ID Token 검증

• 주체 : 백엔드
• 과정
  1. 백엔드 ID Token의 서명을 검증합니다.(구글의 공개 키 사용)
  2. ID Token의 payload를 확인하여 유저의 정보를 추출합니다.(유저 이메일, 이름 등)
  3. 유저의 정보를 기반으로 데이터베이스에서 기존 유저를 조회하거나, 신규 유저라면 회원가입 처리를 수행합니다.

---

7. 세션 또는 토큰 생성

• 주제 : 백엔드
• 과정
  1. 백엔드는 자체 세션을 생성하거나, 자체 Access Token 또는 Refresh Token을 발급하여 프론트엔드에 반환합니다.
  2. 프론트엔드는 이 토큰을 저장하여 이후 API 요청에 활용합니다.

---

8. 유저가 로그인 상태 유지

• 주체 : 프론트엔드, 백엔드
• 과정
  1. 프론트엔드는 백엔드 API 호출 시 저장된 토큰(Access Token 등)을 사용하여 인증된 요청을 보냅니다.
  2. 백엔드는 해당 토큰을 검증한 후 요청을 처리합니다.

---

요약

1. 유저 : 로그인 버튼 클릭 → 구글에서 인증.
2. 프론트엔드 : Authorization Code 수신 → 백엔드로 전달.
3. 백엔드 : Authorization Code로 구글에 Access Token 및 ID Token 요청 → ID Token 검증 → 유저 데이터 처리 → 토큰 또는 세션 생성.
4. OpenID Connect 프로바이더(구글) : 인증 및 토큰 발급