위클리 페이퍼 - 13주차

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

세션이란?

클라이언트가 서버에 접속한 순간부터 접속을 끊을 때까지의 연결 상태 -> 서버가 기억하는 "사용자의 임시 신분증"

세션의 특징

• 서버 중심 관리 : 사용자의 로그인 여부, 권한, 장바구니 정보 등을 서버가 직접 보관
• 클라이언트는 세션 ID만 보관 : 브라우저는 세션 자체가 아니라, 세션을 가리키는 고유 ID를 쿠키에 저장
• 만료 가능 : 일정 시간 동안 요청이 없으면 세션을 종료하거나 최대 사용 시간을 설정할 수 있음
• 보안 의존성 : 세션 ID가 유출되면 사용자 정보가 탈취될 수 있음. 따라서 세션 ID를 안전하게 보호하는 것이 핵심

항목	설명
저장 위치	서버 (메모리, DB, Redis 등)
클라이언트 역할	세션 ID를 쿠키에 저장하여 요청마다 전달
만료 관리	TTL(Time-to-Live), 유휴/절대 타임아웃
보안 이슈	세션 ID 탈취, 세션 고정(Session Fixation) 공격

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

1. 세션 ID 보안
   • 랜덤성 : 세션 ID는 충분히 긴 난수를 사용해야 함
   • 예측 불가능성 : 단순 증가하는 숫자나 시간 기반 ID는 공격자가 쉽게 추측할 수 있으므로 금지
   • 쿠키 보안 속성 : Secure, HttpOnly, SameSite
   • 고유성 보장 : 동일한 세션 ID가 동시에 재발급되지 않도록 보장
2. 세션 만료 정책
   • 유휴 타임아웃 : 일정시간 요청이 없으면 세션을 자동 만료
   • 절대 타임아웃 : 세션이 생성된 지 일정 시간이 지나면 무조건 만료
   • 강제 로그아웃 : 관리자가 특정 사용자의 세션을 강제로 만료
3. 세션 고정 방지
   • 문제점: 공격자가 미리 발급받은 세션 ID를 피해자에게 강제로 사용하게 하면, 로그인 후에도 공격자가 동일한 세션을 이용할 수 있음
   • 대책 : 
     • 로그인 성공 시 새로운 세션 ID를 무조건 재발급
     • 권한 상승 시에도 세션 ID를 다시 생성
4. 로그아웃 처리
   • 서버 측 세션 무효화 : 세션 저장소에서 해당 세션 ID 삭제
   • 클라이언트 쿠키 만료 지시 : Max-Age=0 또는 Expires 속성을 이용해 브라우저 쿠키를 제거
   • 즉시 반영 : 로그아웃 요청 시 즉시 세션이 무효화되어야 하며, 남아있는 요청이 더 이상 인증되지 않아야 함

항목	설명
세션 ID 보안	에측 불가한 난수 + Secure, HttpOnly, SameSite 속성
만료 정책	유휴 타임아웃 + 절대 타임아웃 병행
세션 고정 방지	로그인/권한 상승 시 세션 ID 발급
로그아웃 처리	서버 세션 무효화 + 쿠키 만료 지시
추가 고려사항	동시 세션 제어, 세션 하이재킹 탐지, 로깅/모니터링

토큰이란?

서버(또는 권한 서버)가 발급하는 증표로, 클라이언트가 요청마다 제출하면 누구인지와 무엇을 할 수 있는지를 판단하는 데 쓰임

특정 리소스에 대한 접근 권한을 부여하는 것

토큰의 특징

• 토큰에 포함된 인증 정보는 서버가 별도로 상태를 저장하지 않음
• 생성된 토큰을 HTTP Authorization 헤더에 담아 전송
• 토큰 안에 사용자 정보가 포함되므로, 세션에 비해 네트워크 트래픽이 많을 수 있음
• 서버는 토큰 자체를 관리하지 않으므로, 보안성 측면에서 더 신중한 설계가 필요
• 인증 상태를 서버에 저장하지 않기 때문에 확장성(Scalability) 면에서 매우 유리
• 토큰 유출 시 위험: 토큰은 암호화되지 않은 사용자 정보를 포함할 수 있으므로, 민감한 정보는 토큰에 넣지 않아야 함
• 토큰은 만료되기 전까지는 기본적으로 무효화가 불가능
• CSR(Client Side Rendering) 방식의 애플리케이션에 적합

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

