일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- spring boot rest api
- 메이븐
- 스프링 에러
- REST API
- Oracle
- Spring REST API
- 자바스크립트 class
- 디자인 패턴
- Spring boot
- javascript
- 전자정부프레임워크
- egov
- spring boot error
- spring boot post api
- spring 에러
- 스프링
- Spring
- Intellij
- spring boot CRUD
- 오라클
- javascript 클래스
- 인텔리제이
- 전자정부 샘플
- javascript class
- 스프링부트 post api
- spring 설정 파일
- exceptiontransfer
- pom.xml
- 자바스크립트
- 자바스크립트 클래스
- Today
- Total
빵구의 개발 메꾸기
쿠키 vs 세션 vs 토큰 본문
<쿠키>
사용자가 사이트에 방문하는 경우 브라우저는 서버에 요청을 보낸다.
서버는 이 요청에 대해 사이트 정보에 대해 데이터를 보여주는 응답을 해준다.
브라우저에 쿠키를 저장한 후 해당 웹사이트에 접속할때마다 브라우저는 서버에 요청을 보낼 때
해당 쿠키도 함께 보낸다.
쿠키는 도메인에 따라 제한이 된다.
그리고 쿠키는 유효기간이 있다.
하루, 일주일, 한달 등 서버가 정한 기간에 따라 유효하다.
쿠키는 인증 뿐만 아니라 여러가지 정보를 저장할 수 있다.
예를 들어 웹사이트 언어설정을 바꾸면 서버는 쿠키를 주고 내가 선택한 언어를 저장한다.
다음에 해당 사이트에 방문하는 경우 브라우저는 서버에 쿠키와 요청을 서버로 보내고 서버는 쿠키가 기억해둔
언어설정의 페이지를 제공한다.
<세션>
Stateless는 서버로 가는 모든 요청이 이전 요청과 독립적으로 다뤄진다.
요청끼리의 연결이 없다.
요청이 끝나면 서버는 요청을 보낸 사용자가 누군지 잊어버린다.
요청할 때마다 사용자가 누군지 알려줘야하는데 이를 해결하기 위한 방법 중 하나가 세션이다.
로그인 하는 경우 사용자 정보를 입력하고 서버에 보낼 것이고 로그인이 성공적으로
이루어진다면 서버는 세션DB에 로그인한 사용자의 정보를 저장할것이다.
해당 세션에는 별도의 ID가 있다. 해당 세션 ID는 쿠키를 통해 브라우저로 돌아오고 저장이 된다.
브라우저는 세션ID를 갖고있는 쿠키를 서버에 보낸다.(쿠키는 자동으로 보내진다)
서버는 들어오는 쿠키를 보고 세션ID와 함께 오는 쿠키를 확인한다.
하지만 아직 서버쪽에서는 세션ID가 있는 쿠키를 지닌 요청이 있다는것만 안다.
서버는 받아온 세션ID를 가지고 세션DB를 확인할 것이고 여기서 서버는 요청한 사용자가 누군지
알 수 있다.
해당 요청이 끝나고 다른 페이지로 이동하게 되면 이 모든 프로세스는 반복이 된다.
사용자가 가지고 있는 것은 세션ID뿐이다.
쿠키는 세션ID를 전달하기 위한 매개체일 뿐이다.
세션을 이용해서 ios 혹은 android 앱을 만들 수는 있지만 쿠키는 브라우저에만 있기 때문에
앱쪽에서는 사용할 수 없다.
바로 이 경우에 토큰이 필요하다.
<토큰>
토큰을 사용해서 서버에 토큰을 보낸다.
토큰은 단순 문자열이다.
토큰을 서버에 보내고 서버는 세션DB에서 해당 토큰과 일치하는 사용자를 찾는다.
서버는 요청이 있을때마다 결국 DB에서 일치하는 사용자가 있는지 확인한다.
사용자가 늘어나게 되면 그만큼 DB 리소스는 중요해진다.
그렇기때문에 JWT가 존재한다.
JWT는 토큰형식이다.
JWT로 사용자 인증을 처리하게 되면 세션DB를 갖을 필요도 없고 그렇게 되면 서버는 요청하는 사용자에 대해
인증하기 위해 DB안에서 찾을 필요도 없게 된다.
로그인하는 과정은 같지만 서버쪽에서는 기존 세션DB에서 조회하는것이 아닌 로그인한 사용자의
ID를 가져다가 사인 알고리즘을 이용해서 사인을 한다.
그러고는 사인된 정보를 문자열 형태로 보낼것이고 쿠키는 길이 제한이 있지만 JWT는 제한이 없기 때문에 상당히 길다.
서버는 토큰을 받으면 해당 사인이 유효한지 체크하고 토큰이 유효하다면 서버는 사용자에 대한
인증을 성공처리한다.
JWT는 암호화 되지 않았다.
누구나 열어서 해당 내용을 볼 수 있다.
그렇기 때문에 비밀정보를 JWT안에 두면 안된다.
[정리]
세션의 장점은 로그인 된 사용자의 모든 정보를 저장한다.
따라서 해당 정보를 이용하면 새로운 기능들을 추가할 수 있다.
특정 유저를 쫓아내고 싶을 때 세션을 삭제하면 된다.
넷플릭스처럼 계정 공유 숫자를 제한 할 수 있다.
현재 로그인을 몇명이 했고 시청하는지 알 수 있다.
이 모든 건 서버에 누가 로그인 했는지 세션DB에 저장했기 때문이다.
이를 위해선 DB를 사고 유지해야되는데 사용자가 많아지면 많아질수록 DB도 커져야한다.
반면 JWT는 DB를 따로 살 필요가 없다.
하지만 세션마냥 강제 로그아웃을 시킬 수는 없다.
코로나때문에 진행중인 QR체크인은 JWT가 들어간 QR코드이다.
하지만 서비스가 더 커지고 사용자 계정을 좀 더 잘 관리하고 싶다면 세션을 활용하는게 좋을 것 같다.
쿠키 = 그냥 옮기는 시스템. 매개체
토큰 = 서버가 기억하는 이상하게 생긴 문자열
JWT = 정보를 갖고있는 토큰. DB 없이 검증 가능
'웹 개발 시 알아두면 좋은 개념' 카테고리의 다른 글
JSON VS XML (0) | 2022.04.18 |
---|---|
Library VS Framework (0) | 2022.04.17 |
HTTP 상태 코드 별 특징 (0) | 2022.04.15 |
Web Server VS Web Application Server (0) | 2022.02.22 |