[네트워크] 인증 방식 (쿠키, 세션, 토큰 JWT) 및 로그인 세션ID 저장 과정

인증 / 인가

1. 인증 (Authentication):

• 인증은 해당 유저가 실제 유저인지 확인하는 과정
• 예를 들어, 사용자가 로그인할 때 ID와 비밀번호를 입력하면 시스템은 이를 확인하여 사용자가 누구인지 확인합니다.
• 인증 방식은 비밀번호, 생체 인식, OTP(일회용 비밀번호), 보안 토큰 등 다양합니다.
• 즉, **"누구냐?"**라는 질문에 답하는 과정입니다.

2. 인가 (Authorization):

• 인가는 인증된 유저가 어떤 자원에 접근할 수 있는지, 어떤 행동을 할 수 있는지를 결정하는 과정입니다.
• 예를 들어, 로그인한 사용자가 특정 파일을 열거나 수정할 수 있는 권한을 갖고 있는지 확인합니다.
• 즉, **"이 사용자는 무엇을 할 수 있느냐?"**라는 질문에 답하는 과정입니다.

정리

• 인증: 사용자의 신원을 확인하는 과정 (누구냐?)
• 인가: 사용자가 수행할 수 있는 작업이나 자원에 대한 접근 권한을 부여하는 과정 (무엇을 할 수 있느냐?)

---

쿠키 / 세션 / JWT 토큰 

1. 쿠키 (Cookie)

• 정의: 쿠키는 서버가 클라이언트(브라우저)에 저장하는 작은 데이터 조각으로, 주로 사용자의 세션 정보나 설정 정보를 저장합니다.
• 주요 특징:
  • 클라이언트에 저장되며, 특정 도메인에 의해 접근 가능합니다.
  • 자동으로 서버에 전송됩니다 (HTTP 요청 시 헤더에 포함).
  • 만료 시간, 도메인, 경로 등의 속성을 설정할 수 있습니다.
• 용도: 사용자 로그인 상태를 유지하거나, 사용자 환경 설정 정보를 저장하는 데 사용됩니다.
• 보안: 쿠키에 민감한 정보(예: 비밀번호)를 저장하는 것은 보안상 위험할 수 있습니다. 따라서 Secure, HttpOnly, SameSite 옵션을 설정하여 보안을 강화할 수 있습니다.

쿠키 저장 방식

2. 세션 (Session)

• 정의: 세션은 서버 측에 데이터를 저장해 클라이언트의 상태를 추적하는 방식입니다. 세션 ID를 쿠키에 저장하고, 실제 데이터는 서버에 보관됩니다.
• 주요 특징:
  • 서버에서 상태를 관리하므로, 클라이언트 측에서 데이터를 직접 저장하지 않습니다.
  • 클라이언트에는 세션 ID만 저장되어 서버에서 세션 데이터를 조회합니다.
  • 세션 데이터는 서버 메모리나 데이터베이스에 저장됩니다.
• 용도: 사용자가 로그인한 후, 로그인 정보를 서버에 보관하고 클라이언트는 세션 ID를 통해 이 정보를 식별합니다.
• 보안: 세션은 서버에서 관리되므로 민감한 정보는 서버에만 저장되고, 클라이언트에는 세션 ID만 전달됩니다. 그러나 세션 ID가 탈취되면 세션 하이재킹 공격이 발생할 수 있습니다.

세션 저장 방식

3. JWT (JSON Web Token)

• 정의: JWT는 JSON 형식으로 인증에 필요한 정보들을 암호화시킨 토큰
• JWT 토큰(Access Token)을 HTTP 헤더에 담아 서버가 클라이언트를 식별한다.
• 주요 특징:
  • 클라이언트가 JWT를 보관하고, 서버에 요청할 때마다 이를 전달합니다 (주로 HTTP 헤더의 Authorization 필드에 포함).
  • JWT는 토큰 내부에 인증 정보와 기타 필요한 데이터를 담고 있으며, 서명된 형태로 제공됩니다. 이를 통해 서버는 데이터를 수정하지 않았음을 검증할 수 있습니다.
  • JWT는 State-less 방식으로, 서버는 상태를 저장하지 않으며 클라이언트가 정보를 가지고 있습니다.
  • ex) 카카오 OAuth2 로그인 시 JWT 토큰 사용
• 용도: 분산 시스템이나 마이크로서비스 환경에서 사용자 인증 및 권한 부여에 사용됩니다. 또한, 클라이언트와 서버 간의 인증 정보를 쉽게 전달할 수 있게 해줍니다.
• 보안: JWT는 서명된 토큰으로, 변조를 방지할 수 있습니다. 그러나 토큰이 탈취되면 다른 사용자가 이를 악용할 수 있기 때문에 토큰의 만료 시간을 적절하게 설정해야 합니다.

JWT 동작 방식

차이점 요약:

특성 쿠키 (Cookie) 세션 (Session) JWT (JSON Web Token)

