Index

• 유저 식별과 인증
  • Session 기반 인증
  • JWT 기반 인증
• 정리
• References

유저 식별과 인증

Session 기반 인증

• HTTP는 무상태 프로토콜로 어떤 정보도 저장하지 않는다.
• 서버는 인증된 사용자 정보를 저장하기 위한 용도로 Session을 만들고, 식별자인 session-id(쿠키)를 요청 헤더에 포함시켜 클라이언트에게 전달한다.

• 클라이언트는 요청마다 헤더에 session-id(쿠키)를 넣어, 서버가 클라이언트를 식별할 수 있도록 해야한다.

  [출처] https://cscie12.dce.harvard.edu/lecture_notes/2007-08/20080423/slide51.html

문제점

• Session은 서버 메모리에 저장되기 때문에 너무 많아지면 서버 메모리 부족이 발생
• 장애 발생시 복제본 없는 Session 정보는 유실됨 => 해당 서버에 저장된 유저들 로그인 풀림

해결책

• Scale-Out, 한 대가 아닌 여러대의 서버로 운영

=> BUT, 서버 수가 늘어난만큼 서버간 Session 공유를 어떻게 할지, 특정 서버에 장애가 발생하면 가용성은 어떻게 확보할지.. 생각해야 할 부분이 많아진다

[관련 내용은 여기서 - 멀티 서버 환경에서 Session 관리와 Session Clustering]

너무 복잡하다. 상태 유지를 꼭 해야하나?

모든 유저에게 동일하게 보여지는 정적 컨텐츠가 아닌 이상 현실속에서 불가능해보인다.

그럼 세션 없이 상태를 저장하는 다른 방법은 없을까? 있다!

=> 그것은 바로 JWT!!

JWT 인증 방식

• Json Web Token
• 더이상 세션을 이용하지 않음
• 세션은 Stateful(상태를 어딘가에 저장)했다면 JWT는 Stateless(상태를 저장하지 않음)
• 어떻게 Stateless 할 수 있단 말인가?
  • JWT는 필요한 모든 정보를 자체적으로 지니고 다님
  • 위 사진에서 왼쪽의 인코딩된 상태가 서버와 클라이언트간에 주고 받는 형태. 요청/응답 헤더에 JWT를 넣어서 주고 받음
  • 서버는 요청 헤더의 JWT를 디코딩해서 유저 정보를 가져옴.
    • JWT를 디코딩하면 다음 세부분으로 이루어져 있다.
      • header - JWT 메타데이터
      • payload - 유저 식별 정보가 들어있음
      • signature - 토큰 위변조 확인 위해 사용
• 주의할 점
  • JWT Payload에 사용자 민감 정보(email, password 등)은 넣으면 안된다. 사용자 식별값(PK, 유저 ID)을 넣어야 한다.
• 암호화를 안하고 인코딩인 이유
  • 암/복호화는 큰 연산
  • 초당 수천번씩 들어오는 요청을 서버에겐 큰 부담. 그래서 인코딩 사용

References

프로그래머스 웹백엔드 스터디
jwt.io
https://meetup.toast.com/posts/239
https://hyuntaeknote.tistory.com/6?category=867120
https://dooopark.tistory.com/6
https://thecodinglog.github.io/web/2020/08/11/what-is-session.html