JWT vs 세션

https://balhae.tistory.com/274

쿠키 VS 세션

지난 시간에 쿠키와 세션에 대해 알아봤으면 이번에는 JWT 와 세션 그리고 웹 서비스 유형을 알아보겠다. 

☑️ 인증(Authentication)과 인가(Authorization)의 이해

인증(Authentication)은 사용자의 신원을 확인하는 과정입니다. 즉, "당신이 누구인지" 확인하는 절차로, 로그인을 통해 사용자 ID와 비밀번호를 검증하는 작업이 대표적인 예입니다.

인가(Authorization)는 인증된 사용자가 특정 리소스에 접근할 수 있는 권한이 있는지 확인하는 과정입니다. 사용자가 누구인지 확인한 후, "무엇을 할 수 있는지" 결정하는 단계입니다.

☑️ 세션(Session) 기반 인증

✔️세션이란?

서버가 클라이언트의 상태 정보를 서버 측에 저장하고 관리하는 방식입니다.

 

✔️작동 원리 - 영화관 티켓 비유

사용자(고객)가 로그인(영화 무제한권 구매)하면 서버(키오스크)는 세션 ID를 생성합니다.

이 세션 ID는 마치 영화 티켓을 반으로 나눠 한 쪽은 고객에게 주고(쿠키에 저장), 다른 한 쪽은 서버(영화관 직원의 책상)에 보관하는 것과 같습니다.

사용자가 요청할 때마다 쿠키에 저장된 세션 ID를 서버에 전달하고, 서버는 저장된 세션 정보와 비교하여 인증을 수행합니다.

 

✔️세션 기반 인증의 한계

서버는 모든 클라이언트의 세션 상태를 메모리에 저장해야 하므로 stateful(상태 유지)한 특성을 가집니다.

서버 장애 발생 시 메모리에 저장된 세션 정보가 모두 소실될 수 있습니다.

확장성 측면에서 서버가 늘어날 경우 세션 정보를 동기화하는 추가 작업이 필요합니다.

디스크나 데이터베이스에 세션을 저장할 수 있지만, 이는 매 요청마다 I/O 작업이 발생하여 성능에 영향을 줄 수 있습니다.

☑️ JWT(JSON Web Token) 기반 인증

✔️JWT란?

필요한, 정보를 토큰 자체에 포함시켜 클라이언트에 전달하는 인증 방식입니다.

http://jwt.io/

 

✔️작동 원리 - 개선된 영화관 티켓 비유

사용자가 로그인하면 서버는 JWT 토큰을 발급합니다.

 

이 토큰은 반으로 나누지 않고, 바코드(서명)가 포함된 완전한 티켓으로 사용자에게 전달됩니다.

 

사용자가 서비스에 접근할 때마다 이 토큰을 제시하고, 서버는 바코드 스캐너(토큰 검증 로직)를 사용해 티켓의 유효성을 검증합니다.

 

서버는 별도의 세션 저장소 없이 토큰 자체의 유효성만 검증합니다.

 

✔️JWT 토큰의 구조

헤더(Header): 토큰 유형과 사용된 암호화 알고리즘 정보를 포함합니다.

페이로드(Payload): 사용자 정보와 권한 등 클레임(claim) 정보를 포함합니다.

서명(Signature): 헤더와 페이로드, 그리고 서버의 비밀 키를 함께 암호화하여 생성된 값으로, 토큰의 무결성을 검증합니다.

 

✔️JWT의 장점

• 서버는 클라이언트의 상태를 저장하지 않아도 되므로 stateless(상태 비저장) 시스템을 구현할 수 있습니다.
• 서버 확장이 용이하며, 서버 간 세션 공유 문제가 없습니다.
• 서버 간 인증 정보 공유가 필요 없어 마이크로서비스 아키텍처에 적합합니다.

☑️ 세션과 JWT의 비교: 각각의 장단점

✔️세션의 장점

• 보안성이 높습니다. 세션 ID가 탈취되더라도 서버에서 해당 세션을 무효화할 수 있습니다.
• 사용자의 로그아웃 처리가 용이합니다. 서버에서 세션을 삭제하면 즉시 로그아웃됩니다.
• 다중 기기 로그인 관리가 가능합니다. 한 기기에서만 로그인 상태를 유지하도록 제어할 수 있습니다.

 

✔️JWT의 단점과 해결책

• 토큰이 탈취될 경우 서버에서 개별 토큰을 무효화하기 어렵습니다.
• 이 문제를 해결하기 위해 AccessToken과 RefreshToken 개념이 등장했습니다.
• AccessToken은 짧은 수명(보통 10분 내외)을 가지며 실제 리소스에 접근할 때 사용합니다.
• RefreshToken은 긴 수명을 가지며, AccessToken이 만료되었을 때 새로운 AccessToken을 발급받는 데 사용합니다.
• 하지만 AccessToken이 탈취되면 해당 토큰의 유효 기간 동안은 방어하기 어렵다는 한계가 있습니다.

지난 블로그 참고! 

https://balhae.tistory.com/266

AccessToken과 RefreshToken 인증 방식

 

☑️ 결론: 서비스에 맞는 인증 방식 선택하기

두 인증 방식 모두 각자의 장단점이 있으므로, 서비스의 특성과 요구사항에 맞게 선택해야 합니다.

 

보안이 중요하고 사용자 세션 관리가 필요한 서비스는 세션 기반 인증이 적합할 수 있습니다.

 

확장성과 분산 시스템을 고려한다면 JWT 기반 인증이 더 적합할 수 있습니다.

 

때로는 두 방식을 혼합하여 사용하는 하이브리드 방식도 고려할 수 있습니다.

 

결국 중요한 것은 개발하는 서비스의 특성과 요구사항을 정확히 파악하고, 그에 맞는 인증 방식을 선택하는 것입니다!