Session/Cookie 그리고 Token(JWT)
아직까지 이 3가지를 모르고 사용했다니... 반성하겠습니다
Session
서버와 클라이언트의 연결이 활성화된 상태로 서버에서 가지고 있는 정보
Cookie
서버에서 발급된 세션을 열기 위한 키(세션 ID)
JWT(Json Web Token)
사용자를 인증하고 식별하기 위한 토큰(Token) 기반 인증으로 세션과 달리 서버가 아닌 클라이언트에서 가지고 있는 정보
Token
인증을 위해 사용되는 암호화된 문자열.
인증 방식
I. Session / Cookie 방식
Session/Cookie 방식 인증은 세션 저장소(서버에 존재)를 필요로 하며, 세션 저장소는 로그인시 사용자 정보를 저장하고, 키(Key)로 사용할 수 있는 세션 ID 생성, 그리고 HTTP 헤더에 실어 Client에게 전송하며 Client(브라우저)는 세션 ID 를 포함하는 Cookie를 저장
따라서 인증이 필요한 요청이 올때마다 해당하는 Cookie를 서버에 요청
인증 절차
사용자가 로그인 시 서버에서 계정 정보를 검증 후 고유 ID 값을 부여한 후 세션 저장소에 저장하고, 이와 연결되는 세션 ID 를 발행
클라이언트는 서버에서 해당 세션 ID 를 받아 쿠키에 저장, 인증이 필요한 요청 시 쿠키를 헤더에 포함하여 서버에 요청 후
서버는 쿠키를 받아 세션 저장소에서 일치하는 정보를 제공 마지막으로 인증이 완료되고 서버는 사용자에게 데이터를 전송
쿠키와 세션을 같이 사용하는 이유
쿠키만 사용 시에 서버의 자원을 사용하지 않아, 클라이언트가 인증 정보를 담당하므로 쿠키만으로 인증할 경우 HTTP 요청이 중간에 탈취될 수 있어 보안에 취약
따라서 인증을 서버가 담당하기 위해서 세션을 같이 사용하며, 클라이언트는 쿠키를 통해 서버에 요청하고 서버에서 쿠키를 받아 검증 후 세션의 정보에 접근하는 인증 방식을 사용
II. JWT(토큰 기반) 방식
인증에 필요한 정보들을 Token에 담아 암호화시켜 사용하는 토큰으로, JWT의 특징인 서명된 토큰은 이를 가지고 있는 서버가 토큰이 정상적인지를 검증(인증)하며, JWT의 구조는 .(점)을 기준으로 Header, Payload, signature 세 부분으로 구성
- Header: 토큰의 타입, 서명 생성 시 사용된 알고리즘 등으로 구성
- Payload: 토큰 발급자(iss), 토큰 제목(sub), 토큰 대상자(aud), 토큰 만료 시간(exp), 토큰 활성 날짜(nbf), 토큰 발급 시간(iat), JWT 토큰 식별자(jti)로 구성
- Signature: base64UrlEncode(header), base64UrlEncode(payload), your-256-bit-secret
인증 절차
사용자가 로그인 시 서버에서 계정 정보를 검증한 후에 사용자의 고유 ID 값, 유효기간 그 외 기타 정보와 함께 Payload에 삽입하며 암호화 할 Secret Key를 이용해 Access Token을 발급
클라이언트는 Access Token 을 받아 저장 후, 인증이 필요한 요청마다 토큰을 헤더에 포함하여 요청하며, 서버가 가지고있는 개인키를 가지고 Signature를 복호화한 다음 base64UrlEncode(header)가 JWT의 heaer값과 일치하는지, base64UrlEncode(payload) 와 일치하는지 검증하여 인증을 허용