[Frontend/Backend] 세션/쿠키 & JWT

세션/쿠키

• 사용자가 로그인을 하면 세션 ID를 발급하여 response에 넣어 돌려줌
• 사용자는 서버에서 세션ID를 받아 쿠키에 저장한 후, 인증이 필요할 때마다 쿠키를 헤더에 실어 보냄
• 사용자의 쿠키를 해커가 가로챈 경우 서버는 해커를 사용자로 오인해 정보를 뿌려줄 수 있음
  -> HTTPS를 사용해 탈취해도 정보를 읽기 힘들게함, 세션에 유효시간을 넣어줌
• stateful(저장소가 필요한)한 서버가 되는 단점이 있음

 

토큰

• JWT(Json Web Token)
• 사용자가 로그인하면 서버에서 Acces Token을 발행
• 토큰 발행을 위해 Header, Payload, Verify Signature가 필요
  Header: 암호화할 방식, 토큰타입
  Payload: 서버에 보낼 데이터 값이 들어감, 유저의 고유 ID, 유효기간 등 (민감한 정보는 담으면 안됨)
  Verify Signature: "Header+Payload+개인키"를 서버가 가지고 있는 개인키를 가지고 암호화
  
  Header와 Payload는 디코딩만 되고 Verify Signature는 암호화
• stateful한 서버를 만드는 장점, 토큰이 탈취당하면 만료될 때까지 대처가 불가능하다는 단점이 있음
  -> 단점은 만료기간이 짧은 Access토큰과 Refresh 토큰을 이용해 해결 (Refresh토큰 저장소가 필요해 stateless해지지만 세션저장소를 활용해 인증할 때보다 I/O 요청이 적음)
• JWT를 이용한 인증절차
  1. [front] ID, Password를 백엔드에 넘겨줌
  2. [back] ID, Password를 검증하고 AccessToken을 반환
  3. [front] AccessToken을 받아 다음 api호출부터 헤더에 붙여줌
  4. [back] api 호출 시 AccessToken이 유효한지 확인하여 처리
• Refresh가 더해진 JWT를 이용한 인증절차
  1. [front] ID, Password를 백엔드에 넘겨줌
  2. [back] ID, Password를 검증하고 AccesToken과 RefreshToken, AccessToken의 만료시간 반환
  3. [front] AccessToken을 받아 다음 api호출부터 헤더에 붙여줌
  4. [back] api 호출 시 AccessToken이 유효한지, 만료기간이 지났는지 확인하여 처리
  5. [front] AccessToken이 만료기간이 지났거나, 30초 미만으로 남았다면 RefreshToken을 붙여 Reissue 요청
  6. [back] Reissue 요청이 들어올 경우, RefreshToken이 DB에 있으면 AccesToken과 새로운 AccessToken 만료시간을 반환
  7. [front] Reissue로 반환된 AccessToken과 만료기간을 저장하여 다음 api 호출에 사용