[WIL] cookies, sessions, JWT

📌 HTTP 통신

"로그인" 이라는 과정은 서버와 클라이언트가 데이터를 주고 받는 통신 방법이 필요하다.
그 통신 방법이 HTTP 라는 프로토콜(통신 방법)이다.
HTTP에는 몇 가지 특성이 있다.

• connectionless : HTTP는 연결을 유지하지 않는다라는 특성.
  서버와 클라이언트가 한번 통신이 일어나고 나면 그 연결이 유지가 되는 것이 아니라 바로 끊어진다.
• stateless : HTTP는 상태를 유지하지 않는다라는 특성.
  서버와 클라이언트는 첫번째 통신을 하고 나서 두번째 통신을 할 때는
  이전의 통신에 대한 정보를 가지고 있지 않기 때문에 새롭게 갱신을 해주어야 한다.

위의 특성들 때문에 우리가 "로그인"을 구현하는데 많은 어려움이 있다.
사용자가 매번 서버에 요청을 보낼 때 마다
자신이 누구인지 계속해서 인증을 해주어야 한다는 것.
매번 서버에 사용자가 누구인지 인증을 하는 과정은 번거롭고 귀찮을 뿐만 아니라
매번 요청을 보내야 하기 때문에 우리의 웹페이지가 느려지는 원인이 된다.
이러한 원인과 이유로 우리는
사용자가 누구인지 계속해서 인증을 하는 방법 대신
로그인 정보를 유지시킬 방법이 필요했다. (=> Sessions vs Tokens)

Sessions 세션

접속한 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 일정하게 유지시키는 기술이다. (서버 유지)
여기서 일정 시간은 방문자가 웹 브라우저를 통해
즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다.

세션 특징

1. 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.
2. 웹 서버의 저장되는 쿠키(=세션 쿠키)
3. 브라우저를 닫거나, 서버에서 세션을 삭제했을때만 삭제가 되므로,
   쿠키보다 비교적 보안이 좋다.
4. 저장 데이터에 제한이 없다.(서버 용량이 허용하는 한...)
5. 각 클라이언트 고유 Session ID를 부여한다.
   Session ID로 클라이언트를 구분하여 각 클라이언트 요구에 맞는 서비스 제공

세션의 동작 순서

1. 클라이언트가 페이지를 요청한다. (사용자가 웹사이트 접근)
2. 서버는 접근한 클라이언트의 Request-Header 필드인 Cookie를 확인하여,
   클라이언트가 해당 session-id를 보냈는지 확인한다.
3. session-id가 존재하지 않는다면,
   서버는 session-id를 생성해 클라이언트에게 돌려준다.
4. 서버에서 클라이언트로 돌려준 session-id를 쿠키를 사용해 서버에 저장한다.
   쿠키 이름 : JSESSIONID
5. 클라이언트는 재접속 시,
   이 쿠키(JSESSIONID)를 이용하여 session-id 값을 서버에 전달

사용 예시

화면이 이동해도 로그인이 풀리지 않고 로그아웃하기 전까지 유지

단점

토큰방식보다 보안에 강하다는 장점이 있지만
단점으로는 서버의 확장성이 떨어지고, 서버의 자원(세션을 저장, 유지할 공간)이 많이 필요하다.
또한 세션이 서버에 저장이 되고, 트래픽 분산을 위해서 여러 대의 서버를 사용할 때
만약 사용자가 로그인을 했을 때는 만들어진 세션을 참조해야 하기 때문에
처음 로그인한 그 서버에서만 요청을 보내야 한다는 단점이 있다.

Cookies 쿠키 🍪

HTTP의 일종으로 사용자가 어떠한 웹 사이트를 방문할 경우,
그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일이다.
HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가
필요시 정보를 참조하거나 재사용할 수 있다.

서버가 브라우저에 데이터를 넣을 때 쿠키를 이용함
사이트에 방문하면 브라우저는 서버에 요청을 보낸다. (request)
서버는 이에 응답한다. (response) - 내가 찾던 페이지 정보 등 데이터
일단 브라우저에 쿠키를 저장한 후 해당 웹사이트를 방문할 때마다 브라우저는 해당 쿠키도 요청 함께 보낸다.
! 쿠키는 도메인에 대해 제한되고 서버가 정한 기간 만큼의 유효기간이 있다.
쿠키에는 인증뿐만 아니라 여러 정보를 저장할 수 있다.

쿠키의 동작 순서

1. 클라이언트가 페이지를 요청한다. (사용자가 웹사이트 접근)
2. 웹 서버는 쿠키를 생성한다.
3. 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때,
   같이 클라이언트에게 돌려준다.
4. 넘겨 받은 쿠키는 클라이언트가 가지고 있다가(로컬 PC에 저장)
   다시 서버에 요청할 때 요청과 함께 쿠키를 전송한다.
5. 동일 사이트 재방문시 클라이언트의 PC에 해당 쿠키가 있는 경우,
   요청 페이지와 함께 쿠키를 전송한다.

사용 예시

