특별 세션 <JWT&Cookie>

JWT -> 구조가 있다 HEADER/PAYLOAD / SUGNATURE 세가지 부분으로 나뉘었다
지금은 PATLOAD 정도만 알면된다.

JWT -> 특정 정보를 담아서 암호화한 토큰, 저장하지 않아도 토큰을 주고받아 인증 가능

인증 흐름
1. 로그인 시 사용자 정보를 검증하여 JWT 생성
2. JWT를 응답에 담아 클라이언트에 전달 (보통Cookie 또는 Header)
3 클라이언트는 요청 시 JWT를 전송하고 서버는 토큰을 검증하여 인증 처리

Cookie에 JWT 저장하는 이유

LocalStorage는 XSS 공격에 취약하며 클라이언트의 JavaScript로 접근 할 수 있음 반면 HttpOnly옵션이 설정된 쿠키는 JavaScript로 접근 할수 없기 때문에 XSS에 강함, 다만 CSRF 공격에 대한 대비가 필요

Cookie 권장 설정
HttpOnly : true
Secure : true (HTTPS 환경에서만 가능)
SameSite : Strict 또는 Lax
만료 시간 설정 필요 (Access vs Refresh Token 전략에 따라 다르게 적용)

---

Session과 JWT가 다른점 흐름은 비슷하나 JWT는 직접 생성해줘야함..

public String createToken(Long userId, String email, UserRole userRole) {
 Date now = new Date();
 return "Bearer"()
 /*암호화 하고 싶은 부분
 	.setSubject(String.valueOf(userId)) // 대주제 
    .claim("email", email) 
    .claim("userRole", userRole)
 */
 /* 토큰을 만들때 시간을 지정한는 부분
 	.setIssuedAt(now)
    .setExpiration (new Date(now.getTime() + TOKEN_TIME))
 */
 /* 암호화 해주는 부분
 	.signWith(key, SignatureAlgorithm.HS256)
    .compact
*/

JWT + Cookie 구조 (Access / Refresh 분리)

1. 로그인 요청 시 Access Token(짧은 만료 시간)과 Refresh Token(긴 만료 시간)을 발급
2. Access Token은 HttpOnly 쿠키로 클라이언트에 전달하고, Refresh Token은 쿠키 또는 DB에 저장
3. 이후 요청 시 쿠키를 통해 Access Token이 자동 전송되며, 만료된 경우 Refresh Token으로 Access Token을 재발급

보안 고려 사항

• JWT 서명 키는 외부에 노출되지 않도록 환경변수로 관리
• Refresh Token은 DB에 저장하고 블랙리스트 관리를 고려
• HTTPS 강제 및 CORS 설정을 적절히 구성
• Access Token 재발급 시 기존 토큰을 무효화하는 로직을 고려

✅ 마무리 요약

JWT는 인증 정보를 자체적으로 담고 있으며 서버가 상태를 유지할 필요가 없습니다.
Access Token은 인증 요청 시 사용되며 비교적 짧은 만료 시간을 갖습니다.
Refresh Token은 토큰 재발급에 사용되며 긴 만료 시간을 가집니다.
쿠키에 저장할 경우 HttpOnly와 Secure 옵션 설정을 통해 보안을 강화할 수 있습니다.