세션 로그인 과정
- 클라 - 로그인 폼 보냄
- 서버 - 로그인 확인 후 세션 생성, 세션 정보는 서버에, 클라에는 로그인 식별자 넘겨줌
- 클라 - Request마다 식별자 넣어서 보냄
- 서버 - 식별자로 로그인 됐는지 확인하고 응답 보내줌
왜 JWT를 쓰지?
JWT는 마이크로서비스 아키텍처와 함께 성장해 온 것 같다. 한 서비스의 이용자는 많아졌고 사용자 모두에게 빠른 응답을 하기 위해서는 하나의 서버에 모든 것을 담을 수 없다. 또 하나의 기능을 하는 서버 조차 여러개로 나뉘어 있다.
이 상황에서 개발자들은 어떤 서버에 로그인 정보와 그에 따른 사용자 정보를 저장할 것인가 고민했을 것이다. 디비에 저장한다면 디비에서 병목이 일어날 것이다. (병목을 해결하려고 또 디비를 나눌 수도 없는 노릇....)
아무튼 그래서 JWT라는 걸 사용하기 시작했다.
JWT 로그인 과정
- 클라 - 로그인 폼 보냄
- 서버 - 로그인 확인 후 필요한 정보 넣어서 토큰 만듦, 응답할 때 토큰도 보내줌. (토큰은 서버의 키로 암호화되어 있어 서버만 풀어볼 수 있다)
- 클라 - 서버 응답으로 받은 JWT를 저장함 (로컬 스토리지, 쿠키)
- 클라 - Request마다 JWT를 헤더에 포함하여 보냄
- 서버 - JWT를 검증하고 필요한 사용자 정보 확인하여 응답 보내줌
핵심은 서버에 사용자 정보가 저장되어 있지 않다는 것. 서버가 하는 일은 토큰까서 확인하는 것 밖에 없다. 사용자가 누군지 어떤 권한이 있는지 전부 토큰에 적혀있다. 그래서 JWT 방식은 분산 서버 환경에서 유용할 것이다.
그럼에도 세션의 장점은?
역설적으로 "로그인 정보과 사용자 정보 등이 다 서버에 저장되어있다"는 부분이다. 왔다갔다 하는 데이터가 적어서 부하가 덜하고, 클라이언트가 세션과 인증 정보를 건드릴 수 없을 것이다. 또 암호화와 서명 과정이 없기 때문에 간편하다. 분산 환경이 필요한 대규모 프로그램이 아닌 이상 웬만하면 세션으로도 사용자 인증 문제를 해결하는 게 좋아보인다.
중학생에게 JWT를 설명하기
너에게 키를 줌 키마다 들어갈수 있는 곳이 다름 -> JWT
너에게 암호를 알려줌 관리 아저씨가 암호를 듣고 문을 열어줌 -> 세션
중꺽그마