Cookie & Session & JWT 정리

🏷️Cookie

웹 브라우저 쿠키(Cookie)란, 서버가 사용자의 웹 브라우저에 전송하는 데이터 조각으로 key=value 형식으로 되어 있다. 브라우저는 이 쿠키 값을 저장해놓았다가 동일한 서버에 인증을 필요로 하는 재요청을 보낼 시 쿠키 값을 같이 전송할 수 있다.

🏷️Cookie를 활용한 로그인 처리

1. 클라이언트가 로그인 화면에서 loginId와 password를 입력 후 POST 요청을 통해 로그인 과정을 진행한다.

• 클라이언트가 로그인 폼을 작성하고 제출하면 클라이언트는 loginId와 password를 서버에 POST 요청으로 보낸다.

2. 서버는 DB를 조회하여 해당 유저 정보를 검증한다.

• 서버는 데이터베이스에서 loginId와 일치하는 유저 정보를 조회하고, 입력된 비밀번호와 DB에 해시화된 패스워드를 비교하여 인증을 수행한다.

3. 웹 브라우저의 쿠키 저장소에 반환된 쿠키가 저장이 된다.

1. 클라이언트는 응답 받은 쿠키를 웹 브라우저의 쿠키 저장소에 보관한다. 보관 후 인증을 필요로 하는 요청의 경우 서버에 요청을 보냄과 동시에 쿠키를 같이 보낸다.

1. 서버는 클라이언트로부터 요청 받은 쿠키에 포함된 SessionID를 파싱하여 올바른지 검증하고 인증된 사용자의 경우 요청을 처리한다.

🏷️Cookie의 문제(아는 선에서만 정리한 것, 또 다른 문제가 있다면 추가로 정리)

1. 쿠키 탈취

• 쿠키는 서버 측에 저장되는 것이 아니라 클라이언트 측에 저장된다. 그렇기 때문에 악의적인 공격자가 이를 탈취할 수 있다. 탈취된 쿠키는 사용자 세션을 가로채거나(세션 하이재킹), 해당 사용자 권한을 도용하는 데 사용할 수 있다.
• HTTPS를 사용하여 통신을 암호화하고, 쿠키에 Secure 속성을 설정하여 HTTPS를 통해서만 전송되도록 해야 한다. 또한 HttpOnly 속성을 사용하여 자바스크립트로 쿠키에 접근하는 것을 방지하도록 한다.

2. 쿠키 크기 제한

• 쿠키의 크기는 그렇게 크지 않다. 이 때문에 복잡한 인증 정보나 대량의 데이터를 쿠키에 저장하는 것은 한계가 있다.
• 쿠키에 저장할 데이터는 최소화하고 필요에 따라 서버 측에 중요한 데이터를 저장하는 방식을 사용한다.

3. 쿠키 만료

• 쿠키는 만료 시간이 지나면 자동으로 삭제된다. 또한 쿠키가 클라이언트 측에 저장되기 때문에 사용자에게 노출되며 사용자가 임의로 수정하거나 삭제할 수 있다.
• 쿠키가 탈취되더라도 악의적인 공격자가 이를 재사용할 수 없도록 쿠키 만료 시간을 짧게 유지하는 것이 좋다.

🏷️Session

세션은 영구적이고 상호작용적인 정보 교환을 전제하는 둘 이상의 통신 장치나 컴퓨터와 사용자 간의 대화나 송수신 연결 상태를 의미한다.

결국 세션이란, 클라이언트와 서버 간 연결된 상태를 말한다. 이 세션이 사라지는 경우는 총 3가지가 있다.

• 서버 쪽에서 세션의 값을 제거하는 경우
• 사용자가 웹 브라우저 창을 닫는 경우
• 세션의 만료 시간이 지난 경우

🏷️Session을 활용한 로그인 처리

1. 클라이언트로부터 로그인 요청이 들어온다.

• 클라이언트가 로그인 폼을 통해 제출한 데이터로 서버에 로그인 요청을 보낸다.

