[TIL] 09/08 session/cookie 와JWT

session/cookie

session/cookie

사용자가 로그인을 하게 되면 서버에서는 DB속의 사용자를 확인 후 사용자의 고유한 ID값을 부여하여 세션 저장소에 저장한다. 

그리고 세션 ID를 발행해주고 사용자는 서버에서 세션 ID를 쿠키에 저장한 후 인증이 필요할 때 마다 쿠키를 헤더에 실어 보낸다.

서버에서는 쿠키를 받아 세션 저장소에서 대도를 한 후 대응되는 정보를 가져와서 사용자에 맞는 데이터를 보내준다. 

 

session/cookie 방식은 기본적으로 session저장소를 필요로 한다, 

session 저장소는 사용자의 정보를 저장하고 세션ID 값을 만들어 HTTP헤더에 실어 사용자에게 전달한다. 그리고 사용자는 인증이 필요한 요청에 쿠키에 보관하고 있던 sessionID를 보낸다. 웹 서버는 이 쿠키를 받아 session 저장소에 젖장되어 있는 정보와 매칭시켜 인증을 완료 한다. 

 

**세션과 쿠키

  session : 서버에서 가지고 있는 정보 

  cookie : 사용자에게 발급된 세션을 열기 위한 열쇠(SESSION ID)

• 쿠키만으로 인증을 사용한다는 말은 서버의 자원은 사용하지 않는다는 것, 즉 클라이언트가 인증 정보를 책임지게 된다.
• 위와 같은 경우는 HTTP 요청을 탈취당할 경우 다 털리게 된다.
• 따라서 보안과는 상관없는 단순히 장바구니나 자동로그인 설정 같은 경우에는 유용하게 사용된다.

JWT

사용자가 로그인을 하면 서버는 사용자를 확인 후 유니크ID값을 부여한 뒤 기타 정보와 함께 Payload에 넣는다.

JWT 토큰의 유효기간을 설정한 뒤 암호화 할 SECRET KEY를 이용해 ACCESS TOKEN을 발급하고 사용자는 Acess Token을 받아 저장한 후, 인증이 필요할 때 토큰을 헤더에 담아 보낸다. 

서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효기간을 확인하고 검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져온다.

 

**세션/쿠키 방식과 차이점

• 세션/쿠키는 세션 저장소에 유저의 정보를 넣는 반면, JWT는 토큰 안에 유저의 정보들이 넣는다
• 클라이언트 입장에서는 HTTP 헤더에 세션ID나 토큰을 실어서 보내준다는 점에서는 동일 but 서버 측에서는 인증을 위해 암호화를 하냐, 별도의 저장소를 이용하냐는 차이가 발생

**취약점

이미 발급된 JWT에 대해선 돌이킬 수 없다. JWT는 한번 발급 되면 유효기간이 완료될 때 까지 계속 사용이 가능하기 때문 

• 해결책 
  • Access Token의 유효기간을 짧게 정한다.
  • Refresh Token이라는 새로운 토큰을 발급한다.

Payload 정보가 제한적 따로 암호화 되어 있지 않기 때문에 디코딩하면 누구나 확인이 가능하다. 

따라서 중요한 정보들은 넣을수 없다.