[SB 3기] 코드잇 스프린트 위클리페이퍼 13주차

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

✅ 인증이란?

인증(Authentication)이란 사용자의 신원을 확인하는 과정이다.
웹 서비스에서는 주로 로그인 기능을 통해 인증을 수행하며, 인증된 사용자는 서비스에 접근할 수 있다.

💡 물론, 인증만으로 서비스의 모든 리소스에 접근이 가능한 것은 아니다. 특정 리소스에 대한 접근은 인가(Authorization) 과정을 통해 부여된다.

✅ 세션 기반 인증

• 서버가 발급한 세션 ID를 통해 인증을 진행하는 방식이다.
• 세션 ID는 고유성, 예측 불가능, 임시성을 갖추어야 하며 서버 메모리나 데이터베이스에 저장된다.
• 클라이언트는 발급받은 세션 ID를 쿠키(Cookie)에 담아 서버에 전달하고, 서버는 해당 세션을 확인하여 인증을 유지한다.

🍪 쿠키(Cookie)란?
클라이언트와 서버 간의 상태를 유지하기 위해 사용하는 작은 데이터 조각을 뜻한다.
웹 서버가 생성하여 브라우저에 전송하고, 브라우저는 이후 요청시 해당 쿠키를 서버에 함께 전송하여 세션 정보를 식별할 수 있도록 한다.

🔓 세션 기반 인증의 보안 고려사항

• 세션 ID
  • 충분히 길고 예측하기 어려운 값을 사용해야 한다.
  • 로그인 시마다 새션 ID를 재발급해 세션 고정(Session Fixation) 공격을 방지한다.
• 쿠키 설정
  • Secure : HTTPS 연결에서만 쿠키를 전송되도록 제한한다.
  • HttpOnly : JavaScript를 통한 쿠키 접근을 차단해 XSS 공격을 방어한다.
  • SameSite : 크로스 사이트 요청 시 쿠키 전송을 제어하여 CSRF 공격을 방어한다.
• 세션 만료 정책
  • 일정 시간 사용하지 않으면 세션을 만료시켜 세션 탈취 후 장기 사용을 방지한다.

✅ 토큰 기반 인증

• 서버가 발급하는 토큰(Token)을 사용해 인증을 진행하는 방식이다.
• 토큰은 사용자의 인증 정보와 권한을 포함한 디지털 자격 증명으로, 서버가 상태를 저장하지 않는 Stateless 구조를 가진다.

📌 토큰의 특징

• 자체 포함성 (Self-contained) : 토큰 자체에 인증 및 권한 정보 포함
• 무상태성 (Stateless) : 서버에서 세션 상태를 관리하지 않음
• 이식성 (Portability) : 여러 서비스와 도메인에서 공통 사용 가능

🔓 토큰 기반 인증의 보안 고려사항

• Refresh Token 보호
  • HttpOnly, Secure, SameSite 설정으로 XSS·CSRF 방어
• 토큰 순환 (Token Rotation)
  • Refresh Token 사용 시 새 토큰 발급, 기존 토큰은 즉시 무효화
  • 재사용 감지 시 전체 토큰 폐기 및 강제 재로그인
• 만료 시간 설정
  • 토큰 탈취 피해를 최소화하기 위해 적절한 만료 시간 설정
  • ⭐️ Access Token은 짧은 만료 시간으로 설정
• 서명 검증!
  • 토큰의 서명(Signature)을 검증해 변조 여부 및 무결성 확인

⚠️ Refresh Token은 일반적으로 긴 만료 시간을 갖기 때문에 탈취 시 장기간 악용될 수 있다. 따라서 매우 민감하게 관리해야 한다.

🆚 세션 기반 인증과 토큰 기반 인증의 차이점

구분	세션 기반 인증	토큰 기반 인증
상태 관리	서버가 세션 상태를 저장 (Stateful)	서버는 상태를 저장하지 않음 (Stateless)
확장성	서버 간 세션 공유 필요 → 확장성 낮음	상태가 없으므로 서버 확장 용이
저장소	서버 메모리/DB	클라이언트 측에서 토큰 관리
인증 속성	세션 ID 기반	토큰 자체에 인증 및 권한 정보 포함
보안 포인트	세션 ID 탈취 방지, 쿠키 설정, 세션 만료 정책 설정	토큰 탈취 방지, 서명 검증, 저장 위치 및 만료 관리

