[묘공단-스프링부트3-9장] JWT 이거 auto-k 쓰는 고얌(주의: JWT 얘기는 별로 없음)

'스프링 부트 3 백엔드 개발자 되기'책을 읽으면서 9장이 가장 힘들었다.
JWT은 커녕 세션, 토큰, 쿠키, 서버 기반 인증 뭐 이런 걸 잘 모르기 때문이다...
아니, 내가 실제로 써 본 적이 없다...
그래서 이 페이지에서는 개발 개념을 좀 잡고 가려고 한다.

인증 관련 기본 개념

1. 세션 (Session)
세션은 사용자가 웹 사이트에 로그인할 때, 서버에서 생성되어 사용자의 상태 정보나 환경 설정 등을 저장하는 임시 저장소를 의미합니다. 세션은 서버에 저장되며, 사용자마다 고유한 세션 ID가 생성됩니다. 이 세션 ID는 클라이언트(일반적으로 웹 브라우저)에 쿠키 형태로 저장될 수 있습니다.
2. 쿠키 (Cookie)
쿠키는 웹사이트의 사용자의 브라우저에 저장되는 작은 데이터 조각입니다. 쿠키는 사용자의 선호 설정, 로그인 상태, 장바구니 정보 등을 저장하거나 추적하는 데 사용됩니다. 쿠키는 매 요청마다 서버로 전송됩니다.
3. 서버 기반 인증 (Server-based Authentication)
전통적인 인증 방식입니다. 사용자가 로그인 정보(예: 아이디와 비밀번호)를 제공하면, 서버는 해당 정보를 확인하고 세션을 생성합니다. 그리고 해당 세션 ID를 사용자에게 쿠키로 전송합니다. 사용자는 이후 요청 시 쿠키를 포함하여 전송하면, 서버는 쿠키에 있는 세션 ID를 확인하여 인증합니다.
4. 토큰 기반 인증 (Token-based Authentication)
토큰 기반 인증에서는 사용자가 인증 정보를 제공하면, 서버는 해당 정보를 확인한 후 토큰을 발급합니다. 이 토큰은 일반적으로 서버에 저장되지 않으며, 사용자가 그 토큰을 포함하여 요청을 할 때마다 서버는 토큰을 확인하여 인증합니다. 토큰은 특정 기간 동안만 유효하며, 그 이후에는 만료됩니다.
5. JWT (JSON Web Token)
JWT는 토큰 기반 인증 방식 중 하나로, 정보를 JSON 형태로 표현한 토큰입니다. JWT는 세 부분으로 나뉩니다: 헤더(Header), 페이로드(Payload), 서명(Signature).
헤더: 토큰의 유형 및 사용하는 알고리즘 정보를 포함합니다.
페이로드: 토큰에 포함된 데이터(예: 사용자 ID, 권한)를 포함합니다.
서명: 헤더와 페이로드를 암호화한 값입니다. 이 서명은 토큰의 무결성을 보장합니다.
사용자가 로그인하면 서버는 JWT를 생성하여 사용자에게 반환합니다. 사용자는 이후 요청에서 JWT를 헤더나 본문에 포함하여 전송하면, 서버는 JWT를 검증하여 인증합니다.

이 중 어떤 게 가장 기본적인 개념일까?

쿠키와 세션이 가장 기본적이고 전통적인 방법이다.

쿠키는 HTTP 응답 헤더를 사용하여 설정되며, 웹 브라우저에 저장됩니다. 그 후, 브라우저는 쿠키를 각 요청의 HTTP 헤더에 포함시켜 서버로 전송합니다.

세션은 서버에서 사용자 정보를 저장하는 임시 저장소입니다. 사용자가 로그인하면 서버는 세션을 생성하고, 해당 세션에 대한 고유한 ID를 발급합니다. 이 ID는 쿠키로 사용자에게 전달됩니다.