특성		쿠키 ( Cookie )	세션 ( Session )	JWT ( JSON Web Token )
저장 위치		클라이언트(브라우저)	서버	클라이언트(토큰 자체)
정보 저장		작은 데이터(주로 사용자 설정)	서버에 저장된 사용자 상태	토큰 자체에 사용자 정보 포함
상태 유지		클라이언트에 저장된 쿠키로 상태 유지	서버에서 상태 유지	상태 비저장(State-less) 방식
보안성		민감한 정보는 위험, Secure와 HttpOnly 옵션 필요	세션 ID가 탈취되면 하이재킹 위험	서명된 토큰을 사용해 변조 방지, 만료 설정 필요
사용 용도		사용자 환경 설정, 세션 관리	로그인 상태 유지, 서버에서 세션 관리	분산 시스템에서 인증 및 권한 부여
만료 시간		설정 가능 (Expires, Max-Age)	서버에서 관리	JWT 자체에 만료 시간 (exp) 포함

결론:

• 쿠키는 클라이언트에 데이터를 저장하고 서버와 자동으로 주고받기 위한 용도로 사용됩니다.
• 세션은 서버에서 상태를 관리하는 방식으로, 세션 ID를 클라이언트에 전달하여 세션을 추적합니다.
• JWT는 클라이언트와 서버 간에 인증된 정보를 안전하게 전달하는 데 사용되며, 상태를 서버에서 관리하지 않고 클라이언트가 직접 정보를 담고 있습니다.

---

보통  쿠키와 세션은 세션 ID를 통해 함께 작업하며, 이를 통해 사용자의 로그인 상태나 기타 정보를 유지합니다.

로그인 상태 유지를 위해 세션과 쿠키를 함께 사용하는 이유

1. 보안성 강화
   • 세션 데이터는 서버에 저장되므로 민감한 정보가 클라이언트에 노출되지 않습니다.
   • 클라이언트는 단순히 세션 ID를 전달하는 역할만 합니다.
2. 데이터 관리 용이성
   • 세션은 서버에서 관리하므로 데이터 크기 제한이 없으며, 상태를 중앙에서 제어할 수 있습니다.
3. 추적 및 인증
   • 서버에서 세션을 기반으로 사용자를 추적하면 더 높은 신뢰성과 보안을 제공할 수 있습니다.

쿠키만 사용할 때의 문제점

1. 보안 문제
   • 쿠키에 민감한 정보를 저장하면 사용자가 조작하거나 탈취될 가능성이 높습니다.
   • 예를 들어, 로그인 상태를 나타내는 사용자 ID나 비밀번호를 쿠키에 저장하면 안전하지 않습니다.
   • 이를 막기 위해 쿠키에 저장되는 정보는 암호화가 필요하며, 추가적인 작업이 요구됩니다.
2. 데이터 크기 제한
   • 쿠키에는 일반적으로 크기 제한(대략 4KB)이 있습니다.
   • 사용자 정보나 상태를 모두 쿠키에 저장하기에는 용량이 부족할 수 있습니다.
3. 취약성 증가
   • 쿠키는 클라이언트에 저장되기 때문에 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 같은 공격에 더 취약합니다.
   • 쿠키 기반 인증만으로 시스템을 유지하면 추가적인 보안 조치를 해야 합니다.
4. 관리 어려움
   • 사용자가 쿠키를 삭제하면 서버는 사용자를 식별할 방법이 없어집니다.
   • 반면, 세션은 서버 측에서 관리되므로 클라이언트 환경과 무관하게 상태를 유지할 수 있습니다.

1.  

결론

쿠키만 사용해서 로그인 세션을 유지하는 것도 가능하지만, 보안, 데이터 크기, 관리 측면에서 여러 제약이 따릅니다. 그래서 민감한 데이터는 서버에 저장하고, 클라이언트는 단순히 세션 ID(쿠키)를 통해 서버와 소통하는 방식으로 쿠키와 세션을 함께 사용하는 것이 일반적입니다.

만약 쿠키만 사용하는 방식을 고민 중이라면, 반드시 다음과 같은 보안 대책을 고려해야 합니다:

• 쿠키의 암호화
• HTTPS를 통한 통신
• HttpOnly, Secure 플래그 설정
• CSRF/XSS 방어 메커니즘 추가

이와 같은 이유로, 쿠키와 세션의 조합이 실무에서 가장 널리 사용되는 방식입니다. 😊

---

로그인 상태 유지하는 방법

1. 세션 ID 저장 과정

로그인 요청 시 세션을 생성하고, 세션 ID를 클라이언트와 서버 간에 어떻게 처리할지에 대한 과정은 다음과 같습니다.

1.1 세션 저장소 (서버 측)

• 서버는 로그인 후 세션 객체를 생성하고, 이 객체를 세션 저장소(예: 메모리, 데이터베이스 등)에 저장합니다.
• 세션 저장소에는 세션 ID와 해당 세션에 대한 상태 정보(사용자 정보, 인증 정보 등)가 저장됩니다.

1.2 세션 ID 쿠키에 저장 (클라이언트 측)

