TIL - cookie, session, token(JWT)
1. cookie
이전에 우리는 http 요청이 stateless 해서 사용자의 정보나 통신 상태가 저장되지 않는다고 배웠다. 그런데 어떻게 로그인 상태 등을 알 수 있을까?
바로 '쿠키'를 사용하기 때문이다!
쿠키란 웹사이트에 들어갔을 때 서버가 일방적으로 클라이언트에게 전달하는 작은 데이터이다. 서버가 웹 브라우저에 사용자 정보를 저장하고 불러올 수 있는 수단이다. 따라서 클라이언트에 접속 상태가 저장된다.
[작동방식]
(1) 서버가 Set-Cookie라는 프로퍼티에 쿠키의 값, 경로 등의 옵션을 저장하여 클라이언트에게 보낸다.
(2) 쿠키가 담긴 응답을 받은 클라이언트는 응답헤더에 존재하는 Set-Cookie를 확인한다.
(3) 그 다음부턴 매 요청시마다 쿠키의 이름과 값을 서버에게 전달한다.
즉, 서버가 쿠키를 한 번 저장하면 클라이언트는 그 이후로 해당 웹 사이트를 이용할 때 매 요청에 자동으로 쿠키가 함께 전송한다. 그렇게 때문에 쿠키 내용을 바탕으로 서버는 로그인을 유지, 테마 유지 등을 할 수 있다.
쿠키에 담을 수 있는 옵션들은 다음과 같다.
(1) Domain: 서버와 요청의 도메인이 일치하는 경우 쿠키 전송한다.
(2) Path: 서버와 요청의 세부경로가 일치하는 경우 쿠키 전송한다.
(3) MaxAge or Expires: 쿠키의 유효기간 설정한다.
(4) HttpOnly: 스크립트로 쿠키를 접근할 수 있는지 설정한다.
(true라면 접근 불가하다.)
(5) Secure: HTTPS 프로토콜에서만 쿠키 전송 여부를 결정한다.
(6) SameSite: CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부를 결정한다.
-- Lax: GET 메서드 요청만 쿠키 전송 가능하다.
-- Strict: 도메인, Path, Secure 모두 일치해야만 쿠키 전송 가능하다.
-- None: 모든 메서드 요청에 대해 쿠키 전송 가능하다.
그러나 쿠키는 특별한 이유가 없으면 영원히 저장된다는 특징이 있다. 따라서 중요한 정보를 담기에는 조금 위험한 방법이다.
2. Session
세션은 쿠키와는 다르게 접속 상태가 '서버'에 저장되어 있다는 점이 가장 큰 차이점이다. 쿠키에는 그 데이터에 대한 아이디만 암호화된 상태로 저장되어있다.세션도 결국은 쿠키에 유저의 정보를 담아준다.
[작동방식]
(1) 김코딩이 요청을 보내면 서버는 암호화된 세션 아이디를 Set-Cookie 메소드로 쿠키에 담아서 클라이언트로 전달한다.
(2) 김코딩이 또다른 요청을 보낸다. 이때 김코딩은 세션 아이디가 부여된 상태이다.
(3) 그러므로 이번에 클라이언트는 세션 아이디를 보내면서 요청을 보낸다.
(4) 서버는 세션 아이디를 확인하고 그에 따른 응답을 보낸다.
위에서도 말했듯이 쿠키와 세션의 가장 큰 차이점은 접속 상태의 저장 장소이다. 쿠키는 접속상태를 클라이언트에 저장하고, 세션은 서버에 저장한다.
3. token(JWT)
세션방식은 요청이 있을 때마다 서버를 통해서 확인을 했다. 만약 이 방법이 서버에 많은 부담이 있다고 생각한다면 우리는 token 방식을 사용할 수 있다.
토큰방식은 정보를 클라이언트에 저장한다.
많은 토큰 방식 중 가장 널리 알려져 있는 JWT 방식을 알아보자.
[작동방식]
(1) 클라이언트가 아이디, 비밀번호를 담아서 로그인 요청을 보낸다.
(2) 서버는 정보가 일치하는지 확인하고 클라이언트에게 보낼 암호화된 JWT 토큰을 생성한다.
(3) 생성한 토큰을 클라이언트에게 보내주고 클라이언트는 이 토큰을 localstorage, cookie 등에 저장한다.
(4) 이후 클라이언트가 또다른 요청을 할 때 httpheader에 JWT 토큰을 담아서 요청한다.
(5) 서버는 JWT 토큰을 해독해서 발급한 토큰과 일치하면 그에 따른 응답을 보낸다.
토큰기반 인증을 하면 서버는 클라이언트에 대한 정보를 저장할 필요가 없고 토큰을 헤더에 추가함으로써 인증절차를 완료할 수 있다.
이번시간에는 cookie, session, token에 대해 공부했다.
다음시간에는 OAuth에 대해 공부한다
오늘은 여기까지 :)
