쿠키, 세션, JWT

쿠키

쿠키 : 정보가 적힌 텍스트

1. 김씨가 '빨간색'을 좋아한다고 서버에 말함
2. '빨간색을 좋아한다'는 정보를 담은 쿠키를 서버에서 보내면 김씨 클라이언트에 저장됨
3. 다음부터 김씨는 서버에 쿠키만 보냄
4. 다음부터 김씨는 빨간색을 좋아한다고 또 알릴 필요 없이 빨간색 웹사이트 볼 수 있음

단점 : 비밀번호 같은거 적어두면 탈취되면 큰일남 (= 보안 낮음)

 

세션

1. 김씨가 서버에 들어오면 서버가 김씨만을 위한 세션 ID(=daf2jkcg)가 적힌 쿠키를 보내줌
2. 다음부터 김씨는 서버에 쿠키만 보냄
3. 서버는 쿠키를 받아서 그 안에 있는 세션 ID가 세션 저장소에 있는지 확인
4. 김씨는 이제 비밀번호, 카드번호같은 거 또 입력할 필요 없이 서버에 저장된 정보 쓰면 됨

1. 다른 사람이 김씨라고 위장하고 서버에 들어왔음
2. 김씨는 그것을 알아차림
3. 서버에 요청해서 '김씨2'라는 세션 ID가 들어있는 쿠키는 못 들어가게 할 수 있음

단점 : 쿠키를 받을 때마다 거기 적힌 세션 ID가 유효한 건지 서버에 있는 세션 저장소에서 매번 검색을 해야 하니까 서버에 부하가 많이 감

 

JWT

토큰 : a358adsfbjncjkb0a0... 이렇게 생긴 문자열

토큰은 헤더, 페이로드, 시그니처로 나뉨

헤더 : 종류(JWT는 JSON), 인코딩한 알고리즘
페이로드 : 사용자 정보들 (해독 가능하니 중요한 거 넣으면 안됨)
시그니처 : 알고리즘, 서버 비밀키로 암호화해서 만든 서명 (이것 때문에 위조 불가)

1. 김씨가 서버에 들어오면 '김씨'라는 정보를 담은 토큰을 보내줌
2. 다음부터 김씨는 서버에 토큰만 보냄
3. 서버는 토큰을 분해해보고 유효한 토큰인지 아닌지만 확인함
4. 유효하면 김씨를 들여보내줌

단점 : 해커한테 토큰 털려도 그것만 만료시키는거 불가능

 

Access Token, Refresh Token

access token : 만료 기간 짧은 사용자 인증용 토큰
refresh token : 만료 기간 긴 토큰 갱신용 토큰. 서버에 검증용 저장소가 있음.

평소엔 access token으로 인증하다가
토큰이 털리면 refresh token을 만료시키면 됨

단점 : 평소엔 access token으로만 인증하니까 서버 부하 덜 가지만 어쨌든 refresh token을 쓸 때는 서버에 부하가 가해짐.