[Spring Security] #2 인증 방식: 쿠키 vs 세션 vs JWT

 

오늘은 대표적인 사용자 인증 방식인 쿠키 vs 세션 vs JWT 방식에 대해 정리해보겠습니다.

제가 들은 강의에서는 세션과 쿠키를 합쳐 설명했는데

블로그를 쓰기 위해 자료 조사를 하다보니 쿠키와 세션을 구분짓는 분들이 많으시더라고요.

추가적으로 학습한 내용을 종합하여 써봅니다.

 

먼저 읽으면 좋은 글: 인증과 인가 개념 https://syleeblog.tistory.com/40

---

 

🍪 쿠키 방식

웹에서 쿠키란 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각입니다.
브라우저는 데이터 조각들을 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이터를 함게 전송합니다.

출처: MDN WEB DOCS

 

 

1. 클라이언트가 서버에 로그인 인증 요청을 보냅니다.

2. 서버에서는 적합한 유저인지 인증합니다.

3. 인증이 완료되면 쿠키에 사용자 인증 정보(유저 ID나 인덱스 등 이 유저를 인증한 정보/식별하기 위한 정보)를 담아 응답합니다.

4. 클라이언트 쿠키에 사용자 인증 정보가 저장됐습니다.

5. 클라이언트가 재요청을 할 때마다 쿠키에는 사용자 인증 정보가 담겨 있습니다. 서버는 이를 토대로 인가를 처리합니다.

 

사용자의 인증 정보를 서버가 저장하지 않고, 클라이언트가 저장한 후 요청마다 인증 정보를 쿠키에 담아 보내는 방식입니다.

이렇게 서버가 인증 상태를 관리하지 않는 것을 "Stateless(무상태)"하다고 표현합니다.

 

그러나 이렇게 단순한 쿠키 방식은 잘 사용되지 않습니다. 클라이언트에서 쿠키의 인증 정보를 쉽게 위조할 수 있기 때문입니다.

---

🗂️ 세션 방식

세션은 브라우저(클라이언트)와 웹 서버가 연결되어 브라우저가 종료될 때까지의 시점을 말합니다.

 

사용자가 로그인을 할 때

올바른 사용자임이 인증되면 서버는 쿠키에 세션 ID를 담아 응답합니다.

이후 클라이언트는 요청 시 쿠키에 저장된 세션 ID를 함께 전달하여 서버가 클라이언트를 식별할 수 있도록 합니다.

 

1. 클라이언트에서 로그인을 요청합니다.

2. 서버에서 사용자 식별 후 서버에 사용자 인증 정보 저장합니다.

3. 쿠키에 세션 ID를 담아 응답합니다.

4. 클라이언트가 세션 ID를 가지고 새로운 인가 요청을 합니다.

5. 서버에서는 세션 ID를 바탕으로 서버에 저장된 인증 정보를 확인 후 인가 처리를 합니다.

 

아래 코드에서 session.setAttribute로 세션 정보를 저장할 수 있습니다.

@PostMapping("/login")
public ResponseEntity<?> login(LoginDto dto,
                               HttpSession session) {
    User u = service.verify(dto.email(), dto.password());
    session.setAttribute("LOGIN_ID", u.id()); 
    return ResponseEntity.ok("login ok");
}

 

 

쿠키와 달리 세션 방식에서는 서버가 인증 정보를 관리한다는 점이 포인트입니다.

 

세션이 유지되는 동안은 서버의 메모리에 인증 정보를 계속 저장하고 있어야 합니다.

즉, 서버의 메모리의 어느 부분이 계속 점유당하고 있습니다. 이렇게 서버가 클라이언트의 상태를 기억하는 것을 Stateful(상태 유지)라고 합니다.

이 때문에 Redis(key- value 구조의 고성능 저장소)에 세션 정보를 저장하기도 합니다. 

 

세션 방식의 장점

