HTTP의 특성

• 인터넷 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜.
• 클라이언트가 서버에게 요청을 보내면, 서버는 응답을 보냄으로써 데이터를 교환한다.
• 비연결성, 무상태성
  • 때문에 클라이언트 식별이 불가능하다. (새로고침할 때마다 로그인 해야함)
  • 이 문제를 해결하기 위해 쿠키가 등장했다.

Cookie

• 클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트의 서버를 통해 클라이언트의 브라우저에 저장되는 작은 기록 파일. (소유주가 클라이언트)
• 로그인등의 요청에 대한 응답으로 서버가 응답 헤더의 set-cookie 에 클라이언트 정보를 담아 클라이언트로 전송한다.
• 이후 클라이언트가 서버로 요청을 보낼 때마다 헤더에 set-cookie 정보를 담아 전송하여, 서버가 클라이언트를 식별한다.

단점

• 클라이언트측에 저장 되므로 보안에 취약하다. (데이터 전달 도중 누군가가 악의적으로 데이터를 해킹할 수 있다.)
• 용량 제한이 있어, 많은 정보를 담을 수 없다.
• 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기에, 브라우저 간 공유가 불가능하다.
• 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해진다.

Seesion

• 클라이언트의 인증 정보를 쿠키가 아닌 서버 측에 저장하고 관리한다.

인증 과정

1. 서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 때, 인증 정보는 서버에 저장하고, 클라이언트 식별자인 **JSESSIONID(세션ID)**를 쿠키에 담는다.
   • 세션ID : 각 사용자마다 고유한 세션 ID 발급
2. 이후 클라이언트는 요청을 보낼 때마다 JSESSIONID쿠키를 함께 보낸다.
3. 그리하면 서버는 JSESSIONID의 유효성을 판별해 클라이언트를 식별한다.

장점

• 서버가 클라이언트의 웹 브라우저에 의존하지 않아도 된다.
• 쿠키를 포함한 요청이 외부에 노출되어도 세션 ID 자체는 유의미한 개인 정보를 담지 않는다.

단점

• 해커가 세션 ID를 중간에 탈취하여 클라이언트인 척 위장할 수 있다.
• 서버에서 세션 저장소를 사용하기 때문에, 요청이 많아지면 서버에 부하가 생긴다.

Token

• 토큰 기반 인증은 JWT이다. (Json Web Token)
• JWT 기반 인증은 쿠키/세션 방식과 유사하게 JWT 토큰(Access Token)을 HTTP 헤더
  에 실어 서버가 클라이언트를 식별한다.
• JWT의 구조는 Header, Payload, Signature 세가지 문자열의 조합이다.
• 인코딩, 디코딩 과정에서 서버에서 직접 지정한 Secret Key를 섞기 때문에 쿠키와 세션에 비해 보안이 강하다.

인증 과정

1. 로그인 등으로 서버는 인증 정보를 검증 후 클라이언트 고유 ID등의 정보를 Payload에 담는다.
2. 암호화할 비밀키를 사용해 Access Token(JWT)을 발급한다.
3. 클라이언트는 전달받은 토큰을 저장해두고, 서버에 요청할 때마다 토큰을 요청 헤더 Authorization에 포함시켜 함께 전달한다. (bearer token..)
4. 서버는 토큰의 Signature 을 비밀키로 복호화한 다음, 위변조 여부 및 유효 기간 등을 확인한다.
5. 유효한 토큰이라면 요청에 응답한다.

장점

• Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
• 인증 정보에 대한 별도의 저장소가 필요 없다. (I/O 처리 필요 없음)
• JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됐음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.

단점

• 쿠키, 세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많을수록 네트워크 부하가 심해진다.
• Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다. (패스워드 등)
• 특정 사용자의 접속을 강제로 만료하기 어렵다. (쿠키/세션 기반 인증은 서버 단에서 쉽게 삭제할 수 있지만 토큰은 그게 안 됨)
  • 때문에 토큰의 만료기한을 짧게 설정하는 것이 일반적이다.

Access Token, Refresh Token

• 로그인 요청을 진행한 후, 서버는 클라이언트에게 Access Token과 Refresh Token을 전달한다.
• Access Token
  • 인증이 필요한 요청을 보낼 때 헤더에 담아보내는 인증 토큰
  • 유효기간이 짧다
• Refresh Token
  • Access Token이 만료된 경우 이 토큰을 헤더에 담아 보내 새로운 Access Token을 발급 받음
  • Refresh Token이 만료된 경우 사용자는 다시 로그인을 해야한다.
  • 유효기간이 비교적 길다

레퍼런스

https://velog.io/@whitebear/쿠키, 세션, 토큰(JWT) 몰라도 괜찮겠어?