클라이언트와 서버는 주로 HTTP 프로토콜을 이용해 통신한다.
Http
Http의 대표적인 특징으로는 connectionless, stateless가 있는데, 비연결지향성과 무상태성이다. 이러한 Http의 특징으로 인해 클라이언트 - 서버 통신간 클라이언트의 상태 유지를 별도로 해주어야한다.
😇 클라이언트 상태 유지
대표적인 방법으로는
- 쿠키
- 쿠키+세션
- JWT
가 있다. 하나씩 알아보자.
🍪 쿠키
- Cookie는 클라이언트의 요청, 서버의 응답 객체에 내장해 전달할 수 있는
key-value 형식의 객체이다. - 서버에서 클라이언트의 정보를 쿠키에 담아 응답을 보내면, 클라이언트는 해당 쿠키를 다음 요청에 담아 보내면 서버는 클라이언트를 특정할 수 있게 된다.
- 쿠키 생성시에 쿠키 생명 주기, 적용 도메인 등을 설정할 수 있다.
Cookie cookie = new Cookie("Key", "Value");
response.addCookie(cookie);장점
- 별도의 알고리즘 없이, 바로 요청/응답 객체에서 쿠키 값을 꺼내기만 하면 되니, 빠르고 간단하다.
단점
- 네트워크 중간에서 쿠키를 탈취 당하게 된다면, 탈취 당한 쿠키로 인해 개인 정보 유출의 위험이 있다.
해결책
- 쿠키가 탈취당하지 않을 수 있게 두 가지 설정을 할 수 있다.
cookie.setHttpOnly(true);- 서버로 HTTP Request 요청을 보낼때만 쿠키를 전송한다.
- document.cookie와 같은 자바스크립트로 쿠키를 조회하는 것을 막는다.
(브라우저에서 개발자 도구 -> 콘솔 -> document.cookie검색)
cookie.setSecure(true);- 브라우저와 서버가 HTTPS로 통신하는 경우에만 웹브라우저가 쿠키를 서버로 전송한다.
- 쿠키에는 개인정보를 담지 않도록 한다.
- 개인정보를 유추할 수 있는 정보를 담지 않도록 한다.
Https 프로토콜 아래에서의 쿠키
- 위 서버는 들어온 요청에 대해 쿠키에 담아 보내게 되는데, document.cookie에서 나오지 않게 된다. (HttpOnly)
- 쿠키 정보에 HttpOnly와 Secure 모두 활성화돼있는 것을 확인할 수 있다.
🍪 쿠키 + 📚 세션
세션
-
Session이란, WAS(Web Application Server)에 생성되는 클라이언트 상태 유지를 위한 정보이다.
-
WAS에서 들어온 요청에 대한 상태 유지를 위해 임의의 값으로 세션 id를 만들어 세션 저장소에 관리하게 된다.
-
Tomcat은 클라이언트에 대해 임의의 세션 id를 생성하고, 세션 저장소에 저장한 뒤에, 쿠키에 세션 id를 담아 응답하게 된다.
세션 저장소에 세션 정보를 저장한 뒤, 쿠키를 통해 세션 정보를 주고 받게 된다. 이때 https에서만 쿠키가 사용될 수 있도록 설정하도록 하자!
❓ JWT (JSON Web Token)
JWT란,
-
사용자 인증을 돕는 토큰 (Token) 으로 서버에서 특정 키를 이용해 발급해 클라이언트에게 제공한다.
-
주로 Http Header에 포함시켜 인증을 하게 된다.
-
Header / Payload / Signature 로 구성된다.
Header
Header에는 토큰의 타입(JWT)과 사용할 해시 알고리즘 종류(HS256)가 담겨져있다.
- 해시 알고리즘으로 base64Encode(Header) + base64Encode(Payload) + 서버의 signing key 를 암호화하게 된다.
Payload
Payload에는 사용자의 데이터가 담겨져 있다.
- 토큰 발급 시간, 만료 시간 등이 포함되기도 한다.
Signature
Signature에는 [base64Encode(Header).base64Encode(Payload).서버의 signingKey ]가 담겨 있고,
해당 값을 Header에 명시된 해시 알고리즘으로 암호화한 값을 사용하게 된다.
JWT 인증 과정
- 클라이언트는 JWT를 Http Header에 포함시켜 request를 보낸다. [
Header.Payload.Signature] 형식 - 서버는 JWT의
Header.Payload+ 서버의 signingKey 를 Header에 명시된 해시 알고리즘으로 암호화한다. - 암호화한 전자서명 (Signature)이 JWT의 Signature와 같은지 확인한다.
장점
- 토큰을 쿠키나 세션처럼 서버에 저장하지 않고, 클라이언트에서 저장하게 되어, 서버에 부담이 줄어든다.
- 이에 따라 무제한 확장이 가능하다.
- 클라이언트에게는 유일한 토큰이 발급되게 된다.
단점
- 토큰의 탈취당하면, 대처하기 어렵다.
- 탈취에 대비하기 위해, 토큰의 생명 주기를 짧게 설정하기도 한다.
- Payload는 암호화되지 않기 때문에 유저의 중요한 정보를 담을 수 없다.
- user의 저장 index를 주로 사용한다.
