왜 Jwt를 썼나요, 세션이랑 Jwt 둘 다 쓰면 안되나요

Session Login과 JWT Token 로그인 차이점

무상태성(Stateless)

비 연결적인 특성으로 연결이 해제됨과 동시에 서버와 클라이언트는 클라이언트가 이전에 요청한 결과에 대해 잊어버리게 된다. 따라서 요청을 할 때마다 서버에 연결을 해야한다.

HTTP의 이러한 특성으로 인해 'Stateless Protocol'이라고 불리기도 하며 웹사이트는 매 페이지에서 로그인이 되어있는 상태인지 확인하는 로그인 인증 방식이 필요하다.

Session Login

Session: 방문자가 웹서버에 접속해 있는 상태를 하나의 단위로 보는 것
웹서버는 이러한 각 단위에 세션 Id를 부여하고 같은 브라우저인지 구별
브라우저를 닫거나 서버에서 이 (세션 Id가 들어있는)쿠키를 삭제 했을 때 삭제
session을 사용한다고 해서 cookie를 안쓰는 것은 아님.
다만, cookie가 탈취 되더라도 의미없는 문자열인 세션 Id가 들어있다.

Session Login 방식

1. 클라이언트가 서버에게 로그인 정보가 들어있는 파라미터와 함께 login을 요청
2. 서버에서 login 인증을 하고 정보가 올바르면 세션 객체를 생성하고
   세션 Id를 Set-cookie를 통해 클라이언트에게 전달
3. 세션 객체는 서버에 저장
4. 클라이언트가 서버에 작업을 요청할 때 요청 헤더에 세션 Id가 담긴 쿠키 전달
5. 서버에서는 클라이언트로부터 받은 쿠키에 세션 Id를 확인해서 세션 객체를 검색하고 정보가 있으면 요청한 작업에 대해 응답해주고 통신을 종료

장점

• 쿠키방식과 동일하지만 아무런 의미가 없는 세션 Id가 저장이 되므로 탈취되더라도 해석할 수 없다.

단점

• 해커가 중간에 가로채서 훔친 쿠키로 HTTP 요청을 보낼 수 있는 하이재킹 공격을 당할 수 있다.

해결법
(1) HTTPS를 사용해 요청 자체를 탈취해도 안의 정보를 읽기 힘들게 한다.
(2) 세션에 유효시간을 넣어 유효시간이 끝나면 더이상 해커가 이용할 수 없게 한다.

• 서버에 세션 객체를 저장해놓기 때문에 사용자가 다수일 경우 부하가 높아진다.

• 확장 시 모든 서버가 접근할 수 있도록 별도의 중앙 세션 관리 시스템이 필요하다.

• 확장성이 좋지 않다. (여러 대의 서버 컴퓨터를 추가할 경우 각 서버마다 세선 정보가 저장되기 때문에)

• CORS: 웹 어플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및
서브 도메인에서만 작동하도록 설계되어 있다. 따라서 쿠키를 여러 도메인에서 관리하는 것은 번거롭다.

JWT Login

JWT: JSON Web Token, 전자 서명 된 URL-safe (URL로 이용할 수 있는 문자)의 JSON

JWT Login 방식

1. 사용자가 id와 password를 입력하여 로그인을 시도

2. 서버는 요청을 확인하고 secret key를 통해 Access token을 발급

3. JWT 토큰을 클라이언트에 전달

4. 클라이언트에서 API를 요청할때 클라이언트가 Authorization header에 Access token을
담아서 보냄

5. 서버는 JWT Signature를 체크하고 Payload로부터 사용자 정보를 확인해 데이터를 반환
(JWT는 Header, Payload, Signature로 나뉘어짐)
Header, Payload, Signature 간단한 설명은 이 링크에

1. 클라이언트의 로그인 정보를 서버 메모리에 저장하지 않기 때문에 토큰 기반 인증 메커니즘을 제공

장점

• 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요없다.
• 서버에 상태를 저장하지 않기 때문에 무상태(stateless)로 동작하며, 확장성과 성능이 좋다.

단점

• 토큰이 클라이언트에 저장되므로, 탈취되었을 때 보안 문제가 발생
• 서버에서 토큰을 강제로 무효화하기 어려움

JWT와 Session을 같이 사용하는 경우

민감한 작업(계정 설정 변경, 비밀번호 변경 등) - Session 인증을 사용하여 추가적인 보안

일반적인 작업(게시글 조회, 댓글 작성 등) - JWT를 사용하여 빠른 응답과 확장성을 챙김

JWT를 사용하고, localStorage에 저장한 이유

모바일에 더 용이한 방식

1. 무상태: 모바일 App은 주로 API 서버와 통신하는데, JWT 로그인은 무상태(stateless) 인증
   방식이기 때문에 서버 확장성이 높고, 서버 부하가 적다.
2. 오프라인 지원: JWT는 자체적으로 정보를 포함하고 있어 인터넷 연결이 불안정한 모바일
   환경에서도 일정 시간 동안 유효성을 유지할 수 있다.
3. localStorage: 모바일 App의 localStorage는 브라우저의 저장하는 웹과 다르게, App의 사유
   디렉토리에 저장되어 다른 App이나 사용자의 의해 접근이 어렵고, 보안성이 높다.
4. 보안: 운영 체제의 샌드박스 보안 모델 덕분에 다른 App으로부터 격리, 이를 통해 데이터의 안전성 보장

따라서, 모바일 App까지 확장을 생각했기에 우리는 JWT 로그인 방식과, localStorage 저장 방식을 선택했다.

Trouble

localStorage에 저장한 정보를 탈취 당해 다른 회원의 아이디를 임의로 사용하거나 변경한 이력 발생

--> 고안해낸 해결 방법

로그인 시 localStorage에 정보를 저장할 때, 정보를 암호화해서 저장,

localStorage에 저장하여 사용했던 정보들을, 서버 측에서 제공해서 사용하는 방식으로 변경

적용은 하지 않음, 고안만 했음