CS/Network

[CS/네트워크] 인증과 인가 방식(로그인)

연유뿌린빙수 2025. 9. 26. 02:59

 

오늘은 인증과 인가에서 중요한 역할을 하는
세션, 쿠키, 토큰에 대하여 정리해보자.

저번 CS 주제에서 이미 한 번 다루었던 내용이지만,
로그인 서비스와 연관지어 더 깊이있는 탐색을 해보려고 업로드한다.



쿠키 방식

 

1-1. 쿠키 저장과 보안 설정

가장 기본적인 인증 방식으로 사용되는 것이 Cookie이다.

Cookie는 브라우저에서 보관하며,
서버가 클라이언트에게 내려보낸 데이터를 요청 시마다 자동으로 다시 서버에 전송한다.

보안 강화를 위해 일반적으로 Cookie에 다음과 같은 설정들을 추가한다.

Cookie cookie = new Cookie("token", "값");
cookie.setHttpOnly(true);
cookie.setSecure(true);

이렇게 설정을 하면, JS와 같은 프론트 측에서 접근을 못한다.
탈취를 못하는 Cookie가 되는 것이다.

단, 일부 SPA(프론트엔드 단일 페이지 애플리케이션) 아키텍처에서는 이 방식이 서버와의 연동에 제약을 주기도 한다. 예를 들어 CORS 정책, 도메인 설정 등과 맞물려 서버-클라이언트 간 쿠키 교환이 제한될 수 있다.

 

  • HttpOnly : 자바 스크립트에서 접근할 수 없게 만들어 XSS 기반 쿠키 탈취를 방지
  • Secure : https 환경에서만 전송되어 중간자 공격에 대한 안정성을 높임

 

참고로 XSS 공격에 대하여 작성해본다.

  • XSS 공격
    • Reflected XSS
    • Stored XSS
    • DOM Based XSS

Reflected XSS, Stored XSS, DOM-based XSS 모두 자바스크립트를 통해 브라우저에서 쿠키에 접근 가능하면(=document.cookie로 읽을 수 있으면) 쿠키 탈취가 가능하다.

단, HttpOnly 옵션이 설정된 쿠키는 클라이언트 JS에서 접근할 수 없어 XSS로는 직접 탈취할 수 없음(하지만 다른 공격 경로로 우회될 여지는 있음).



 

1-2. 쿠키 탈취와 한계

보안 설정을 해도 쿠키 자체는 여전히 브라우저에 저장되는 것이 사실이다.


그리고 브라우저에 저장된 이상 위의 사진과 같이 조회가 가능하다(위는 네이버 사이트에서 로그인했을 때 확인 가능한 쿠키들의 모습이다)

만약 HTTPS가 아닌 환경,
혹은 잘못된 설정이 적용된 경우에는
공격자가 쿠키를 탈취할 수 있으며(일단 읽을 수 있으니까..),

그 결과 세션 하이재킹이나 불법 인증 재사용이 가능하다

 

 

 

세션 방식(Session)

 

2-1. Session 동작 원리

세션은 반면에,
(java 환경에서 ) HttpSession이라는 서버 딴에서의 객체를 의미한다!

서버의 애플리케이션 메모리(캐시) 에 저장이 된다!

 

클라이언트는 세션을 직접 보관하지 않고,
JSESSIONID라는 식별자( ID)만을 쿠키에 담아 서버로 전송하면서 인증을 사용한다.

서버는 이 ID를 통해 세션 객체를 찾아 인증 상태를 유지한다.

 

 

2-2. Session Hijacking과 서버 부하

그러나,
세션 방식에는 다음과 같은 단점들이 존재한다.

 

  • 세션 하이재킹(Session Hijacking)
    공격자가 XSS, 네트워크 스니핑, 중간자 공격 등을 통해서 JSESSIONID를 탈취
    -> 해당 세션에 대한 모든 권한을 가로채는 것이 가능하다( 사실상 세션 다 뺏긴거나 다름없음)
  • 세션 고정(Session Fixation)
    공격자가 임으로 세션 ID를 지정해 사용자가 그것을 쓰도록 유도하면 , 인증 오나료 후에도 공격자가 동일한 세션을 재사용하는 것이 가능함
  • 서버 부하
    서버는 모든 유효 세션을 메모리에 저장한다.
    공격자가 무효 세션 ID를 반복적으로 보내면,
    서버가 매번 새로운 세션을 생성해 메모리와 CPU를 소진시키는 DoS(서비스 거부) 형태의 부하를 유발 가능하다

 

 

2-3. 세션 방식의 한계와 대안

이러한 이유로 최근에는 세션 "단독"의 방식을 잘 사용하지는 않는 것 같다.

대신,
쿠키를 단순한 스토리지로만 사용하고 토큰 기반 인증과 결합하는 추세가 일반적이다.

즉, 서버 상태를 저장하지 않고도 인증이 가능한 구조가 필요하며,
이 요구를 만족시키는 방법이 JWT이다.



 

3. 토큰 기반 인증

 

3-1. 동작 방식

JWT는 서버가 인증을 완료하면 서명된 토큰을 발급하고,
클라이언트는 이후 모든 요청 시 이 토큰을 HTTP 헤더(Authorization: Bearer )에 담아 보낸다.

서버는 토큰을 검증만 하면 되므로, 세션을 메모리에 유지할 필요가 없다.

따라서 서버 부하가 현저히 감소하며, 세션 하이재킹의 위험도 상대적으로 낮다.

단, JWT 자체는 브라우저 쿠키 또는 로컬스토리지에 저장될 수 있으므로, 저장 위치에 따른 보안 설계(예: HttpOnly 쿠키에 저장)가 중요하다.

 

3-2. Access Token과 Refresh Token 전략

실무에서는 Access Token과 Refresh Token을 나누어 사용한다고 한다.

  • Access Token: 만료 시간이 짧고, 인증 요청 시 직접 사용하는 토큰으로 클라이언트에서 요청마다 헤더에 저장을 해두고 요청을 하면 된다.
  • Refresh Token: 만료 시간이 길며, Access Token이 만료되었을 때 새로운 Access Token을 발급받는 용도로 사용한다

이 구조는 토큰 탈취 시 피해를 최소화하고, 자동 재로그인을 할 때에는 Refresh Token을 기반으로 새로운 access token을 저장하는 형식으로 진행한다.


이 과정에서 refresh token만을 저장하는 TTL 기능이 가능한 저장소가 별도로 필요하다. 주로 사용하는 것은 redis 이다.