Spring Boot 3 & Security 6 시리즈: JWT 로그인 폼 구현 (1편)

 

 

Spring Security를 구현하기 전에 앞으로 사용할 JWT 토큰이 어떤 것인지에 대해서 알아보자

 

📌 서론

JWT (JSON Web Token)는 웹에서 정보를 안전하게 전송하기 위한 컴팩트하고 독립적인 방식을 제공하는 토큰이다. JWT는 세 부분으로 구성되며, 각 부분은 점(.)으로 구분된다.

 

아래의 링크에서 jwt 토큰을 Encoded, Decoded 해볼 수 있다.

JWT.IO

jwt 페이지

 

 

1. JWT란

Header: Header는 JWT의 메타데이터를 포함하며, 주로 두 가지 정보를 담고 있다.

• alg: 사용된 암호화 알고리즘을 나타낸다. 예: HMAC SHA256 또는 RSA.
• typ: 토큰의 타입을 나타낸다. JWT의 경우 "JWT"로 설정된다.

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload (Claims)

Payload는 토큰의 주요 내용을 담고 있다. 이 부분에는 여러 클레임(claim)이 포함된다. 클레임은 토큰에 담긴 정보의 한 조각을 의미하며, 세 가지 유형의 클레임이 있다.

• Registered claims:
  • 토큰의 동작과 관련된 일련의 클레임이다. 예로는 iss (발행자), exp (만료 시간), sub (주제), aud (대상) 등이 있다.
    
    
• Public claims:
  • 공개적으로 정의된 클레임들로, JWT 사용자 사이에 충돌을 피하기 위해 IANA JSON Web Token Registry에 등록해야 한다.
    
    
• Private claims:
  • 두 당사자 사이에서 합의된 클레임으로, 공개 클레임과 충돌을 피해야 한다. 예로는 사용자의 ID, 이름, 이메일 등의 사용자 정보가 있다.

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

Signature

• Signature는 토큰의 무결성을 보장하기 위해 생성된다. Header와 Payload의 값을 암호화하여 생성되며, 이 서명을 통해 토큰이 중간에 변경되지 않았음을 검증할 수 있다.
  
  
• 서명 생성 방법:

HMACSHA256(
	  base64UrlEncode(header) + "." +
	  base64UrlEncode(payload),
	  secret
)

• 이렇게 생성된 세 부분 (Header, Payload, Signature)은 점(.)으로 연결되어 하나의 JWT 문자열을 형성한다.

JWT는 자체 포함적인 특성 때문에 인증 및 권한 부여에서 널리 사용된다. 토큰 자체에 모든 필요한 정보가 포함되어 있기 때문에 별도의 세션 저장소가 필요하지 않다. 이로 인해 서버의 확장성을 향상시키고, 여러 서비스 간에 토큰을 쉽게 전달할 수 있다.

 

 

2. MSA 와 JWT

JWT (JSON Web Token)는 MSA (Microservices Architecture) 프로젝트에서 특히 유용하다.

• MSA에서는 여러 개의 독립적인 서비스가 함께 작동하여 하나의 큰 애플리케이션을 구성한다. 이러한 구조에서 JWT의 특성은 다음과 같은 이유로 특히 중요하다.
  
  
• 스케일 아웃 및 분산 시스템:
  • MSA는 여러 서비스 인스턴스를 통해 확장될 수 있다. JWT는 상태가 없기 때문에 어떤 서비스 인스턴스에서든 사용자를 인증할 수 있다. 이는 세션 기반 인증에서 발생할 수 있는 세션 동기화 문제를 피할 수 있다.
    
    
• 서비스 간 인증:
  • MSA에서는 서비스 간에 요청이 자주 발생한다. JWT를 사용하면 한 서비스에서 생성된 토큰을 다른 서비스에서도 검증할 수 있다. 이로 인해 사용자 인증 정보를 쉽게 전달하고 검증할 수 있다.
    
    
• 효율성:
  • JWT는 자체 포함적이므로 추가적인 데이터베이스 조회 없이 필요한 모든 정보를 토큰에서 직접 얻을 수 있다. 이는 네트워크 지연 시간을 줄이고 전체 시스템의 효율성을 향상시킨다.
    
    
• 보안:
  • JWT는 디지털 서명을 통해 보안을 제공한다. 이로 인해 토큰이 변경되거나 조작되지 않았음을 확인할 수 있다.
    
    
• 플랫폼 및 언어 독립성:
  • JWT는 다양한 프로그래밍 언어와 플랫폼에서 지원된다. 이는 MSA 환경에서 다양한 기술 스택을 사용하는 서비스 간에 토큰을 쉽게 교환할 수 있음을 의미한다.
    
    
• 결론적으로, JWT는 MSA 환경에서 인증 및 권한 부여를 효율적이고 안전하게 관리하는 데 매우 유용한 도구이다.
  

 

3. SSR(Server Side Rendering) 에서의 JWT

서버사이드 랜더링 (Server-Side Rendering, SSR)의 일반적인 프로젝트에서 JWT를 사용하는 것은 여전히 유용할 수 있다.
그러나 SSR 환경에서의 JWT 사용에는 몇 가지 고려 사항이 있다.

1. 쿠키 vs 로컬 스토리지:
   • 클라이언트 사이드 렌더링에서는 JWT를 로컬 스토리지나 세션 스토리지에 저장하는 것이 일반적이다. 그러나 SSR에서는 쿠키를 사용하여 JWT를 저장하는 것이 더 일반적이다. 이는 서버에서 페이지를 렌더링 할 때 쿠키를 쉽게 읽을 수 있기 때문이다.
     
     
2. 보안:
   • 쿠키를 사용하여 JWT를 저장할 때는 HttpOnly 및 Secure 플래그를 사용하여 쿠키를 보호해야 한다. 이렇게 하면 스크립트를 통한 접근이 방지되고 HTTPS를 통해서만 쿠키가 전송된다.
     
     
3. 퍼포먼스:
   • SSR에서는 사용자의 요청마다 서버에서 페이지를 렌더링 한다. JWT를 사용하여 인증 정보를 빠르게 검증하면 서버의 응답 시간을 줄일 수 있다.
     
     
4. 상태 유지:
   • JWT는 상태가 없는 인증 방식이므로, 서버사이드 랜더링 환경에서도 세션 관리에 대한 추가적인 부담 없이 사용자 인증을 처리할 수 있다.
     
     
5. 토큰 만료:
   • JWT는 만료 시간을 가질 수 있으므로, 만료된 토큰에 대한 적절한 처리가 필요하다. SSR 환경에서는 만료된 토큰을 감지하고 사용자에게 적절한 응답을 제공해야 한다.
     
     

• 결론적으로, 서버사이드 랜더링 프로젝트에서 JWT를 사용하면 인증 및 권한 부여를 효과적으로 처리할 수 있다. 그러나 SSR 특성과 JWT의 특성을 모두 고려하여 올바르게 구현해야 한다.

 

 

 

 

Spring Boot 3 & Security 6 시리즈: SecurityConfig 클래스 작성하기 (2편)