세션 구현 순서:
1. 사용자가 로그인 요청을 보냄.
2. 서버에서 사용자의 인증 정보를 확인.
3. 인증이 성공하면, 서버는 세션을 생성하고 고유한 세션 ID를 발급.
4. 이 세션 ID를 쿠키로 설정하여 사용자에게 응답.
5. 사용자의 브라우저는 이후의 요청에 쿠키를 포함하여 전송.
6. 서버는 쿠키에 포함된 세션 ID를 확인하여 해당 사용자의 세션에 접근.

쿠키와 세션은 두 개의 별개의 기술이지만, 인증 및 사용자의 상태 정보를 유지하기 위해 자주 함께 사용됩니다. 이러한 맥락에서 보면, 쿠키는 세션을 구현하기 위한 방법 중 하나로 사용될 수 있습니다.

쿠키는 세션 ID와 같은 정보를 클라이언트 측에 저장하고, 서버 측의 세션 정보와 일치시키는 데 사용되는 매개체로 볼 수도 있습니다. 세션 자체의 데이터는 서버에 저장되며, 보안상의 이유로 클라이언트에는 저장되지 않습니다.

인증이 쿠키와 세션으로는 불충분했던 걸까?

YES.

쿠키와 세션은 웹에서 상태 유지를 위한 전통적인 방법이지만, 웹과 모바일 어플리케이션의 복잡성과 다양성이 증가함에 따라 그 한계와 단점이 도드라지게 되었습니다. 이에 따라 다른 대안적인 방법들이 등장하게 되었습니다.

쿠키와 세션의 주요한 제한점과 문제점은 다음과 같습니다:

1. 상태 유지 (Stateful): 세션은 서버에 상태를 저장하므로 확장성이 제한됩니다. 웹 트래픽이 많아지면 세션 정보를 저장하고 관리하는 데 많은 리소스가 필요합니다.
2. 쿠키 크기 제한: 쿠키는 브라우저 및 도메인 별로 크기와 개수에 제한이 있습니다. 큰 데이터를 저장하기에는 적합하지 않습니다.
3. 보안 문제: 쿠키는 중간에서 가로챌 수 있으므로 민감한 데이터를 저장하는 데 적합하지 않습니다. 물론 쿠키에 저장된 세션 ID도 탈취될 위험이 있습니다.
4. 크로스 도메인 제한: 쿠키는 동일한 출처 정책 (Same-Origin Policy)에 따라 도메인 간에 공유되지 않습니다.
5. 모바일 환경: 많은 모바일 앱은 쿠키를 사용하지 않거나 제한적으로 사용합니다. 따라서 다른 방법의 인증 및 상태 유지가 필요합니다.

이러한 문제점들을 해결하기 위해, 토큰 기반의 인증 방식이 도입되었습니다. 특히 JWT (JSON Web Tokens) 같은 기술은 서버에서 상태를 저장하지 않는 상태 없음 (stateless) 인증 방식을 제공하여 확장성을 개선하고, 다양한 플랫폼과 서비스 간의 인증을 쉽게 구현할 수 있게 해주었습니다.

또한, API 중심의 개발 방식과 마이크로서비스 아키텍처가 인기를 얻으면서, 서버 간의 통신과 다양한 클라이언트 (웹, 모바일, 데스크톱)에서의 인증이 중요해졌습니다. 이러한 환경에서는 토큰 기반의 인증 방식이 더 유연하고 적합하다고 판단되었습니다.

그래도 토큰보다 세션과 쿠키를 쓰는 게 유리한 환경이 있지 않을까?

YES.