1. 짧은 Access + 회전형 Refresh
   • Access 5–15분, Refresh는 길게.
   • Refresh 토큰은 회전(Rotation): 재발급 시 이전 RT 즉시 폐기(재사용 감지).
2. 안전한 저장·전달
   • 브라우저: 가능하면 HttpOnly + Secure 쿠키(로컬/세션스토리지 지양) + SameSite 설정.
   • 네이티브 앱: OS 보안 스토리지(Keychain/Keystore).
   • 전 구간 TLS 필수.
3. 엄격한 검증 & 키 관리
   • alg=none 금지, 허용 알고리즘 화이트리스트.
   • JWKs + kid로 키 롤오버 운영.
   • iss/aud/exp/nbf/iat 등 클레임 철저 검증(+ 시계 오차 허용).
4. 무효화 전략
   • 즉시 폐기가 중요하면 Opaque 토큰 + 인트로스펙션 또는 블랙리스트.
   • JWT만 쓴다면 짧은 만료 + RT 회전으로 피해 범위 최소화(디바이스별 토큰 종료 UI 제공).
5. XSS/CSRF 대응(전송 방식별)
   • 쿠키 전송: CSRF 토큰 + SameSite + Origin/Referer 검증.
   • 헤더 전송(Bearer): CSRF 위험↓ 대신 CSP·입력검증·출력인코딩으로 XSS 방어 강화.

나만의 언어로 정리해보기

세션 기반 인증
세션이란?
- 클라이언트가 서버에 접속한 순간부터 접속을 끊을 때까지의 연결 상태 (사용자의 임시 신분증)

특징
- 서버 중심 관리 : 권한 등을 서버가 직접 보관
- 클라이언트는 세션 ID만 보관 : 브라우저는 세션을 가리키는 고유 ID를 쿠키에 저장
- 만료 가능 : 최대 사용 시간을 설정하거나 일정 시간동안 요청이 없으면 세션을 종료
- 보안 의존성 : 세션 ID가 유출되면 사용자 정보가 탈취될 수 있다.

보안 고려 사항
 - 세션 ID 보안
 - 세션 만료 정책
 - 세션 고정 방지
 - 로그아웃 처리

토큰 기반 인증
토큰이란?
- 특정 리소스에 대한 접근 권한을 부여하는 것으로, 클라이언트가 요청마다 제출하면 누구인지와 무엇을 할 수 있는지 판단하는데 쓰임

특징
 - 토큰에 포함된 인증 정보는 서버가 따로 저장하지 않는다.
 - 생성된 토큰을 HTTP Authorizaion 헤더에 담아 전송한다.
 - 세션에 비해 네트워크 트래픽이 많을 수 있다.
 - 보안성 측면에서 더 신중한 설계가 필요하다.
 - 확장성 면에서 매우 유리하나, 토큰 유출 시 위험하다.

보안 고려 사항
 - 짧은 Access + 회전형 Refresh
 - 안전한 저장·전달
 - 엄격한 검증 & 키 관리
 - 무효화 전략
 - XSS/CSRF 대응

 

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

OAuth 2.0의 주요 컴포넌트

1. 리소스 소유자 (Resource Owner)
   : 보호된 리소스(데이터)의 주인인 최종 사용자
   • ex) Google 계정을 소유한 사용자
2. 클라이언트 (Client)
   : 리소스 소유자를 대신하여 보호된 리소스에 접근을 요청하는 제3자 애플리케이션
   • ex) Google 캘린더 일정을 연동하려는 캘린더 앱
3. 권한 서버 (Authorization Server)
   : 리소스 소유자를 인증하고, 클라이언트에게 접근 토큰(Access Token)을 발급해주는 서버
   • ex) 사용자의 ID와 비밀번호를 확인하고 로그인 동의 화면을 제공하는 Google의 인증 시스템
4. 리소스 서버 (Resource Server)
   : 보호된 리소스를 호스팅하는 서버, 클라이언트로부터 접근 토큰을 받아 유효성을 검증한 후, 요청된 리소스를 제공
   - ex) 사용자의 캘린더 데이터, 프로필 정보를 실제로 저장하고 있는 Google API 서버
   
   

Authorization Code Grant