2. 서버는 DB를 조회해 유저 데이터를 확인한다.

• 서버는 클라이언트로부터 전달받은 로그인 정보를 이용해 데이터베이스에서 해당 유저의 정보를 확인하고 비밀번호를 검증한다.
• 유저 정보가 유효하고 인증에 성공했다면 다음 단계로 진행된다.

3. 서버는 세션 저장소에 세션 정보를 생성한다.

• 인증에 성공한 유저에 대해서 서버는 세션 저장소에 유저와 관련된 세션 정보를 생성한다.
• 세션 정보에는 주로 유저의 식별자나 로그인 상태 등을 포함한다.

4. 서버는 SessionID를 클라이언트에 응답으로 보낸다.

• 서버는 생성된 세션에 대한 고유한 SessionID를 발급하고 이 SessionID를 클라이언트 쿠키에 저장하여 응답으로 보낸다. 이후 클라이언트는 이 쿠키를 유지하게 된다.

5. 클라이언트는 추후 인증이 필요한 요청을 보낼 경우 이 SessionID를 쿠키에 담아 요청을 보낸다.

• 클라이언트가 인증이 필요한 요청을 보낼 때 브라우저는 자동으로 해당 쿠키(SessionID 포함)를 서버에 전송한다.
• 서버는 이 SessionID를 기반으로 세션 저장소에서 유저 정보를 조회하여 인증을 처리한다.

🏷️Session의 문제(아는 선에서만 정리한 것, 또 다른 문제가 있다면 추가로 정리)

1. 서버 측 상태 관리

• 세션 기반 인증에서는 서버가 각 클라이언트의 상태를 유지하기 위해 세션 저장소에 세션 데이터를 저장한다고 했다. 이는 서버의 메모리나 데이터베이스에 부담을 줄 수 있다.

2. 서버 장애

• 서버 장애가 발생하면 해당 서버에 저장된 세션 정보가 사라져 사용자들이 과정을 처음부터 다시 시작해야 한다.

🏷️JWT(Json Web Token)

세션 기반 인증의 경우 요청을 서버에 보낼 때마다 세션 ID를 조회하는 작업을 통해서 DB 접근이라는 절차를 수행해야한다는 점, 이 과정이 서버의 부하를 증가시킬 수 있다는 점을 알고 더 좋은 방법이 무엇이 있는지 찾아보면 대표적으로 JWT가 많이 보인다.

JWT는 각각의 구성요소가 점(.)으로 구분이 되어있으며 구성 요소는 아래와 같다.

• Header
• Payload
• Signature

1. Header

Header에는 토큰의 타입과 해시 알고리즘을 명시하는 부분이다. 일반적으로 두 가지 정보를 포함하는 JSON 객체로 구성된다.

2. Payload

Payload는 JWT의 본문 부분으로 사용자에 대한 정보를 포함하고 있다. 클레임은 JWT에서 전송하고자 하는 정보들이 있다.

iss : 토큰 발급자
sub : 토큰 제목
aud : 토큰 대상자
exp : 토큰 만료
nbf : 토큰 활성 날짜
iat : 토큰 발급 시간
jtl : JWT 토큰 식별자

3. Signature

Signature은 헤더와 페이로드를 조합하여 생성되며, JWT의 무결성과 출처를 검증하는 데 사용된다.

🏷️JWT를 활용한 로그인 처리

1. 클라이언트로부터 로그인 요청이 들어온다.

• 클라이언트가 아이디와 비밀번호를 사용해 서버에 로그인 요청을 보낸다.(이 때, 폼을 통한 제출은 비활성화 처리)

2. 서버에서 사용자 인증을 한다.

• 서버는 제공된 자격 증명을 기반으로 사용자를 인증한다.

3. JWT(Json Web Token)를 생성한다.

