첫 프로젝트를 회원,인증파트로 시작해서
세션 vs 토큰 중 무엇을 선택할지 정해야했다.
나는 쪼랩이라 저게 뭔지도 몰랐다..

그래서 배운걸 하나씩 남겨보려고 한다..
나같은 쪼랩에게 도움이 되길바라며
ai한테 물어보려나?

먼저 세션에 대해 이야기를 해보겠다..

📄session (feat. 🍪)

세션 기반 인증은 stateful 하다고 할 수 있는데 이 stateful이 뭐냐!!

서버가 로그인한 사용자의 정보를 자체적으로 저장하는 것이다

즉 로그인하면 서버가 세션id 는 클라이언트에게 주고, 세션 데이터는 db에 저장을 해서 요청마다 id와 데이터가 일치한지 db에 조회를 하는 것이다

이때 클라이언트는 세션id를 쿠키로 들고다니는데 왜 쿠키가 필요할까??

HTTP가 stateless 프로토콜이기 때문이다!

stateless는 말그대로 stateful 과 반대로 자체적으로 저장하지 않기 때문에 요청 하나하나를 기억하지 못하게 된다
페이지가 넘어갈 때마다 증명을 해야하는 것이다

그냥

하하가 되.

그렇담 쿠키는 당연히! 클라이언트를 기억할 수 있게 도와주는 역할을 하는데 어떻게 하냐면!
0. 쿠키는 http 헤더를 통해 주고받는 형식
1. 서버가 set-cookie: id=abc; max-age= 3600; httpOnly; secure 라는 응답헤더를 보냄
2. 클라이언트는 이 헤더를 보고 쿠키 저장소에 세션id를 저장!
3. 이제 다음 요청부터는 쿠키를 함께 헤더에 넣어서 보냄
4. 서버는 db에 있는 세션 데이터와 쿠키안에 있는 세션id를 비교 (stateful과 동일)

2번의 클라이언트가 쿠키저장소에 세션 id를 자동저장하는건 only 브라우저만 가능!
만약 모바일이나 api클라이언트라면 개발자가 직접 구현해야합니다....

그래서 세션의 장단점이 무엇일까요?

장점

1. 사용자의 중요한 데이터는 서버에 있음(= 세션을 직접 관리)
2. 그러므로 탈취가 된다하더라도 중요한 데이터는 서버가 보존
3. 그러므로 즉각적으로 무효화를 시킬 수 있음
   => 보안&즉각적인 무효화에 강하다

단점

1. 사용자의 중요한 데이터는 서버에 있음(= 세션을 직접 관리)
2. 그러므로 사용자가 많아질수록 서버에 과부하
3. 쿠키에 의존하다보니 쿠키와 맞지 않는 환경에는 다루기 불편
   => 확장성&유연성에 약하다

그래서 우리는 이러한 단점을 만회하기 위해 Redis 같은 중앙저장소를 사용합니다!

1. TTL(만료시간 설정) 이 가능합니다! -> 세션 만료시간을 자동으로 정해둬서 로직을 짤 필요가 없는 장점🤩
2. 원자적인 명령어 처리! -> 여러 서버가 동시에 같은 세션에 접근해도 데이터가 꼬이지 않아요
3. RDB, AOF 와 같은 영속성 옵션 -> 세션데이터가 날라가지 않음

이제 또다른 방식 stateless 한 토큰(jwt)가 등장합니다~!!

토큰(JWT)

토큰은 stateless해서 서버가 사용자의 데이터를 따로 저장하지 않고
사용자가 사용자 정보를 담은 토큰을 가지고 다니며 인증하는 시스템이다!
사용자가 많아져도 서버에 과부하가 오지 않는 장점이 있습니다만

말만 들어도 보안에 취약한게 느껴지지 않습니까??

느껴지지 않으thㅔ요?!?!?!??

문제점 1번

jwt는 header+payload+signature 구조인데
header = authorization: Bearer ,,, 으로 이루어져있고 이를 디코딩하면
algorithm, type이 나옵니다
이때 algorithm 에는 토큰의 signature를 만들때 어떤 알고리즘을 썼는지 나타냅니다.
예를 들면 HS256(대칭키), RS256(비대칭키)
문제는 이 알고리즘이 서명 전이라 조작이 가능합니다...
공격자가 알고리즘을 none값으로 바꿔버릴 수 있다는 것이죠
즉 none -> 서명 검증을 하지 않아도 됨이 되는것!!
=> 따라서 우리는 none은 무조건 거부하는 방식으로 대응

문제점 2번

앞서 말씀드렸듯이 jwt는 signature를 씁니다. 암호화(encrypt)가 아니란거죠!!
즉 payload(내용물)을 누구나 디코딩해서 읽을 수 있습니다.
=> 따라서 우리는 payload에 민감한 정보를 넣지 않는 방식으로 대응

문제점 3번

탈취 당했을 경우 세션과 달리 정지가 어렵습니다. 왜냐면 서버가 직접 관리하지 않기 때문이죠!
=> 따라서 우리는 refresh token rotation 을 이용합니다.

refresh token rotation이 뭐냐!

1. 로그인 시 access, refresh token 두개를 사용자에게 줍니다.
   -> 이때 access 유효기간은 짧게 (30분) refresh 유효기간은 길게(1달)
2. refresh token 은 db에 저장합니다.
3. access 유효기간이 만료되었을 때 토큰을 재발급하기 위해 사용자는 refresh token 을 서버에 제시하고 서버는 db에 저장된 refresh와 대조합니다 (stateful 과 동일)

그럼 여기서 궁금한 점!
똑같이 db에 넣어놓고 대조하면 jwt의 서버의 과부하를 줄이는 장점이 사라지지 않나요?
=> refresh 유효기간이 길기때문에 엄청난 과부하가 일어나진 않습니다!!

이상입니다..