8월_1주차. 세션과 토큰 기반 인증, QAuth 2.0

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

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

1. 세션 기반 인증, 토큰 기반 인증

- 1_1) 세션 기반 인증

(1) 사용자가 로그인하면, 서버가 세션을 생성하고, 그 세션에 인증 상태를 저장하는 방식

서버는 세션을 식별할 수 있는 세션 ID를 브라우저의 쿠키에 담아 클라이언트에 전달

이후 클라이언트는 요청마다 이 id를 쿠키에 담아 서버에 전송하고, 서버는 이를 기반으로 로그인 여부를 확인

 

(2) 보안 고려사항

- 세션 하이재킹 위험: 쿠키가 탈취되면 공격자가 동일 세션으로 접근 가능

  >> HttpOnly, Secure, SameSite 옵션을 적용하여 완화할 수 있음

- CSRF(Cross-Site Request Forgery) 공격: 쿠기 자동 전송 특성으로 CSRF에 취약

  >> CSRF 토큰 사용으로 방지

- 세션 무효화 처리 필요: 로그아웃이나 비정상 종료 시 서버에서 세션을 명확히 만료시켜야 함

 

 

*HttpOnly: 웹브라우저에서 쿠키를 자바스크립트로 접근할 수 없게 만드는 속성으로
XSS 공격으로 쿠키 탈취를 방지
→ 브라우저에서 document.cookie로 접근 불가능

*Secure: 쿠키가 HTTPS(암호화된 통신) 연결에서만 전송되도록하는 속성으로,
네트워크에서 평문 전송으로 쿠키 탈취되는 것 방지
→ HTTP 요청에서는 해당 쿠키가 전송되지 않음

*SameSite: 쿠키가 다른 도메인에서 발생한 요청에 대헤 어떻게 전송될지 제어하는 속성
- Strict: 같은 사이트 요청에서만 쿠키 전송 (가장 안전)
- Lax: 일부 크로스사이트 요청(GET 링크 클릭)에는 허용, POST 등은 차단
- None: 모든 크로스사이트 요청에서 쿠키 전송 (반드시 Secure와 함께 사용)
- CSRF(Cross-Site Request Forgery) 공격 완화 목적

*CSRF: 사용자가 의도하지 않은 요청을 공격자가 강제로 보내게 하여
사용자의 권한으로 악의적인 요청을 실행시키는 공격
- 예시: 로그인 상태에서 공격자가 만든 링크를 클릭 → 피해자의 세션으로 계정 정보 변경 요청 발생
- 방지 방법
1) CSRF Token 사용: 서버가 폼이나 요청에 난수 토큰을 발급하고 요청 시 검증
2) SameSite 쿠키 사용: 크로스사이트 요청에 쿠키가 자동으로 안 가도록 설정

 

 

 

 

 

- 1_2) 토큰 기반 인증

(1) 토큰 기반 인증은 로그인 성공 시 서버가 토큰(JMT 등)을 발급하고,

클라이언트가 이를 저장해두었다가 요청 시 헤더에 담아 서버에 전달하는 방식

서버는 토큰 자체를 검증하여 인증 여부를 판단하며, 별도의 세션 상태를 저장하지 않아 무상태 방식으로 동작

*무상태 방식(Stateless): 서버가 클라이언트의 이전 요청 상태를 저장하지 않고,
각 요청을 독립적으로 처리하는 아키텍쳐 스타일
토큰 기반 인증과의 관계)
	1) 토큰 기반 인증(JWT 등)은 토큰 자체에 인증 정보를 포함하므로,
    서버가 별도로 세션 상태를 보관할 필요가 없음
    2) 서버 확장(스케일 아웃)이 쉬워짐 
    >> 어떤 서버가 요청을 처리해도 같은 결과 반환 가능

 

(2) 보안 고려사항

- 토큰 탈취 위험: 탈취 시 누구나 접근 가능

 >> HTTPS 사용 필수, 민감한 정보는 토큰에 직접 포함하지 않음

- 만료 및 폐기 관리: 토큰 발급 후 강제 만료가 어려움

 >> 짧은 만료시간 설정 + Refresh Token 전략 사용

- 저장 위치 보안: 로컬스토리지에 저장 시 XSS에 노출될 수 있음

 >> 가능한 HttpOnly Cookie를 사용해 보관

- 서명 검증: 토큰 위, 변조 방지를 위해 서버는 항상 서명을 검증해야함

 

1_3) 세션 기반 인증과 토큰 기반 인증의 차이점

구분	세션 기반 인증	토큰 기반 인증
상태 관리	서버가 세션 상태를 직접 저장(상태 유지)	서버는 상태를 저장하지 않음(무상태)
확장성	서버 간 세션 공유 필요, 부하분산 시 복잡	토큰만 검증하면 되므로 서버 확장 용이
보안 취약점	세션 하이재킹, CSRF 공격에 상대적으로 취약	토큰 탈취, XSS 공격에 주의 필요
만료 관리	서버가 세션을 강제로 무효화 가능	토큰은 발급 후 강제 폐기가 어려움
저장 위치	브라우저 쿠키	로컬스토리지, 세션스토리지, 쿠키 등

 

 

2. QAuth 2.0 

- 2_1) OAuth 2.0의 주요 컴포넌트

: 제3자 애플리케이션이 사용자 자원을

직접적인 인증정보(아이디/비밀번호) 없이 접근할 수 있게 해주는권한 위임 프로토콜

 

- Resource Owner(리소스 소유자): 자신의 자원 접근 권한을 다른 애플리케이션에 위임하는 사용자

- Client(클라이언트 애플리케이션): 사용자 대신 API에 접근하는 애플리케이션

- Authorization Server(인가 서버): 인증을 수행하고 Access Token을 발급하는 서버

- Resource Server(리소스 서버): 보호된 자원을 호스팅하는 서버

- Access Token / Refresh Token: 인증 후 발급되는 자격 증명, API 요청 시 사용

 

- 2_2) Authorization Code Grant 흐름

OAuth 2.0 에서 가장 안전한 권한 부여 방식으로 

사용자의 자격 증명을 직접 노출하지 않고 인가 코드를 통해 Access Token을 발급 받음

1. 사용자 인증 요청
	클라이언트가 인가 서버로 리디렉션 → 로그인 화면 표시

2. 사용자 승인
	사용자가 클라이언트의 자원 접근을 허용

3. Authorization Code 발급
	인가 서버가 클라이언트 Redirect URI로 인가 코드 전달

4. Access Token 요청
	클라이언트가 서버 사이드에서 인가 코드 + 클라이언트 비밀키를 보내 토큰 요청

5. Access Token 발급
	인가 서버가 Access Token과 Refresh Token을 발급

6. Resource Server 접근
	클라이언트가 Access Token으로 보호된 자원에 접근

 

보안 포인트

- 인가 코드를 브라우저에서 직접 Access Token으로 교환하지 않음

>> 토큰 유출 위험 감소

- state 파라미터 사용으로 CSRF 공격 방지

- HTTPS 사용으로 코드 및 토큰 탈취 방지