JWT 토큰을 이용한 인증방식 개선: HTTP 헤더에서 쿠키 기반 인증 방식으로

안녕하세요.

오늘은 최근 회사에서 진행 인증 방식을 개선한 내용을 정리해보도록 하겠습니다.

1. 기존 인증방식

HTTP 헤더를 이용한 JWT 인증

기존에는 클라이언트가 서버와 통신할 때, JWT(Json Web Token)를 HTTP 헤더의 Authorization 필드에 포함하여 요청을 보내고 이를 인증하는 방식이었습니다. 이 방식은 주로 다음과 같이 동작합니다.

 

기존 인증 방식 흐름

1. 클라이언트가 로그인 시 서버에서 JWT 토큰 (access token, refresh token)을 발급
2. 클라이언트는 API 요청 시 HTTP 헤더의 Authorization 필드에 access token을 포함하여 보냄
3. 서버는 Authorization 헤더에 포함된 토큰을 검증한 후 요청을 처리
4. 토큰이 만료되었을 경우, refresh token을 사용해 새로운 access token을 재발급
5. refresh 토큰이 만료되었을 경우, 로그아웃 처리

기존 인증 방식의 문제점

• 브라우저 환경에서 토큰 관리의 어려움 클라이언트가 직접 localStorage 또는 sessionStorage에 토큰을 저장해야 하며, 이를 관리하는 로직이 필요함
• XSS(Cross-Site Scripting) 공격에 취약 JavaScript 코드로 localStorage에 저장된 토큰이 탈취될 경우, 공격자가 이를 이용해 세션을 탈취할 가능성이 있음
• 자동 인증 유지가 어려움 Authorization 헤더를 항상 추가해야하며, 여러 도메인을 사용할 경우 각각 헤더에 값을 설정해줘야 한다.

2. 개선된 인증 방식

JWT 토큰을 이용한 쿠키 기반 인증

위 문제를 해결하기 위해, JWT 토큰을 HTTP 쿠기(Cookie)에 저장하여 인증을 수행하는 방식으로 개선하였습니다.

 

개선된 인증 방식 흐름

1. 클라이언트가 로그인 시 서버에서 JWT 토큰 (access token, refresh token)을 쿠키에 저장 (HttpOnly, Secure 옵션 적용)
2. 이후 클라이언트가 API 요청을 보낼 때 자동으로 쿠키가 서버로 전송 됨 (브라우저가 관리)
3. 서버는 요청에서 쿠키를 확인하고 인증을 수행
4. 만료된 access token은 refresh token을 이용해 재발급하여 다시 쿠키에 저장

쿠키 인증 방식의 특징

• 토큰을 HttpOnly 쿠키에 저장하여 XSS 공격 방지
  • HttpOnly 속성을 사용하면 JavaScript에서 쿠키에 접근할 수 없으므로, 악성 스크립트에 의해 토큰이 탈취되는 것을 방지할 수 있음
  • CSRF(Cross-Site Request Forgery) 보호 가능
    • SameSite=Strict 또는 SameSite=Lax 설정을 통해 CSRF 공격을 방어할 수 있음.
  • 자동 로그인 유지
    • 브라우저가 쿠키를 자동으로 전송하므로, Authorization 헤더를 추가하는 번거로움이 사라짐

3. 인증 방식 변경 이유

• 클라이언트 측의 사용 편의성 향상
  • 기존 방식에서는 클라이언트가 직접 JWT를 저장 및 관리해야 했으나, 쿠키 기반 인증 방식에서는 브라우저가 자동으로 JWT를 관리
  • API 요청마다 Authorization 헤더를 추가할 필요 없이 자동으로 인증이 수행됨
  • access token이 만료되었을때, refresh token을 사용해서 토큰을 갱신하는 요청을 따로 보내지 않아도 됨
• 보안성 향상
  • HttpOnly 속성을 통해 XSS 공격으로 인한 토큰 탈취를 방지
  • Secure 옵션을 적용하면 HTTPS 환경에서만 쿠키가 전송되므로, 네트워크 공격에 대한 보안이 강화됨
  • SameSite=Strict 또는 SameSite=Lax 설정으로 CSRF 공격을 방어
• 유지보수 및 확장성 증가
  • 토큰을 클라이언트 측에서 직접 관리하지 않으므로, 인증 관련 로직이 단순화됨
  • 브라우저의 기본 쿠키 관리 기능을 활용하여 다양한 환경(웹, 모바일)에서 인증이 쉬워짐

