쿠키 : 유저
- 아이디 자동완성
- 쇼핑몰에서 로그인 안한 채로 장바구니담기
- 사용자의 편의를 위함
- 조작되어도 큰 문제가 없는 정보
세션 : 서버(관리자)
- 사용자의 민감한 정보, 조작되면 안되는 정보
- 세션에 담긴 정보가 많으면 서버 부하가 걸릴 수 있음
- 서버에서 만든다.
- 쿠키안에 세션 ID를 넣어서 클라이언트에게 Response 한다. 결국 세션도 쿠키를 사용하는 것이다.
- timeout을 업데이트
- 세션을 RAM DB에 저장해둔다.
- 사용자가 다시 로그인을 하면 쿠키와 세션 정보를 같이 서버에 보낸다.
- 내부 DB로 세션정보를 확인
- 트래픽이 많아지면 로드밸런서가 사용된다. 3개의 웹서버가 동작한다고 가정했을 때, 1번 서버에서 세션 ID를 발급받았는데, 이 세션 ID를 가진 사용자를 로드밸런서가 2번 서버로 보낸다면, 로그인을 못하는 것이다.
- 이를 방지하기 위해 로드밸런서는 한 유저는 한개의 서버로 계속 들어가도록 만들어주는 테크닉이 필요하다.
- 세션 전용 DB를 만든다.
- 어떠한 서버에 접속을 하든, 웹서버는 세션 DB에 접근하여 세션 ID를 가져온다.
- 이 DB 또한 마찬가지로, DB에 너무 많은 세션 ID가 들어가 있으면 찾는데 시간이 오래걸리므로 세션을 저장하는 DB를 여러개 만들게 되면 복잡하고 어려워진다. 또한 서버의자원을 사용하는 것이므로 메모리가 많아지면 속도가 느려진다.
- 이것 또한 DB가 많아지므로 문제가 생긴다. 이를 해결하는 것이 Token based 인증을 한다. 이게 JWT이다.
스파를 이용하는 시나리오
쿠키북을 사용 - 고객이 가지고 돌아다님(like 케베의 바코드 띠)
- 작성 가능. 한번 이용한 시설을 기록해둔다.
- 재방문 시 보여주기만 하면된다
- 내가 갖고 있음 → 남이 볼 수 있음(민감한 정보 X)
- 스파측에서 보관해야하는 정보는 기록 X(손님이 위변조 가능)
스파세션 - 스파측에서 보관
- 사용자의 행동을 저장
- 쿠키북에 저장하기 민감한 정보 저장
- 고객은 회원이다. 각 고객 구분
- 서비스 어떤걸 이용했는지 확인
쿠키+세션의 조합으로 로그인이 풀리지 않는 것임
쿠키를 지우고 새로고침 하면 로그인 풀림
쿠키를 사용하는 이유
HTTP 프로토콜이 connectionless, stateless한 특성이 있기 때문
connectionless
클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징
HTTP는 먼저 클라이언트가 request를 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 response를 보내고 접속을 끊는 특성이 있다.
헤더에 keep-alive라는 값을 줘서 커넥션을 재활용하는데 HTTP1.1에서는 이것이 디폴트다.
HTTP가 tcp위에서 구현되었기 때문에 (tcp는 연결지향,udp는 비연결지향) 네트워크 관점에서 keep-alive는 옵션으로 connectionless의 연결비용을 줄이는 것을 장점으로 비연결지향이라 한다.
statless
통신이 끝나면 상태를 유지하지 않는 특징
연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다.
쿠키와 세션은 위의 두 가지 특징을 해결하기 위해 사용한다.
예를 들어, 쿠키와 세션을 사용하지 않으면 쇼핑몰에서 옷을 구매하려고 로그인을 했음에도, 페이지를 이동할 때 마다 계속 로그인을 해야 한다. 쿠키와 세션을 사용했을 경우, 한 번 로그인을 하면 어떠한 방식에 의해서 그 사용자에 대한 인증을 유지할 수 있다.
Token Based Auth(JWT)
- 똑같이 Id와 pw로 접속하면 서버는 토큰을 발급해서 전달해준다.(Response)
- 이 때 토큰에 모든 정보가 담겨있다. ex) id, pw, 권한, 토큰 생성일자 등등
- 다음 요청은 토큰으로 요청을 보낸다(Request)
- 세션 ID를 제공하지 않는다.
- 클라이언트가 서버에 접속할 때는 토큰이 올바른지만 확인해준다.
- 토큰에 따라 권한을 준다.
JWT : JSON Web Token
헤더, 페이로드, 시그니처로 나뉨
- 헤더 : 어떤 알고리즘으로 암호화 되어있는지, 어떤 타입의 토큰인지에 대한 정보가 담겨있다.
- 페이로드 : 데이터에 해당하는 부분으로 이름, 토큰 발행시점 등이 적힘
- 토큰의 유효 기간이 적힘
- 수정 가능한 데이터
- 정보를 삭제, 추가 가능 → 최소화된 정보만 가져가는게 좋다.
- 시그니쳐 : 헤더와 페이로드를 넣어주고 암호화 되어있다.
- Claim 기반 토큰 개념
사용자가 id와 password를 입력하여 로그인을 시도
서버는 요청을 확인하고 secret key를 통해 Access token을 발급
JWT 토큰을 클라이언트에 전달
클라이언트에서 API 을 요청할때 클라이언트가 Authorization header에 Access token을 담아서 보냄.
서버는 JWT Signature를 체크하고 Payload로부터 사용자 정보를 확인해 데이터를 반환.
클라이언트의 로그인 정보를 서버 메모리에 저장하지 않기 때문에 토큰기반 인증 메커니즘을 제공.
- 인증이 필요한 경로에 접근할 때 서버 측은 Authorization 헤더에 유효한 JWT 또는 존재하는지 확인한다.
- JWT에는 필요한 모든 정보를 토큰에 포함하기 때문에 데이터베이스과 같은 서버와의 커뮤니케이션 오버 헤드를 최소화 할 수 있다.
- Cross-Origin Resource Sharing (CORS)는 쿠키를 사용하지 않기 때문에 JWT를 채용 한 인증 메커니즘은 두 도메인에서 API를 제공하더라도 문제가 발생하지 않는다.
- 일반적으로 JWT 토큰 기반의 인증 시스템은 위와 같은 프로세스로 이루어진다. 처음 사용자를 등록할 때 Access token과 Refresh token이 모두 발급되어야 한다.
==> 장점 : 별도의 인증 저장소가 필요 없음. MSA에 적합한 인증 및 인가 방법 제공
캐시
- 컴퓨터 메모리에 쓰이는 것과 비슷함
- 이미지나 css, js파일 등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것이다. → css나 js를 수정해도 캐시가 비어있지 않는 경우 반영이 안되는 것
- 정보를 다시 가져올 때 비용이 많이 들기 때문에 한번 받아온 데이터를 사용자의 컴퓨터 또는 중간 역할을 하는 곳에 임시저장
- 한번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있는데 이런 부분을 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 header에 캐시 만료시간을 명시하는 방법등을 이용할 수 있다.