1. 단순한 웹 애플리케이션: 작은 규모의 웹 애플리케이션에서는 세션과 쿠키만으로도 충분히 사용자 인증과 상태 관리를 할 수 있습니다. 토큰 기반의 인증 시스템을 도입하는 것은 오버킬이 될 수 있습니다.
2. 서버 사이드 렌더링: 서버 사이드에서 페이지를 렌더링 할 때 사용자의 상태나 세션 정보가 필요한 경우, 쿠키와 세션을 사용하는 것이 토큰보다 직관적일 수 있습니다.
3. 보안: 토큰은 탈취당하면 해당 토큰의 유효 기간 동안 악용될 수 있습니다. 반면, 세션은 서버 측에서 관리되므로 더 높은 수준의 보안 조치를 취할 수 있습니다. 예를 들어, 비정상적인 접근 패턴을 감지하면 세션을 즉시 무효화할 수 있습니다.
4. 자동 만료: 세션은 설정된 시간 후에 자동으로 만료될 수 있습니다. 이는 추가적인 구성 없이 보안을 강화할 수 있는 방법 중 하나입니다. 토큰도 만료 시간을 가질 수 있지만, 토큰의 재발급 및 관리가 필요할 수 있습니다.
5. 세션 저장의 유연성: 세션 데이터는 메모리, 데이터베이스, 캐시 (예: Redis) 등 다양한 저장소에 저장될 수 있습니다. 이를 통해 애플리케이션의 확장성과 가용성을 향상시킬 수 있습니다.
6. 데이터 저장의 용이성: 세션은 사용자와 관련된 여러 정보를 저장하기 쉽습니다. 토큰의 경우, 너무 많은 정보를 포함시키면 토큰의 크기가 커지게 되어 네트워크 부하가 발생할 수 있습니다.

그럼 다시 JWT으로 돌아가자. JWT 구현 FLOW는?

1. 로그인 요청: 사용자는 자신의 아이디와 비밀번호로 로그인 요청을 합니다.
2. 검증: 서버는 제공된 아이디와 비밀번호를 검증합니다.
3. 토큰 생성: 서버는 검증이 성공하면 사용자에 대한 정보와 일부 메타데이터(예: 유효 기간)를 포함하는 JWT를 생성합니다. 이 토큰은 서버의 비밀 키(secret key)로 서명되어 변조를 방지합니다.
4. 토큰 응답: 생성된 JWT를 사용자에게 응답으로 전송합니다.
5. 토큰 저장: 클라이언트(웹 브라우저, 모바일 앱 등)는 받은 JWT를 적절한 위치에 저장합니다. 웹의 경우 Local Storage나 Session Storage에 저장할 수 있습니다.
6. 인증된 요청: 사용자가 인증이 필요한 요청을 서버에 보낼 때, JWT를 HTTP 헤더 (보통 'Authorization' 헤더)에 포함시켜 보냅니다.
7. 토큰 검증: 서버는 요청에서 받은 JWT를 자신의 비밀 키로 검증합니다. JWT의 서명이 올바른지, 유효 기간이 만료되지 않았는지 등을 확인합니다.
8. 요청 처리: 토큰 검증이 성공하면 서버는 요청을 처리하고 결과를 사용자에게 응답합니다. 만약 토큰이 유효하지 않으면 인증 오류 응답을 보냅니다.
9. 토큰 만료 및 갱신 (선택적): JWT는 유효 기간을 가질 수 있습니다. 만료된 경우 새로운 토큰을 발급받아야 합니다. 이를 위해 갱신 토큰(refresh token) 같은 추가 메커니즘을 사용할 수 있습니다.

이는 JWT의 기본적인 구현 흐름입니다. 실제 환경에서는 더 많은 세부 사항과 보안 고려 사항이 있을 수 있습니다.

JWT 구현 코드는 책에서 볼 수 있다!
웬만하면 잘 모르는 내용을 끝까지 확인하는 나인데 JWT 구현 부분은 그럴 엄두가 나지 않는다.
그래서 어떤 플로우를 타서 구현이 되었는지도 지금은 기록하지 않으려 한다.
어차피 타임어택 몬스터에 회원가입, 로그인 적용하면 JWT도 같이 적용해야 하기 때문에
그때까진 편안하게 책 진도만 나가고 싶다!

이 글은 골든래빗 《스프링 부트 3 백엔드 개발자 되기 - 자바 편》의 9장 써머리입니다.