결론 및 성과

• 기존의 JWT 헤더 방식보다 보안성이 크게 향상 됨 XSS 및 CSRF 공격 방어 기능
• 클라이언트 개발 경험 개선 브라우저가 자동으로 쿠키를 관리하여 API 요청시 별도의 헤더를 추가할 필요 없음
• 유지보수 비용 절감 토큰 관리 로직이 단순화되어, 클라이언트 측에서 불필요한 로직을 줄일 수 있었음

---

웹 애플리케이션 보안에서 중요한 두 가지 공격 기법에 대해서 간단하게 알아보자.

1. XSS(Cross-Site Scripting) 공격

사용자가 웹 사이트를 방문할 때, 악성 스크립트(JavaScript)가 실행되도록 하는 공격입니다. 주로 입력값을 검증하지 않거나, 신뢰할 수 없는 데이터를 그대로 출력하는 취약점을 이용하여 공격자가 클라이언트(웹 브라우저)에서 악성 코드를 실행되도록 하는 공격입니다.

 

방어 방법

1. 입력값 검증 (Input Validation)
   1. 사용자가 입력하는 데이터에서 스크립트 관련 문자는 필터링 하여 제거한다.
2. 출력 시 인코딩
   1. <script> 같은 태그가 브라우저에서 실행되지 않도록 HTML 엔티티로 변환한다.
3. Content Security Policy 적용
   1. 외부에서 로드 된 악성 스크립트 실행을 차단하는 브라우저 보안 정책이다.
   2. Content-Security-Policy: default-src 'self'; script-src 'self'
   3. ‘self’만 허용하면, 같은 도메인에서만 스크립트를 실행할 수 있다.
4. HttpOnly & Secure 쿠키 사용
   1. 공격자가 쿠키를 탈취하는 것을 방지하기 위해 쿠키를 HttpOnly 옵션으로 설정한다.
   2. HttpOnly 옵션: JavaScript에서 쿠키 접근을 차단
   3. Secure 옵션: HTTPS 환경에서만 쿠키 전송 허용
5. eval(), innerHTML, document.write() 같은 함수는 사용을 피한다.

2. CSRF(Cross-Site Request Forgery) 공격

사용자가 인증된 상태에서 공격자가 원하지 않는 요청을 실행하도록 유도하는 공격입니다.

즉, 공격자가 피해자의 세션을 이용해 본인에게 유리한 요청을 보낼 수 있도록 하는 것입니다.

 

방어 방법

1. CSRF 토큰 사용
   1. 서버에서 난수 기반 토큰을 생성하여 요청시 함께 전달한다.
2. SameSite 쿠키 설정
   1. 다른 도메인에서 자동으로 쿠키가 전송되지 않도록 설정
   2. Strict 모드: 같은 사이트 내에서만 쿠키가 전송됨
   3. Lax 모드: GET 요청만 허용
3. Referer/Origin 검증
   1. 요청을 보낸 사이트의 도메인을 확인하여 신뢰할 수 있는 출처만 허용
   2. CSRF 공격은 보통 공격자의 사이트에서 발생하므로 출처(Origin)를 확인하는 것이 효과적이다.
4. CORS 정책 적용
   1. Cross-Origin Resource Sharing 정책을 설정하여 신뢰할 수 있는 도메인에서만 API 요청을 허용한다.
   2. credentials: true 옵션을 추가하면 쿠키 기반 요청을 안전하게 처리 가능하다.
5. GET 요청에서 중요한 작업 제한
   1. CSRF 공격은 보통 자동으로 실행 가능한 GET 요청을 악용한다. 중요한 작업은 반드시 POST/PUT 요청에서 처리해야한다.

3. XSS vs CSRF 차이점

구분 XSS (Cross-Site Scripting) CSRF (Cross-Site Request Forgery)

목적	클라이언트(브라우저)에서 악성 스크립트 실행	사용자의 세션을 악용하여 공격자가 요청을 전송
공격 대상	브라우저에서 실행되는 스크립트 (JavaScript)	웹 서버 및 사용자 세션
조건	공격자가 직접 실행되도록 유도해야 함	사용자가 로그인한 상태에서 공격자가 요청을 보내야 함
방어 방법	입력값 검증, CSP, HttpOnly 쿠키	CSRF 토큰, SameSite 쿠키, CORS