• 인증에 성공하면 서버는 클라이언트 정보를 바탕으로 Access Token(액세스 토큰)과 Refresh Token(리프레시 토큰)을 생성한다.
• Access Token은 사용자 정보와 만료 시간을 포함하며 짧은 시간을 설정하는 것이 일반적이다.
• Refresh Token은 사용자 식별 정보만 포함하고 만료 시간이 Access Token보다 길다. 이 토큰은 Access Token이 만료된 경우 재발급 요청 시에 사용된다.
• 생성된 JWT는 Header + Payload + Signature 등의 구조를 가진다.

4. JWT를 응답으로 보낸다.

• 서버는 클라이언트에게 Access Token와 Refresh Token을 같이 보낸다.

5. 클라이언트는 Access Token을 사용하여 요청을 보낸다.

• 클라이언트는 이후 서버에 요청을 보낼 때, Access Token을 Authorization 헤더에 포함하여 보낸다.

6. 서버에서 Access Token을 검증한다.

• 서버에서 Access Token의 유효성을 검증하고 유효하면 사용자의 요청을 처리한다.

7. 만약 6번 과정에서 유효성을 검증하는 과정에서 Access Token이 만료되었다면 응답으로 같이 보냈던 Refresh Token을 통해 Access Token을 재발급한다.

🏷️JWT의 문제(아는 선에서만 정리한 것, 또 다른 문제가 있다면 추가로 정리)

모든 기술이 장점만 있는 것은 아니듯이 단점도 존재한다. 쿠키의 단점이 있어 세션을 사용했으나 세션 역시 단점이 있어 JWT를 사용했다. 하지만 이 JWT 역시 단점이 존재한다.

1. 토큰 크기

• 세션이 Stateful한 설계라면 JWT는 Stateless한 설계이다. JWT는 클라이언트 측에 저장되며, 페이로드에 포함된 데이터가 클수록 토큰 역시 커진다. 이는 네트워크 대역폭을 많이 점유한다는 의미로 클라이언트 - 서버 간 통신 성능에 영향을 줄 수 있다.

2. 서버에서의 토큰 무효화 어려움

• 위에서 말했지만 JWT는 Stateless한 설계로 서버 측이 상태를 관리하지 않는다. 따라서 클라이언트 측에 이미 발급된 토큰에 대해서 무효화하거나 강제로 로그아웃 처리하는 것이 어렵다. 이를 해결하기 위해 Token Blacklist나 만료 시간을 짧게 가져가야 한다.

3. 토큰 재사용 가능성

• 토큰이 탈취되면, 토큰에 지정된 만료 시간이 다 될 때까지 이를 악용할 수 있다. JWT는 기본적으로 토큰의 유효성을 검증하는 과정에서 서버에 저장된 세션 정보를 확인하지 않기에 토큰이 탈취되면 이 탈취되었다는 사실을 인지하기 어렵다.

4. Payload 정보 노출 가능성

• JWT 페이로드는 기본적으로 Base64 URL-safe encoding으로 인코딩되지만, 암호화되지 않는다. 따라서 페이로드에 포함된 데이터는 누구나 쉽게 디코딩이 가능하다. 민감한 정보를 토큰에 포함시키는 것은 보안적으로 권장하지 않는다.

5. JWT 토큰의 만료 그리고 갱신의 어려움

• JWT는 토큰 Payload의 속성 중 하나인 exp를 통해 만료 시간을 지정할 수 있는데 이 만료 시간을 갱신하기 위해서 새로운 토큰을 발급받아야 한다.

토큰을 발급받았다는 의미는 인증되었다는 것을 말하기 때문에 세션 저장소와 같은 별도의 저장소가 필요하지 않을 수 있다.

세션의 경우 서버 측에 상태를 저장해야하는 Stateful 설계인 반면 JWT의 경우 서버 측에 상태를 저장할 필요가 없는 Stateless 설계가 가능하다.

결과적으로 JWT를 도입하는 이유는 Stateful한 세션 설계의 단점을 보완하기 위해 Stateless한 JWT 설계를 도입하여 서버의 수평적 확장을 용이하게 하는 데 그 목적이 있다.