로그인 (쿠키, 세션 ,토큰) 에 대해서

http 통신은 stateless 하다 따라서 어떤 사용자가 접속했는지 알수 없고 이전에 어떤걸 했는지 알수없다

단지 이번요청에대한 응답만 해줄 뿐이다.

그러나 우리가 웹페이지를 이용하다보면 서버가 클라이언트의 정보에 대해 인지하고 있어야 적합한 기능들을 제공해줄수 있는경우가 더러있다. 관련 상품을 추천한다던지 기존설정을 유지한다던지 등등 있지만 가장 대표적인 부분은 로그인 상태에 대한 부분이다.

---

1.쿠키

- 클라이언트에서 로그인 관련 정보들을 입력후 요청한다.

- 서버에서 로그인관련 정보를 데이터와 비교후에 응답헤더의 쿠키에 로그인 관련정보를 담고 응답한다.

- 이후로 클라이언트의 요청의 요청헤더에는 쿠키가 심어진채로 요청이 들어가 서버에서 지속적으로 확인할수있다.

- 요청과 응답시에 클라이언트쪽에서는 withCredential:true 로 설정해줘야 쿠키를 주고 받을수 있게된다.

쿠키를 통해 들어온 아이디를 이용해 데이터베이스에서 조회한 이후 결과를 응답해주는 코드이다.

---

2.세션

- 쿠키의 경우 로그인 관련정보가 브라우저나 디바이스를 통해 열람할수 있게된다. 이러한 점은 보안적으로 약점이다.

- 세션의 경우 쿠키를 사용하긴 하지만 쿠키에 로그인관련정보들을 담아서 보내주는 것이아니라 관련정보들은 따로 서버쪽에 저장을 해두고(세션스토리지) 저장한 위치를 id로 만들어서 쿠키로 전송해준다.

-이후 요청시마다 쿠키에 세션id 값이 딸려서 들어오고 그 id 를 통해 세션스토리지를 확인

하고 관련정보를 확인할수있게된다.

- 쿠키의 경우 만료시간 설정이전에는 영구적이지만 세션의 경우 브라우저 종료시 저장된 값이 사라진다라는 차이가 있다.

요청의 세션을 바로 확인하는거처럼 보이지만 이과정은 쿠키에서 세션아이디를 확인하고 세션아이디를 이용해 세션스토리지에서 조회하는 과정이 모듈화 되어있는 코드이다.

---

3.토큰

-세션의 경우 서버가 여러개인 경우 문제가 되는데 이때 저장된 정보가 모든 서버에 있는것이 아니라 곤란한 경우가 생긴다.

-따로 데이터 베이스에 관리를 하게 되면 매 요청시마다 데이터베이스를 조회해야 되기때문에 과부하가 생길 위험이 있다. 그로인해 나온것이  토큰이다.

- 클라이언트 요청에 데이터베이스를 조회후 확인한다.

- 관련정보를 페이로드에 담고 사용자마다 고유한 id 를 설정해 같이 페이로드에 담는다. 

- 해당정보를 암호화 하여 토큰으로 만들어 클라이언트로 보내주게 된다.

- 클라이언트는 인증이 필요할때마다 가지고 있던 토큰과 같이 요청을 전송한다.

- 서버측은 해당토큰을 검증한 이후에 원하는 데이터를 보내줄수 있다.

- 이때 위에서 토큰은 access token 을 이야기 하는데 이때 payload 에 데이터가 암호화가 되있긴 하지만 탈취당할 위험이 있기때문에 유효한 시간을 짧게 설정을 해놓는다 그렇게 되면 로그인을 자주해야하는 번거로움이 생기게 되는데 그것을 보완하기 위해서 access token 을 발급할대 refresh 토큰으 함께 발급해 access token 만료시에는 refresh 토큰을 이용해 토큰을 재발급 받을 수있게 할수도 있다.

토큰을 헤더에 실어서 보낼때 코드이다.