• 서버에서 인증 정보를 관리하기 때문에 일반 쿠키 방식보다 안전합니다.
• 브라우저가 쿠키를 자동으로 붙여주므로 서버에서는 CSRF 토큰 전략만 마련하면 됩니다.
  • CSRF 토큰이란 로그인 시 서버가 발행해주는 토큰으로, 클라이언트와 공유되는 인증 값입니다.
    클라이언트는 올바른 토큰 값을 포함해야 서버에 요청을 할 수 있습니다.
• 서버 측에서 세션을 쉽게 무효화할 수 있습니다. 어느 사용자의 접근이 비정상적으로 보이면 바로 로그아웃시킬 수 있는거죠.

세션 방식의 단점

• 서버에 인증 정보를 저장해야 하므로 메모리나 Redis 등 세션 저장소 운영 비용 부담이 있습니다.
• 모바일 앱이나 SPA에서는 쿠키 다루기가 번거로울 수 있습니다.
  • SPA란? Single Page Application으로 모든 페이지를 가져오지 않고,
    필요한 컨텐츠를 서버에서 비동기적으로 가져와 현재 페이지 내에서 업데이트하는 모던 웹 애플리케이션입니다.

---

🪙 JWT 방식

JWT 방식은 토큰을 이용하는 방식입니다.

JWT는 Json Web Token의 약자로, 아주 긴 문자열로 되어 있습니다.

 

1. 클라이언트가 서버에 로그인 요청을 보냅니다.

2. 서버에서는 인증 후 응답에 토큰을 담아 (헤더 또는 쿠키로)  보냅니다.

3. 클라이언트는 이 토큰을 어딘가(로컬 스토리지 등)에 저장합니다.

4. 클라이언트는 이후 인가 요청 시마다 토큰을 함께 담아 보냅니다.

5. 서버에서는 올바른 토큰인지 확인 후 인가 처리를 합니다.

 

이전 방식들과의 차이점은 쿠키가 아닌 JWT 토큰을 주고 받는다는 점과

토큰에는 만료 시간이 있고, 서버에서 아직 만료시간이 남았는지, 사용자가 맞는지 등 유효한 토큰인지 검증하는 단계가 있다는 점입니다.

 

이 토큰은 이 서버에서만 사용하는 시크릿 키라는 특이한 값과 특정 알고리즘들에 따라 만들어집니다.

헤더와 페이로드, 시그니처로 구성이 되는데 오늘 글에서는 JWT 토큰 만드는 법에 대해서는 넘어가겠습니다.

 

서버에서는 사용자 인증 정보를 저장하지 않습니다.

처음 인증 요청에서만 토큰을 발급하고,  이후 요청에서는 늘 클라이언트가 토큰을 담고 요청을 하니

매번 토큰을 검증합니다. 이처럼 클라이언트의 상태를 저장하지 않으므로 Stateless 합니다.

 

JWT 방식의 장점

• 서버는 Stateless하기 때문에  서버 측의 부하가 낮습니다. 서버 인스턴스가 여러 대 확장되어도, 세션 공유 문제가 발생하지 않습니다.
• API 게이트웨이나 모바일 네이티브 연동이 세션에 비해 수월합니다.

 

JWT 방식의 단점

• 토큰이 탈취당하면 만료되기 전까지는 해커를 막을 방법이 없습니다.
• 한 번 발급된 토큰은 알아서 만료되기 전까지 수정이나 폐기가 불가능합니다.
  • 이를 보완하기 위해 만료 시간이 짧은 AccessToken과 만료 시간이 긴 Refresh Token을 둘 다 발급하고, AccessToken 만료 시 Refresh Token을 이용해 Access Token을 새로 발급 받는 방법이 있습니다. 이러면 AccessToken이 탈취되어도 금방 만료될테니 해커가 움직일 수 있는 시간이 짧아집니다.

---

참고자료

• https://ksh-coding.tistory.com/113
• https://velog.io/@gotaek/%EC%84%B8%EC%85%98Session%EA%B3%BC-JWT
• https://docs.tosspayments.com/resources/glossary/spa