1. 오늘 할 일
- 쿠키/토큰/세션/JWT 개념 정리
2. 오늘 한 일 (배운 것)
- 쿠키
- 매개체 (그냥 옮기는 시스템)
- 쿠키를 이용해서 서버(웹사이트)는 클라이언트(브라우저)에 데이터를 넣을 수 있음
- 클라이언트 -> 서버: request
- 서버 -> 클라이언트: response(+쿠키)
- 클라이언트에서 해당 웹사이트 방문할 때 마다 request(+쿠키) 보냄
- 도메인에 따라 제한됨 (YouTube 가 준 쿠키는 YouTube에만 보내짐)
- 서버가 정한 유효기간이 있음
- 인증뿐만 아니라, 여러가지 정보 저장 가능
- 클라이언트 -> 서버: 언어 설정 변경 요청
- 서버 -> 클라이언트: 쿠키(+언어) 응답
- 클라이언트 -> 서버: 다시 웹사이트 방문 시 쿠키(+언어) 요청
- 서버 -> 클라이언트: 쿠키가 기억한 언어 페이지를 제공
- 세션에서는 세션 ID를 / JWT에서는 토큰을 저장하고 전달하는 매개체
- 토큰
- ID 카드
- 서버가 기억하는 이상하게 생긴 텍스트
- 해당 토큰을 서버에 보내고 서버는 세션 db에서 해당 토큰과 일치하는 유저 찾음
- 쿠키는 브라우저에만 존재 (세션을 이용해 iOS, Android앱 만들 수 있지만 쿠키는 사용 불가) => 이 경우 토큰을 사용
- 세션
- 해당 서버에 접속한 클라이언트(유저)가 누군지 알게해주는 정보
- 중요한 클라이언트 정보는 모두 서버에 존재
- 클라이언트는 세션 ID 정보만 가지고 있음
- 현재 로그인한 클라이언트들의 모든 세션 ID를 DB에 저장함
- 유저 늘어남에 따라 DB 리소스 필요성 증가
- 요청이 들어올 때마다 서버는 쿠키를 통해 세션 ID와 일치하는 클라이언트를 찾고, 그 다음 작업을 수행 가능
- 클라이언트 -> 서버: 아이디/비번 확인 요청
- 서버: 확인되면 세션 DB에 유저 생성 (세션에는 별도의 ID가 존재)
- 서버 -> 클라이언트: 쿠키(+세션 ID) 응답
- 클라이언트: 쿠키(+세션 ID) 저장
- 클라이언트 -> 서버: 다른 페이지 접속 시 쿠키(+세션 ID) 요청
- 서버: 들어오는 쿠키(+세션 ID)를 확인 (아직까지 서버는 클라이언트가 누군지 모름, 쿠키를 지닌 요청만 있다는 것만 아는 상태)
- 서버: 해당 세션 ID를 가지고 세션 DB 확인 (클라이언트가 누군지 알게됨)
- 해당 요청이 끝나고 다른 페이지로 이동하면 5~7번 프로세스 반복
- JWT
- 유저를 인증하는데 필요한 정보를 갖고 있는 토큰
- DB 없이 검증 가능 (서버가 많은 일을 하지 않아도 됨)
- 세션 ID 보다 김 (쿠키는 공간 제약 있음, JWT는 공간 제약 없음)
- 암호화 되지 않았으므로 누구나 열어서 내용 확인 가능 (비밀정보 JWT 안에 넣으면 안됨)
- DB 대신 정보에 Sign하고 전달하는게 다임
- 클라이언트 -> 서버: 아이디/비번 확인 요청
- 서버: 확인되면 서버는 DB 에 아무것도 생성 안함
- 서버: 클라이언트(유저) ID 를 가져다가 Sign 알고리즘을 이용해 Sign을 함
- 서버 -> 클라이언트: Sign된 정보(string 형태)를 쿠키(+토큰)로 보냄
- 클라이언트: 쿠키(+토큰) 저장
- 클라이언트 -> 서버: 재방문 또는 다른 페이지 접속 시 쿠키(+토큰) 요청
- 서버: 쿠키(+토큰)에 Sign이 유효한지 체크 (조작되었는지 확인)
- 서버: 유효하다면 서버는 클라이언트를 해당 유저로 인증
- 세션 / JWT 차이
- 세션 (별도 저장소)
- 로그인 된 클라이언트(유저) 모든 정보를 DB 저장 (해당 정보로 새로운 기능 추가 가능)
- 세션 추적 가능 (특정 유저 쫒아내고 싶을 땐, 세션 삭제)
- 인스타그램 디바이스 강제 로그아웃 / 넷플릭스 계정 공유 숫자 제한
- 유저 수 많아지면 DB 유지보수 비용 증가
- JWT (암호화)
- DB 사용 안함 (비용 X)
- 생성된 토큰 추적안함
- 토큰이 유효한가 여부만 확인
- 강제 로그아웃 안됨 (토큰 만료될 때까지 유효)
- QR 체크인
- 서비스가 더 커지고 유저 계정을 좀 더 잘 관리하고 싶다면 세션으로 옮김
개발일지