• 서버는 생성된 세션에 대해 고유한 세션 ID를 할당하고, 이를 쿠키에 저장하여 클라이언트에 전달합니다.
• 쿠키는 Set-Cookie 헤더를 통해 서버가 클라이언트에 세션 ID를 전달하는 방식으로 설정됩니다.

클라이언트는 이 세션 ID를 브라우저 쿠키에 저장하며, 이후 서버에 요청을 보낼 때마다 이 세션 ID가 자동으로 서버로 전달됩니다.

2. 구체적인 처리 방식

구체적으로 로그인 요청이 들어왔을 때 서버측에서 클라이언트에게 어떻게 세션ID를 생성해서 쿠키에 담아 전달하는지 아래와 같은 순서대로 설명하겠습니다.

2.1 HttpSession 사용 (서버 측 세션 관리)

• 로그인 요청이 들어왔을 때 서버 측에서 HttpSession 객체를 사용하여 세션에 정보를 저장해 세션을 관리합니다. 이 객체는 서버가 클라이언트에 대한 정보를 추적할 수 있도록 도와줍니다.
• Java 기반 웹 애플리케이션의 경우, HttpSession 객체는 다음과 같은 방식으로 사용됩니다

// 로그인 처리 시 세션 생성
HttpSession session = request.getSession();
session.setAttribute("user", user); // 사용자 정보를 세션에 저장

위 코드에서 request.getSession()은 현재 클라이언트에 대한 세션을 생성하거나, 이미 존재하는 세션을 반환합니다. 세션에 저장된 정보는 서버 측에서 관리됩니다.

2.2 세션 ID 자동 전달 (Set-Cookie 헤더)

• HttpSession 객체를 통해 세션을 생성하면, Set-Cookie 헤더가 자동으로 클라이언트에게 응답으로 전송됩니다. 이 헤더에는 세션 ID가 포함되어 있습니다. (따로 setCookie로 세션ID 저장할 필요 없음)
• 클라이언트는 이 세션 ID를 쿠키에 저장하고, 이후 요청 시 이 세션 ID를 서버에 자동으로 포함시킵니다.
• 예를 들어, 서버가 응답할 때 클라이언트에게 전달하는 Set-Cookie 헤더는 대개 다음과 같습니다

Set-Cookie: JSESSIONID=1234567890abcdef; Path=/; HttpOnly; Secure; SameSite=Strict;

여기서 JSESSIONID는 세션 ID이고, 클라이언트는 이 값을 쿠키에 저장합니다.

2.3 Set-Cookie를 명시적으로 설정 (직접적인 쿠키 설정) //생략 가능한 부분

• 일부 경우에는 **Set-Cookie**를 명시적으로 설정할 수도 있습니다. 예를 들어, 서버에서 세션 ID 외에도 추가적인 정보를 클라이언트에 쿠키로 전달하고자 할 때 HttpServletResponse 객체의 addCookie() 메서드를 사용합니다:이 방식은 서버가 HttpSession을 사용하지 않고 세션 ID를 직접 쿠키로 관리할 때 사용됩니다.

// 쿠키를 명시적으로 추가하는 방법
Cookie sessionCookie = new Cookie("SESSIONID", sessionId);
sessionCookie.setPath("/"); // 모든 경로에 대해 유효
sessionCookie.setHttpOnly(true); // 클라이언트 JavaScript에서 쿠키를 접근할 수 없게 설정
response.addCookie(sessionCookie);

이 방식은 서버가 HttpSession을 사용하지 않고 세션 ID를 직접 쿠키로 관리할 때 사용됩니다.

3. 결론

• 세션 ID 저장: 서버는 HttpSession을 사용하여 세션 ID를 관리하고, 세션 저장소(예: 메모리, 데이터베이스 등)에 세션 정보를 저장합니다.
• 쿠키에 저장: HttpSession을 사용하면 세션 ID는 자동으로 Set-Cookie 헤더를 통해 클라이언트의 쿠키에 저장됩니다. 클라이언트는 이 쿠키를 통해 서버에 요청할 때마다 세션 ID를 자동으로 전달합니다.
• setCookie vs HttpSession:
  • HttpSession: 세션 ID와 관련된 서버 측 세션 관리를 자동으로 처리하며, 세션 ID는 자동으로 쿠키에 설정됩니다.
  • setCookie: 서버가 직접 쿠키를 설정하여 클라이언트에게 추가적인 정보를 전달할 수 있습니다. (세션 ID를 쿠키에 수동으로 설정할 수도 있음)

실제 로그인 흐름

1. 클라이언트가 로그인 요청을 보냅니다.
2. 서버는 HttpSession을 통해 세션을 생성하고, 세션에 사용자 정보를 저장합니다.
3. Set-Cookie 헤더를 통해 세션 ID가 클라이언트의 쿠키에 저장됩니다.
4. 클라이언트는 이후 요청을 보낼 때 쿠키에 저장된 세션 ID를 함께 보내고, 서버는 이를 기반으로 사용자를 인증하고 상태를 유지합니다.