Cookie/Session & Token (feat. token 주의 사항)

HTTP 통신의 특징 중 하나는 바로..
stateless 하다는 것이다.
즉, 서버에 클라이언트의 상태를 저장하지 않는다는 특징이 있다.

그러면..
로그인은 어떻게 처리할 수 있을까..
우리 눈에는 웹 페이지를 넘기면서 로그인이 유지되는 것 처럼 보이는데 말이다..

그래서, 서버에는 클라이언트의 상태를 저장하지 않고 동시에 로그인을 유지하려면...
클라이언트는 서버에게 내가 로그인한 상태라는 것을 지속적으로 알려줘야한다.
이때, 사용되는 기술이 cookie/session 방식과 token 방식이 있다.

<참고>
cookie는 stateless 한 서버를 보완하기 위해
클라이언트에서 내가 누군지 식별하기 위해 서버에 계속 보내는 정보이다.


Cookie/Session 방식에 대해 알아보기 전에.. Cookie 방식에 대해 알아보자.

cookie 방식
서버는 클라이언트의 로그인 요청에 대한 응답을 보내줄 때
클라이언트가 저장했으면 하는 정보(아이디, 주소 등 개인 식별정보)를
응답 헤더의 Set-Cookie에 담아 응답한다.
그러면 클라이언트는 서버에 요청 할 때 마다..
해당 쿠키 정보를 요청 헤더의 Cookie에 담아 요청을 할 것이고..
서버는 쿠키정보를 바탕으로 요청을 보낸 클라이언트가 누군지 알 수 있게 된다.

예시..

서버 응답 Headers = [Set-Cookie: "username=AAA", "address=BBB"]

클라이언트 요청 Headers = [Cookie: "username=AAA", "address=BBB"]

Cookie 방식은 보안에 매우 취약하다..
당연하게도 개인 식별 정보가 유출 될 가능성이 높기 때문이다..


그래서 나온 방식이..

Cookie/Session 방식이다.
개인 식별 정보를 서버의 DB나 메모리에 담아 보관하고
해당 식별 정보와 매핑되는 세션 아이디(JSESSIONID)를 쿠키로 클라이언트에 보내는 방식이다.
서버는 세션 아이디의 만료시간을 정하고 유효성을 판별 할 수 있게 되었다.

서버 응답 Headers = [Set-Cookie: "JSESSIONID=lsa12sdfa32rwafwe.."]

이제.. 쿠키에는 개인 식별정보가 아닌 무의미한 일련번호만 들어가기 때문에
보안 관점에서 좋아졌다.

Cookie/Session 방식의 단점..
1. 서버에 세션 저장소를 사용하기 때문에.. 요청이 많아지면 서버에 부하가 심해진다.
2. 중간자 공격에 취약하다.


그러면 Token 방식은 무엇일까?

cookie/session 방식과 token 방식의 차이점으로 알아보자.

대표 공통점.
두 방식 모두, 클라이언트가 로그인을 하면 서버가 인증(Authentication)의 표시로
세션/토큰을 발급해서 응답으로 내려준다.
클라이언트는, 해당 세션/토큰을 서버에 요청을 보낼 때마다
인가(Authorization) 를 위해 해당 세션/토큰을 요청에 담아 보내야한다.

대표 차이점.
세션은 서버에 저장되어야 한다.(메모리, DB 등)
토큰은 클라이언트에만 저장된다. (서버 Stateless 유지)
-> 따라서, 토큰은 세션과 다르게 서버의 확장성 면에서 뛰어나다.
토큰은 내부에 정보들이 저장되기 때문에 사이즈가 세션에 비해 훨씬 크다.


JWT 사용 시 주의사항.
1. JWT Header의 alg 필드에 none을 넣었을 경우 서버가 입장되는지 확인 필요
2. JWT는 디코딩이 매우 쉽다. 따라서, 민감한 정보를 절대로 넣으면 안된다.
3. 서버가 보관하는 비밀키를 충분히 길고 복잡하게 작성하고 유출 되지 않게 보관 해야한다.
-> 시크릿 키를 생성용 키, 검증용 키 2개로 (비대칭키) 관리 하는 방법도 있으니 참고
4. JWT 탈취 (중간자 공격)
책임 자체는 클라이언트에 있지만.. 토큰을 만료하기가 구조상 불가능하다. (서버에 없기 때문)
-> 1. JWT 블랙리스트를 운영하면.. session과 동일한 방식이 되어버림..
(블랙리스트가 서버에 저장이 되고 요청 올때 마다 매칭되는지 검사해야함)
-> 2. 만료기한을 짧게 하고 refresh 토큰을 운영한다.
->-> refresh 토큰이 탈취되는 상황이 생길 수 있다.. 이때는 Refresh Token Rotation 방식 필요