---

Q. OAuth 2.0의 주요 컴포넌트와 Authorization Code Grant 흐름을 설명하세요.

✅ OAuth란?

• OAuth(Open Authoriazation)란 사용자가 비밀번호를 직접 제공하지 않고도 다른 서비스(구글, 네이버 등)에 저장된 개인 정보에 대하여 제한된 접근 권한을 제3자 애플리케이션에 위임할 수 있도록 하는 표준 프로토콜이다.

예시 : Velog에서 GitHub, Google, Facebook 계정으로 로그인할 수 있는 소셜 로그인 기능

📌 특징

• 토큰 기반 인증/인가 프로토콜이다.
• 비밀번호 노출 없이 권한을 안전하게 위임할 수 있다.
• Scope(권한 범위)를 통해 애플리케이션이 접근할 수 있는 리소스를 제한할 수 있다.

✅ OAuth 2.0

• 현재 가장 널리 사용되는 표준으로, 이전 버전보다 단순한 구조와 다양한 인증 방식을 지원한다.
• Access Token과 Refresh Token 개념을 도입해 더욱 안전하고 유연한 인증/인가를 제공한다.
• 모바일 앱, 웹 애플리케이션, 서버 간 통신 등 다양한 환경에서 활용된다.

📌 OAuth 2.0의 주요 컴포넌트

• OAuth 2.0은 네 가지 핵심 주체로 이루어져있다.

구분	역할	설명	예시
Resource Owner (리소스 소유자)	리소스 소유자	자신의 리소스에 대한 접근을 허용할지 결정	내 구글 계정 정보의 소유자인 "나"
Client (클라이언트)	제3자 앱	사용자를 대신해 리소스에 접근	Velog, Notion 등
Authorization Server (인가 서버)	인증/토큰 발급	사용자 인증 후 Access Token 발급	Google Authorization Server
Resource Server (리소스 서버)	리소스 제공	데이터(API)를 제공하고 Access Token 검증	Google API Server

🌊 Authorization Code Grant 흐름

• Authorization Code Grant은 권한 부여 승인 코드 방식을 뜻하며, OAuth 2.0에서 가장 널리 사용되는 승인 방식이다.
• 인가 서버에서 발급한 Authorization Code(승인 코드)를 통해 Access Token을 발급받는 방식이다.
  

1️⃣ 권한 부여 요청

• 클라이언트는 사용자의 브라우저를 인가 서버로 리다이렉션하여 Client ID, Redirect URI 등을 함께 전달한다.
• 사용자의 브라우저는 인가 서버에 로그인 페이지를 요청하고, 인가 서버는 로그인 화면을 제공한다.
• 사용자는 로그인 후 애플리케이션이 요청하는 권한(Scope)에 동의한다.

2️⃣ Authorization Code 발급

• 인가 서버는 사용자의 브라우저를 통해 클라이언트의 Redirect URI로 Authorization Code(승인 코드)를 전달한다.

3️⃣ Access Token 요청

• 클라이언트는 받은 Authorization Code와 함께 자신의 Client ID/Secret을 인가 서버로 전달하여 Access Token을 요청한다.

4️⃣ Access Token 발급

• 인가 서버는 클라이언트의 정보를 검증한 후 Access Token을 발급한다. (+필요 시 Refresh Token도 함께 발급)

5️⃣ 리소스 요청

• 클라이언트는 Access Token을 이용해 리소스 서버에 보호된 리소스를 요청한다.

6️⃣ 리소스 제공

• 리소스 서버는 Access Token의 유효성을 검증한 후 클라이언트에게 요청된 리소스를 제공한다.

이 외에도 Implicit Grant, Resource Owner Password Credentials Grant, Client Credentials Grant 등 다양한 승인 방식이 있다.

---

📄 참고문서

• 코드잇 강의 자료
• OAuth 2.0 개념 - 그림으로 이해하기 쉽게 설명
• OAuth 2.0 개념 총 정리