HTTP 통신은 요청과 응답으로 정보를 주고받는데, 이 과정이 종료되면 그 상태가 유지되지않는 비연결적인 특징을 갖기 때문에 만약 로그인 작업을 할 때 누가 로그인 중인지 그 상태를 기억하지 못하는 일이 발생했다. 이를 해결하기 위해 등장한 것이 쿠키, 세션, 토큰과 같은 개념들이다.
쿠키,세션, 토큰은 왜 등장했을까
- Connectionless => 쿠키 등장
- Stateless => 세션,토큰 등장
쿠키🍪
사용자에 관한 정보를 기억하기 위해 쿠키를 이용해 브라우저에 데이터를 저장
HOW?
- 서버는 클라이언트에게 response를 보낼 때 본문에 아래 데이터를 보낸다.
- 방문한 페이지에 관한 정보
- 서버가 브라우저에 저장하고자 하는 쿠키 (set-cookie)
- 기타정보
- 브라우저에 쿠키를 저장한 후에는 해당 웹사이트를 방문할때마다 (재요청) 저장된 쿠키를 헤더의 cookie에 담아보낸다.
- 서버는 쿠키에 담긴 정보를 바탕으로 클라이언트 식별
세션🔒
HTTP는 stateless하기 때문에 이전 요청과 독립적이다. 즉, 이전에 이루어졌던 요청에 대한 메모리는 해당 요청이 끝나면 전부 없어진다. 그럼 우리는 같은 웹사이트에 접속할 때마다 우리가 누구인지 알려줘야하는데, 이걸 알려주는 방식 중 하나를 세션이라고 한다.
세션은 비밀번호와 같은 인증정보를 쿠키에 저장하지 않는 대신 사용자의 식별자인 session id를 저장하여 서버에 인증정보 + 이 id에 해당하는 사용자의 정보를 저장한다.
사용자들의 정보를 기억하기 위해서는 세션을 계속 유지해야하는데 이를 위해 메모리/디스크 또는 DB를 이용한다.
토큰🔐
쿠키는 브라우저에만 있기 때문에 네이티브 앱에서는 쿠키를 주고 받는 방식을 사용할 수 없게 된다. (쿠키 컨테이너 사용 제외.) 이 경우에 토큰을 사용하여 서버에 정보를 보낸다.
토큰을 전달받은 서버는 세션DB에서 해당 토큰과 일치하는 유저를 찾는 방식으로 로그인과 같은 작업을 실행할 수 있게한다.
JWT (Json Web Token) 인증방식
하나의 토큰 형식, JWT로 유저 인증을 처리하면 서버에 세션DB를 가지고 있을 필요가 없고 서버는 유저 인증을 위해 많은일을 하지 않아도 된다.
JWT vs 세션
세션의 장단점 Ex)넷플릭스
- 세션DB에 저장된 유저의 모든 정보를 이용하여 계정을 활용한 새로운 기능 추가 가능
- 세션DB의 관리가 어려움. (비용적인 문제는 redis DB로 해결)
- 분산된 시스템 설계가 불가능은 아니지만 너무 복잡하여 확장성이 안좋음
- CORS ; 쿠키는 단일/서브 도메인에서만 작동하여 여러 도메인에서 관리가 번거로움 (네이티브 앱에서 쿠키 사용불가)
JWT의 장단점 Ex)QR체크인
-
DB 따로 구축할 필요 없음
-
header와 payload로 signature 생성하므로 데이터 위변조 막을 수 있다.
-
토큰이 한 번 발급되면 유효기간 만료 시까지 사용이 가능
-
토큰을 사용하여 다른 서비스에서도 권한 공유 가능 , 토큰에 선택적인 권한만 부여하여 발급이 가능
= JWT는 토큰에 대한 기본정보와 전달한 정보, 토큰이 검증되었다는 서명 등 필요한 정보를 자체적으로 지니고있음.예를 들어 로켓펀치에서 페이스북 계정으로 로그인 -> 프로필정보를 가져오는 권한은 있지만, 포스트 작성 권한은 없음.
즉 토큰을 사용하면 디바이스와 도메인에 상관없이 토큰만 유효하다면 요청을 정상적으로 처리해줌
- 서버는 생성된 토큰을 추적하지 않고 토큰이 유효한가? 의 여부밖에 알 수 없기 때문에 기능 추가 불가능
토큰의 구조
헤더
Base64 URL-Safe 인코딩된 문자열인 JSON 객체로 JWT를 어떻게 검증하는가에 대한 내용
alg : 서명시 사용하는 알고리즘, kid : 서명시 사용하는 키를 식별하는 값
payload
JWT의 내용, 페이로드에 있는 속성들을 클레임 셋이라고 부름.
클레임 셋은 토큰 생성자의 정보나 생성일시 등 클라와 서버 사이에 주고받기로 한 데이터들로 구성
signature
점(.)을 구분자로 헤더와 페이로드를 합친 문자열을 서명한 값
서명은 헤더의 alg에 정의된 알고리즘과 비밀 키를 이용해 생성하고 Base64 URL-Safe로 인코딩
보안전략🔑
- 만료기한을 짧게 설정한다
- 서비스를 지속적으로 이용하는 클라이언트에겐 자동으로 토큰 만료기한을 늘려준다 (Sliding Session)
3.Access Token과 Refresh Token의 구별
; 클라이언트가 로그인 요청을 보내면 서버는 Access Token과 그보다 만료기간이 긴 Refresh Token을 함께 보내줌으로써 Access Token이 만료되었을 때 클라이언트는 Refresh Token을 이용하여 Access Token의 재발급을 요청함.
즉, 서버에 Refresh Token을 별도로 저장하여 비교하고 새로운 Access Token을 발급
정리
- 쿠키 : 정보를 옮기는 매개체
- 토큰 : 서버가 기억하는 텍스트형식(?), 서버에게 보여줘야 하는 것
- JWT : 정보를 가지고 있는 토큰, DB가 없어도 검증할 수 있음.
참고👍
https://blog.naver.com/gpalstksxk/222623551030
https://velog.io/@jung5318/%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-%ED%86%A0%ED%81%B0%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90
