쿠키와 세션, 그리고 JWT

쿠키와 세션

둘 다 사용자 데이터를 저장하는 데 사용한다. 구체적인 사용처로는 로그인 유지 기능, 자동 로그인 기능, 쇼핑몰의 장바구니 기능 등이 있다.

웹 브라우저가 종료되어도 유지되는 것(웹 브라우저가 종료되어도 자동 로그인 가능, 쇼핑몰의 장바구니) -> 쿠키로 구현

웹 브라우저가 종료되면 정보가 사라지는 것(웹 브라우저 종료 전까지 로그인 유지, 쇼핑몰의 장바구니) -> 세션으로 구현

자동 로그인 기능의 경우에는 JWT의 Access Token, Refresh Token 방식으로도 구현이 가능하다. -> 쿠키에 토큰 담기

	쿠키	세션
데이터 저장 장소	로컬	서버 로컬(쿠키)에서는 세션 ID만 가지고 있음
데이터 전송	매번 모든 쿠키를 서버로 전송	매번 세션 ID만 서버로 전송
생명 주기	개발자가 설정한 유효 기한	웹 브라우저의 종료
보안	추후 작성	추후 작성

 

JWT(JSON Web Token)

Key:Value 쌍으로 이루어진, 웹에서 사용되는 토큰이다. 나의 경우 자동 로그인 기능 구현에 사용하였다. 그러므로 이 경우에 대해 자세히 설명하겠다.

 

Access Token과 Refresh Token을 이용한 자동 로그인

1. Client: 사용자가 ID, Password를 이용해 로그인 성공
2. Server: Access Token(유효 기한 짧음, 분 단위)과 Refresh Token(유효 기한 비교적 김, 일주일 단위) 발급. Refresh Token의 경우 쿠키와 DB에 저장(나의 경우 RDBMS의 Member 테이블에 저장, 많은 경우 Redis 등의 NoSQL 사용하는 것으로 알고 있음)
3. Client: 쿠키에 Access Token과 Refresh Token 저장
4. Server: Client로부터 요청을 받을 때마다 Access Token이 유효한지 확인, 만약 유효하지 않다면 쿠키에 저장된 Refresh Token이 존재하는지 확인하고, 만료되지 않았는지 확인한다. 예외가 발생하지 않았다면 쿠키에 저장된 Refresh Token을 기준으로 DB의 Member 테이블을 검색하여 해당하는 Member가 존재하는지 확인하고, 만약 존재한다면 해당 Member 정보로 Access Token을 재발급한다.

Access Token과 Refresh Token을 이용한 로그아웃

1. Client: 로그아웃 요청
2. Server: 쿠키에 저장된 Refresh Token을 조회하여 DB에 저장된 해당 Refresh Token 삭제

내가 생각하기에 이러한 구현 방식의 단점은... DB의 Member당 Refresh Token 값을 하나씩밖에 저장하지 못하기 때문에 자동 로그인은 한 곳에서밖에 유지되지 못한다. 예를 들면, 하나의 브라우저에서 자동 로그인을 설정하고, 다른 브라우저에서 자동 로그인을 다시 설정하면, 처음 자동 로그인을 설정한 브라우저의 자동 로그인이 풀리는 현상이 일어난다. 내가 자주 이용하는 모 사이트가 이러한 문제를 갖고 있는데, 그 사이트도 이런식으로 구현되어 있는 것으로 추측된다. 이러한 문제를 방지하기 위해서 Refresh Token을 Key로 하고, Member Id 등의 Unique Key를 Value로 하는 Key:Value 쌍을 DB에 저장해두고 Refresh Token을 기준으로 Member를 조회하여 Member 정보를 가지고 Access Token을 재발급하는 것이 가장 이상적으로 보인다. 이러한 Key:Value 방식에 딱 맞는 DB가 Redis이다. Redis는 적은 용량의 데이터를 빠른 속도로 조회하는 데 좋은 성능을 보이기 때문이다. 그래서 로그인 관련 JWT 구현에 Redis를 많이 사용하는 것 같다.

 

---

프로젝트를 진행하며 강의, 글 등을 참고하여 직접 구현해보며 깨달은 점을 정리해본 것입니다. 제 지식이 늘어나는 대로 내용이 수정되거나 추가 글이 작성될 수 있습니다...