JWT의 인증방식과 Session을 이용한 인증방식의 차이점을 구분하는데 이해가 바로 안되었고 막상 또 쿠키와 세션을 구분하라고 하면 유효기간의 차이 외엔 아무말도 못했다.
🍪 쿠키
서버가 유저에 대해 기억하기 위해 브라우저에 데이터를 저장하게 되는데 이 데이터를 쿠키라고 한다.
특징
- key-value 형태의 string이다.
- 서버가 유효기간을 정할 수 있다.
- 브라우저가 종료되어도 유지된다.
- 따로 요청이 없어도 브라우저가 서버에 request를 보낼때 자동적으로 서버에 전송된다.
- 도메인에따라 제한된다. ex) 유튜브에서 받은 쿠키는 유튜브에서만 주고 받고 가능
- 인증뿐 아니라 여러가지 정보를 저장할 수 있다. ex) 언어설정
- 공간제약이 있어서 엄청 긴 string을 보낼 수 없다.
동작 방식
- 유저가 페이지 요청
- 서버에서 쿠키를 생성한 후 응답한다.
- 브라우저에서 쿠키를 저장한다.
- 서버에서 정보를 처리해야하는 요청이 발생한다면 쿠키를 업데이트 한 후 응답한다.
📄 세션
브라우저에서 유저 정보를 관리하는 쿠키와 달리 서버에서 유저 정보를 관리한다.
특징
- 이용자가 많다면 서버의 성능이 매우 중요해진다.
- 유저의 정보를 서버에 두어 보안이 좋지만 서버가 무거워진다.
- 유저에게 유니크한 id를 주고 관리한다.
- 브라우저가 종료될때까지만 인증상태가 유지된다.
- 서버에는 중요한 유저의 정보가 모두 있지만 유저는 sessionID만 가지고 있다.
- 서버에 로그인되어있는 모든 유저의 정보를 저장하기 때문에 새로운 정보들을 추가할 수 있다. ex) 서버에서 강제 로그아웃 시키기
동작 방식
- 유저가 서버에 접속해 서버가 sessionDB에 해당하는 sessionID(유일한 id)를 생성해 받는다. 이 id는 쿠키를 통해 브라우저로 돌아오고 저장된다.
- 사이트에서 다른 페이지에 접속한다면 브라우저가 가지고 있는 id가 있는 쿠키를 서버에게 보낸다.
- 해당 쿠키에 있는 sessionId를 통해 sessionDB에 접속해 해당 id가 누구인지 찾은 후에 존재한다면 인증이 된다
토큰(JWT)
JSON Web Token의 약자이다.
토큰(정보의 일부를 이용해 서명 알고리즘을 이용해 암호화된)을 서버와 주고 받으며 그때마다 인증을 하기때문에 저장소도 필요하지 않다.
특징
- 서버가 정한 유효기간을 만족할때까지 계속 사용 가능
- 인증이 필요한 http통신에서 header에 담겨 보내진다.
- 유저를 인증하는데 필요한 정보를 토큰에 저장한다.
- header | payload | signature 로 구성되어있다.
- 공간제약이 없어 엄청 긴 문자열로 이루어져 있어도 괜찮다.
- 로그인된 유저의 정보를 컨트롤할 수 없다.
- ⭐️ 암호화된것이 아니다.
JWT의 정의는 정의서명 알고리즘을 이용해 암호화된 토큰이다. 근데 왜 암호화된것이 아닐까
우선 첫번째 JWT는 누구나 볼 수 있다는 점
따라서 암호화가 되었더라도 유저의 정보가 노출될 가능성 자체가 존재하게 된다.
두번째 알고리즘의 레인보우 테이블이 공개되어있다.
벡엔드에서 유저 정보를 받아 JWT를 만드는 과정에서 몇번의 암호화, 어떤 암호화 방식 등 사용할 수 있는 라이브러리를 사용한다.
이것은 공격을 마음을 먹은 해커에게 장벽이 되지 않는다.
레인보우 테이블이 존재하는 이상 언제든지 암호화를 풀어버릴 수 있다.
따라서 JWT에는 유저의 개인정보, 비밀번호 등의 중요한 정보를 넣지 않는 것이 바람직하다.
동작 방식
- 서버에 로그인 정보를 보낸다.
- 서버에 정해져 있는 사인 알고리즘을 이용해서 서명을 한 후 string 형태로 유저에게 보낸다.
- 이제 서버에 request를 보낼때 유저 정보 or 토큰을 보낸다.
이때 서버가 토큰을 받으면 해당 서명이 유효한지 체크한 후 유효하다면 인증을 완료한다.