1. 방문했던 사이트에 다시 방문 하였을 때 아이디와 비밀번호 자동 입력
2. 팝업창을 통해 "오늘 이 창을 다시 보지 않기" 체크

Tokens 토큰 방식 (클라이언트 유지)

사용자가 로그인을 하면 서버에서 발행해주는 토큰을 가지고
브라우저의 저장소에 토큰을 유지시키는 방법.
요기서 말하는 토큰이 우리가 말하는 JWT이다.
서버에 저장하지 않아서 서버에 확장성이 있다.
위에서 말했듯 로그인을 했을 때 해당 서버에만 요청을 보내는 것이 아닌
요청이 들어왔을 때 해당 토큰이 유효한지만 체크하면 되기 때문에
어떤 서버로 요청을 보내도 상관이 없다는 뜻이다.

🪙 JWT(JSON Web Token)

JWT는 두 개체 사이에서 안정성있게 정보를 교환하기 좋은 방법
JWT는 우리가 위에서 계속 말한 웹 토큰, JSON Web Token의 약자이다.
JWT는 웹표준 (RFC 7519)으로,
전자 서명 된 URL-safe (URL로 이용할 수있는 문자 만 구성된)의 JSON이다.

1. header

헤더(Header)에는 JWT를 어떻게 검증하는지에 대한 내용이 들어가 있다.
토큰의 타입, 암호화 알고리즘이 어떤 알고리즘인지에 대한 정보가 들어있다.
해시 알고리즘의 이름을 적어줄 수 있다.

2.payload

토큰에 담아서 우리가 보내고자 하는 데이터가 이곳에 담겨져 있다.
이 정보의 조각은 클레임(claim) 이라고 하고, key - value의 한 쌍으로 이루어져 있다.
그리고 payload에는 여러 개의 클레임을 담을 수 있고, 클레임을 공개(public) 혹은 비공개(private) 할 것인지 등록(registered)할 것인지 결정할 수 있다.

3.signature

시그니처(signature)에는 위의 헤더(header)와 페이로드(Paylaod)를 합친 문자열을 서명한 값이다.
서명은 헤더의 alg에 정의된 알고리즘과 secret key를 이용해 생성하고
Base64 URL-Safe로 인코딩한다.
secret key를 포함해서 암호화가 되어있다.

📌 JWT의 장단점

• 장점

  세션 방식과 다르게 별도의 인증 저장소가 필요 없어서 서버와의 커뮤니케이션을 최소한으로 할 수 있다.
  트래픽에 대한 부담이 적다.
  세션과 다르게 독립적인 느낌의 JWT를 활용한다는 것.

• 단점

  JWT의 크기가 커질수록 거의 모든 요청에 대해 전송되므로 데이터 트래픽 크기에 영향을 미칠 수 있다.
  토큰은 클라이언트에 저장되기 때문에 DB에서 사용자 정보를 수정하더라도 토큰에 직접 적용할 수 없다.

HTTP의 connectionless, stateless 특성에 의해
로그인 정보를 유지시키기 위해서 알맞은 유지 방법이 필요했다.
JWT는 암호화, 복호화를 통해 두 개체 사이에서 정보를 안전하게 주고 받을 수 있는 좋은 수단이다.

필요한 API

Refresh API
새로고침, AccessToken 만료시에 호출 (setTimeout으로 자동 호출 설정 가능)
RefreshToken을 쿠키에서 읽어와서 서버로 보냄
RefreshToken,AccessToken을 다 받아올지 AccessToken만 받아올지는 선택
Login API
로그인 시 호출
RefreshToken,AccessToken 을 받아옴
API 호출 후
AccessToken는 header에 default로 설정하여 API마다 보내도록 설정
AccessToken의 유효기간이 끝나기 전 자동으로 Refresh API가 호출되도록 설정 가능 (선택적)
RefreshToken는 쿠키에 저장
- RefreshToken 또한 기간이 만료되면 재로그인이 필요

참고

https://velog.io/@junghyeonsu/프론트에서-로그인을-처리하는-방법

Week01 회고

기초적인 개념도 안 잡혀 있는 상태에서 미니프로젝트를 시작하고 완성했다.
그나마 쉬운 로그인 페이지를 맡아서 강의를 따라가면서 JWT에 대해 알게 되었다.
이미 공부를 많이 하고 온 팀원들은 자연스럽게 용어를 쓰면서 말하는데 나는 몰랐기 때문에 모든 내용을 알아들을 수 없어 말미잘이 된 기분이었다...
알아봐야 할 것들은 메모장에 빠르게 적어 놓고 회의가 끝나면 찾아보곤 했다.
그래도 포기하지 않을 생각인 건 알아가는 재미와 기쁨이 크다는 것 때문 🌮
팀원들과 주제 정하는 것부터 누가 뭘 만들지 배분하는 것, git을 이용해 파일을 주고받고 코드가 합쳐지는 과정을 본 것들이 큰 배움이었다.
새로운 팀원들과의 알고리즘 주차가 시작됐는데 미니 프로젝트 할 때보다 훨씬 재미있다.
에러가 나면 구글링해서 고치고 또 고치고 하다가 실행됐을 때 기쁨이 크다.🧃