• OAuth 2.0에서 가장 표준적이고 안전한 권한 부여 방식으로, 주로 서버 사이드 애플리케이션(웹 애플리케이션)에서 사용됨
• 클라이언트가 접근 토큰을 직접 받지 않고, 중간 단계에서 임시 승인 코드(Authorization Code)를 발급받아 보안을 강화하는 방식

권한 부여 승인 코드 흐름 (Authorization Code Grant Flow)

1. 권한 부여 요청

• (사용자 → 클라이언트): 사용자가 앱에서 'Google 캘린더로 로그인' 버튼 클릭
• (클라이언트 → 사용자 에이전트(브라우저)): 클라이언트는 사용자의 브라우저를 Google(권한 서버)의 로그인 페이지로 리디렉션시킴. 이때 URL에는 다음과 같은 중요한 정보들이 쿼리 파라미터로 포함됨
  • response_type=code: 권한 부여 승인 코드를 요청한다는 의미
  • client_id: 클라이언트가 사전에 Google에 등록하고 발급받은 고유 식별자
  • redirect_uri: 권한 부여 후 Google이 사용자를 다시 돌려보낼 클라이언트의 주소
  • scope: 클라이언트가 요청하는 권한의 범위
  • state: CSRF 공격을 방지하기 위해 클라이언트가 생성하는 임의의 문자열

2. 사용자 인증 및 동의

• (사용자 → 권한 서버): 사용자가 Google 로그인 페이지에서 자신의 ID와 비밀번호를 입력하여 본인임을 인증
• (권한 서버 → 사용자): 인증이 완료되면 권한 서버는 앱이 요청한 권한(ex. 캘린더 읽기 권한) 목록을 보여주며, 사용자에게 이 권한을 허용할 것인지 묻는 동의 화면을 제시

3. 승인 코드 발급 (Authorization Code Grant)

• (사용자 → 권한 서버): 사용자가 동의 버튼을 클릭
• (권한 서버 → 클라이언트): 권한 서버는 미리 지정된 redirect_uri로 사용자의 브라우저를 다시 돌려보냄. 이때 URL에는 임시 승인 코드(Authorization Code)와 이전에 받았던 state 값이 포함되어 있음
  • 승인 코드: 수명이 짧은 일회성 코드

4. 접근 토큰 요청

• (클라이언트 → 권한 서버): 클라이언트의 백엔드 서버는 방금 받은 승인 코드를 사용하여 권한 서버의 토큰 엔드포인트(Token Endpoint)로 직접 요청을 보냄. 이 요청은 사용자의 브라우저를 거치지 않는 서버 간 통신(Back-channel)으로 이루어지므로 보안에 더 안전하며 요청 본문에는 다음 정보가 포함됨
  • grant_type=authorization_code: 승인 코드를 사용하여 토큰을 요청한다는 의미
  • code: 3단계에서 전달받은 승인 코드
  • redirect_uri: 1단계에서 보냈던 redirect_uri와 동일한 값(보안 검증용)
  • client_id, client_secret: 클라이언트의 자격 증명 정보

5. 접근 토큰 발급

• (권한 서버 → 클라이언트): 권한 서버는 전달받은 승인 코드, client_id, client_secret 등을 모두 검증한 후, 모든 정보가 유효하면 접근 토큰(+필요한 경우 갱신 토큰도 함께 발급)을 클라이언트에게 발급함
  • 갱신 토큰(Refresh Token): 접근 토큰이 만료되었을 때, 사용자 재인증 없이 새로운 접근 토큰을 요청하는 데 사용하는 토큰

6. 리소스 접근

• (클라이언트 → 리소스 서버): 클라이언트는 발급받은 접근 토큰을 HTTP 요청의 Authorization 헤더에 담아 Google API(리소스 서버)로 보냄
  • Authorization: Bearer [Access_Token]
• (리소스 서버 → 클라이언트): 리소스 서버는 해당 접근 토큰이 유효한지 확인 후, 유효하면 클라이언트가 요청한 리소스(ex. 사용자의 캘린더 일정)를 응답으로 제공

나만의 언어로 정리해보기

OAuth 2.0의 주요 컴포넌트
1. 리소스 소유자
2. 클라이언트
3. 권한 서버
4. 리소스 서버

Authorization Code Grant Flow
1. 권한 부여 요청
2. 사용자 인증 및 동의
3. 승인 코드 발급
4. 접근 토큰 요청
5. 접근 토큰 발급
6. 리소스 접근