글의 목적
- session과 jwt token만을 비교하여 인증과 인가에 대해서 깊에 이해하기 위함.
본론
Session 이란?
- 유저의 정보를 데이터베이스에 저장하고 상태를 유지하는 도구
Session의 특징
- Session은 특수한 ID 값으로 구성되어 있다.
- Session은 서버에서 생성되며 클라이언트에서 쿠키를 통해 저장된다.
- 클라이언트에서 요청을 보낼때 Session ID를 같이 보내면 현재 요청을 보내는 사용자가 누구인지 서버에서 알 수 있다.
- Session ID의 정보가 서버에 특정 데이터베이스의 정보와 연결이 되어있다는 의미
- 그래서 요청마다 매번 아이디와 비밀번호를 물어볼 필요 없음 (jwt도 같은 특징을 가짐)
- Session ID는 데이터베이스에 저장되기 때문에 요청이 있을때마다 매번 데이터베이스를 확인해야한다.
- Session의 장점이면서 단점임.
- Session ID는 어떤 특정 정보를 들고 있진 않음. Random String이라고 생각하면 됨.
- 이 Random String을 가지고 서버에 데이터베이스와 비교하면 이 Random String에 해당되는 정보를 가져올 수 있음. (Key-Value 구조)
- 서버에서 데이터가 저장되기때문에 클라이언트에 사용자 정보가 노출될 위험이 없다.
- Session ID 즉, Random String은 아무런 의미가 없는 String이기 때문에 노출해도 별 상관이 없음.
- 데이터베이스에 Session을 저장해야하기때문에 Horizontal Scaling이 어렵다.
- Horizontal Scaling이란 말 그대로 수평적 확장을 말한다.
- 온프레미스 서버든 클라우드 서버든 CPU나 메모리 자체를 키우는것을 Vertical Scaling 수직확장이라고 하고 갯수를 늘리는것을 Horizontal Scaling 수평확장이라고 하는데 트레픽이 증가하면 이 둘중 하나를 고려해서 트레픽을 감당해야함.
- 하지만 Session에 저장을 해두면 수평확장을 했을때 데이터 정합성을 꼭 고려해야 함.
- 왜냐면 한 서버에 Session과 수평확장을한 다른 서버의 Session정보는 다르기 때문!
- 그래서 특정 요청은 하나의 Session에만 저장하는것을 Sticky Session이라고 하고 모든 Session정보를 공유하는것을 Session Clustering이라고 하는데 결론은 Horizontal Scaling에서 여러가지 고려해야 할게 많기 때문에 메모리측면에서도 그렇고 작업을 해야하는 번거로움도 그렇고 리소스적으로 단점이 많다는 뜻이다.
JWT Token 이란?
- 유저의 정보를 Base 64로 인코딩된 String 값에 저장하는 도구
JWT Token의 특징
- JWT Token은 Header, Payload, Signature로 구성되어 있으며 Base 64로 인코딩 되어있다.
- JWT Token은 서버에서 생성되며 클라이언트에서 저장된다.
- 서버에서 정보를 담아서 Token을 생성하면 클라이언트는 Token형태로 저장을 해둠.
- 클라이언트에서 요청을 보낼때 JWT Token ID를 같이 보내면 현재 요청을 보내는 사용자가 누구인지 서버에서 알 수 있다.
- Session과 동일하고 요청마다 매번 아이디와 비밀번호를 물어볼 필요가 없음.
- JWT Token은 데이터베이스에 저장되지 않고 Signature 값을 이용해서 검증할 수 있다. 그래서 검증할때마다 데이터베이스를 매번 들여다볼 필요가 없다.
- 토큰이 검증하는것은 결국 Signature값이 변형이되었는지 안되었는지임.
- 정보가 모두 토큰에 담겨있고 클라이언트에서 토큰을 저장하기 때문에 정보 유출의 위험이 있다.
- Base 64 인코딩 방식은 쉽게 복호화가 가능한 방식이기 때문에 쉽게 열어볼 수 있음.
- 다만 이러한 토큰 정보의 유출이 보안 문제인지를 파악하는것은 2가지 기준에서 생각해야 함.
- 토큰을 어떻게 저장하는지
- Payload에 어떤 정보를 담아두는지
- refresh token과 access token으로 어느정도 보안문제를 해결할 수 있음.
- 데이터베이스가 필요없기 때문에 Horizontal Scaling이 쉽다.
Session 생성 방식
Session 사용 방식
JWT Token 생성 방식
JWT Token 사용 방식
Session Sequence Diagram
Token Sequence Diagram
Session vs JWT Token 비교
결론
- 이제 드디어 조금 느낌이 온다.
- 여기서 Refresh Token의Sequence Diagram은 다루지 않았지만 기회가 된다면Sequence Diagram을 만들어서 올리려고 한다.
'데일리' 카테고리의 다른 글
[2023.11.26] Refresh Token & Access Token (1) | 2023.11.26 |
---|---|
[2023.11.26] 내가 놓치고 있던 부분을 발견하여 정리3 (vscode 디버깅) (4) | 2023.11.26 |
[2023.11.24] 내가 놓치고 있던 부분을 발견하여 정리2 (PM2, NGINX, gzip) (2) | 2023.11.24 |
[2023.11.24] 내가 놓치고 있던 부분을 발견하여 정리1 (cookie, session, JWT) (2) | 2023.11.24 |
[2023.11.15] Redis 이해하기 (1) | 2023.11.15 |