스프링 시큐리티(Spring Security)
스프링 기반 애플리케이션의 인증(Authentication)과 인가(Authorization)를 담당하는 보안 프레임워크. 강력한 확장성으로 요구사항에 맞춰 쉽게 커스터마이징할 수 있다.
1) 스프링 시큐리티 한줄 개요
- 스프링 하위 프레임워크로 인증/인가를 표준 방식으로 제공
- 모든 요청을 필터 체인으로 가로채어 보안 처리
- CSRF 방어, 세션/토큰 인증, 확장 가능한 인증/권한 처리 지원
2) 핵심 개념 정리
- 인증(Authentication): “누구인지” 확인
- 인가(Authorization): “무엇을 할 수 있는지” 확인
- 보안 주체(Principal): 보호 자원에 접근하는 유저(자격 증명은 Credential)
3) 보안 필터 체인 요약 (Authentication Filter Chains)
요청 → 다층 보안 필터 통과 → 컨트롤러
| 필터 | 역할 요약 |
|---|---|
| SecurityContextPersistenceFilter | SecurityContext 로딩/저장 |
| LogoutFilter | 로그아웃 처리 후 즉시 종료 |
| UsernamePasswordAuthenticationFilter | 폼 로그인 인증 수행 |
| DefaultLoginPageGeneratingFilter | 기본 로그인 페이지 제공 |
| AnonymousAuthenticationFilter | 비인증 사용자에 익명 권한 부여 |
| SessionManagementFilter | 세션 타임아웃/동시 세션/세션 고정 방어 |
| ExceptionTranslationFilter | 인증/인가 예외 → 401/403 처리 또는 리다이렉트 |
| FilterSecurityInterceptor | 자원 접근 권한 최종 판정 |
핵심 포인트
- 인증 담당:
UsernamePasswordAuthenticationFilter - 인가 담당:
FilterSecurityInterceptor
4) 로그인 처리 흐름(요청 → 인증 완료)
- 브라우저가 아이디/비밀번호 전송
- AuthenticationFilter가
UsernamePasswordAuthenticationToken생성 - AuthenticationManager가 Provider 목록에서 처리 가능 대상 탐색
- 적합한 AuthenticationProvider 선택
- UserDetailsService의
loadUserByUsername()호출 - DB 조회 후
UserDetails반환 → 인증 검증 - 성공 시
SecurityContextHolder에 Authentication 저장 → 이후 어디서든 조회 가능
5) 인증 방식 비교: 세션 vs 토큰
| 구분 | 세션(Session/Cookie) | 토큰(Token) |
|---|---|---|
| 저장 위치 | 서버(세션 저장소) | 클라이언트(로컬스토리지/쿠키 등) |
| 장점 | 구현 간단, 서버에서 즉시 무효화 가능 | 서버 확장 용이, 무상태(Stateless) |
| 단점 | 확장 시 부담(Sticky/Clustering/외부 세션 저장소 필요) | 탈취 시 위험(민감정보 금지, 만료·재발급 전략 필수) |
| 확장 전략 | Sticky, Clustering, 외부 세션 저장소(예: Redis) | 짧은 Access + 긴 Refresh 조합, 재발급 플로우 |
6) JWT 한눈에 보기
인증 서버가 발급하는 서명된 토큰. 클라이언트가 요청마다 전송하고 서버는 서명 검증만으로 신뢰할 수 있다.
- Header: 알고리즘/타입 (예: HS256, JWT)
- Payload: 클레임(iss, sub, exp 등 표준 + 커스텀)
- Signature: 헤더+페이로드에 비밀키로 서명(무결성 보장)
운영 팁
- 민감정보 저장 금지(식별자/역할 정도만)
- Access 토큰 만료 짧게, Refresh 토큰으로 재발급
- 키 관리/키 롤오버 정책 수립
7) 체크리스트
- 인증/인가 책임을 컨트롤러 앞 필터 체인에서 일관 처리하고 있는가
UserDetailsService와PasswordEncoder가 올바로 연동되는가- 세션 기반일 때 확장 전략(저장소/동시 로그인/세션 고정 방지) 준비되어 있는가
- 토큰 기반일 때 만료·재발급·블랙리스트/로그아웃 전략이 있는가
- CSRF 방어 설정이 요청 특성(폼 vs API)과 맞는가
8) 요약
- 스프링 시큐리티는 필터 체인 기반으로 인증/인가를 표준화
- 로그인은
Authentication → Provider → UserDetailsService흐름으로 처리 - 세션은 단순하지만 확장에 부담, 토큰은 확장에 유리하지만 안전한 운용 전략이 필수
- JWT는 경량·무상태 인증에 적합하며 만료/재발급/키 관리가 핵심 포인트
개발자 희망자