쿠키(Cookie)/세션(Session)/토큰(Token)(+JWT)

쿠키, 세션, 토큰은 모두 클라이언트가 서버와 통신할 때 자신을 인증하고 식별하기 위한 수단이다.

 

클라이언트가 서버와 통신하기 위해 보내는 요청은 모두 독립적(stateless)이지만,

사용자 기반의 요청을 처리하기 위해서는 매 요청마다 사용자 상태(로그인 정보 등)를 유지해야 한다.

이를 위해 서버는 쿠키, 세션, 토큰과 같은 인증 수단을 활용하여 사용자의 인증 상태를 관리한다.

 

---

 

쿠키(Cookie)

쿠키는 서버가 클라이언트(웹 브라우저)에 저장하도록 보내는, 인증 및 식별에 필요한 작은 데이터 집합을의미한다.

출처: https://velog.io/@narangke3/%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-jwt

 

쿠키를 통한 인증 과정은 다음과 같다.

• 클라이언트가 서버로 요청을 보내면,
• 서버는 클라이언트로 쿠키에 사용자 인증 정보를 담아 전송(응답)한다.
• 이후 클라이언트는 해당 쿠키를 가지고 서버에 요청을 보내고,
• 서버는 전달받은 쿠키를 통해 사용자를 인증하고 요청을 처리한다.

이처럼 쿠키는 클라이언트 쪽에 정보를 저장하여, 이후의 요청 시 해당 정보를 서버에 함께 전달하는 일종의 매개체라 할 수 있다.

또한 쿠키는 브라우저 별로 각각 유효 기간이 설정되며, 유효 기간이 만료되면 자동으로 삭제된다. (+ 보안에 취약하다.)

 

---

 

세션(Session)

세션은 쿠키 인증 방식과 달리 사용자의 정보를 모두 서버에 저장하며,

클라이언트에는 세션을 구분하는 고유한 세션 ID만 쿠키에 담아 전달한다.

 

출처: https://dongsik93.github.io/til/2020/01/08/til-authorization%281%29/

 

세션을 통한 인증 과정은 다음과 같다.

• 사용자가 로그인에 성공하면, 서버는 세션 저장소에 사용자에 대한 고유한 세션 ID를 발급한다.
• 생성된 세션 ID는 쿠키에 담겨 클라이언트에 전달된다.
• 이후 클라이언트는 세션 ID가 담긴 쿠키를 가지고 서버에 요청을 보내고,
• 서버는 전달받은 쿠키 내 세션 ID를 기반으로 사용자를 인증하고 요청을 처리한다.

세션 인증 방식은 서버에서 모든 인증 정보를 관리하기 때문에, 쿠키 인증 방식보다 보안 상 안전하다는 장점이 있다.

또한 서버가 세션 정보를 직접 관리할 수 있어, 여러 사용자가 하나의 계정을 공유하는 경우에도 세션 상태를 효과적으로 제어할 수 있다.

하지만 서비스를 사용하는 유저가 많아지면, 세션 ID를 저장하는 저장소도 더 많아져야 한다.

 

---

 

토큰(Token)

토큰 인증 방식은 클라이언트가 직접 문자열 형태의 토큰을 보관하고, 이를 서버에 전달하여 인증하는 방식이다.

따라서 세션과 달리 토큰은 별도의 저장소 없이 유효한지 검증하기만 하면 되므로,

서버의 부하가 상대적으로 적다는 이점이 있다!

JWT

JWT 인증 방식은 이러한 원리를 이용한 대표적인 토큰 기반 인증 방식이다.

• 이 방식은 여러 브라우저나 다양한 클라이언트 환경에서 인증 토큰을 사용할 수 있다.
• 토큰이 탈취되지 않도록 토큰 만료 시간 설정 및 리프레시 토큰 관리 등을 통해 보안에 주의해야 한다.

JWT를 통한 인증 과정

 

1. 사용자는 서버에게 로그인을 시도한다.
2. 로그인에 성공한다면 서버는 JWT 토큰을 생성하여 전달한다.
3. 이후, 사용자는 헤더에 토큰을 담아 요청을 보낸다.
4. 서버는 토큰이 유효한지 검사하고, 유효하다면 응답을 반환한다.

서버는 JWT 토큰이 유효한지 어떻게 검증할까? 

이를 위해서는 먼저 JWT의 구조에 대해 알아야 한다.

 

JWT의 구조

JWT는 Header, PayLoad, Signature 세 구조로 나뉘어진다.

 

Header

Header(헤더)는 토큰 유형(typ), 해시 알고리즘 종류(alg)로 나뉘어진다.

ex) typ : jwt

      alg: HMAC SHA 256, RSA, ...

 

PayLoad

PayLoad(페이로드)는 서버에서 첨부한 사용자의 권한 정보와 데이터를 의미한다.

이때, 정보는 Claim 형식으로 담긴다.

※ Claim: key - value 형식으로 이루어진 한 쌍의 정보로, 3가지로 나뉘어진다.

• Registed Claims: 미리 정의된 클레임
      ex) iss(이슈 발행자), exp(만료 시간), sub(제목), iat(발행 시간), jti(JWI ID)
• Public Claims: 사용자가 정의된 공개용 클레임, 정보 전달을 위해 사용한다.
• Private Claims: 외부에 공개되도 상관은 없지만, 해당 유저를 특정할 수 있는 정보들을 담는다.

Signature

Signature(시그니처)는 헤더와 페이로드를 서명하는 과정이다.

서명 과정은 다음과 같다.

1. Header와 PayLoad를 Base64Url 인코딩한다.
2. 인코딩한 Header, 인코딩한 PayLoad로 서버 Key를 적용한 뒤 → Header의 해시 알고리즘으로 해싱한다.

최종적으로 JWT 토큰을 조립하는 방법은 다음과 같다.

jwt = Base64Url(Header) + . + Base64Url(PayLoad) + . + Base64Url(Signature)

 

JWT 유효성 인증

인증 과정 중 사용자로부터 요청이 도착하면, 헤더에 담긴 JWT 토큰이 유효한지 검증해야 한다.

유효성을 검증하는 과정은 다음과 같다.

• JWT 토큰의 헤더와 페이로드로 시그니처를 생성한다.
• 전달된 토큰의 시그니처가 만든 시그니처와 동일하면 토큰이 유효하다고 판단한다.

 

JWT 장점과 단점

JWT의 장점

• Stateless이므로, 서버가 클라이언트 세션 상태를 기억할 필요가 없다.

JWT의 단점

• 토큰 길이: PayLoad의 길이가 길어질수록 네트워크에 부하를 줄 수 있다.
• PayLoad 인코딩: 디코딩이 가능하므로, 중요한 데이터를 넣지 않아야 한다.

 

:)

 

참고

https://ksh-coding.tistory.com/113

https://jibinary.tistory.com/270

https://dsc-sookmyung.tistory.com/313