🔐 Spring Security 6

실제 운영 환경에서 REST API는 아무나 접근 가능한 완전한 오픈 API 상태로 서비스를 배포할 수는 없습니다. 이번 글에서는 Spring Security가 어떻게 기본 보안을 제공하는지, 그리고 Security 구조의 내부 동작을 단계별로 분석합니다.

이전 글에서는 Spring Security의 기본 설정과 내부 흐름을 학습하며 보안 필터가 요청을 어떻게 가로채고, 인증 과정을 어떻게 처리하는지 살펴봤습니다.

Spring Security는 단순히 로그인 로직을 제공하는 프레임워크가 아닙니다.사용자 자격 증명(credential)을 안전하게 저장하고 검증하기 위한정교한 해싱 시스템(PasswordEncoder)을 제공합니다.

이전 글에서 우리는 사용자의 인증(Authentication) 흐름을 완성했습니다. 이제 인증된 사용자가 무엇을 할 수 있는가, 즉 인가(Authorization)를 다룰 차례입니다. Spring Security는 인가를 세 가지 수준으로 제공합니다.

이제부터는 웹 보안의 가장 핵심적인 두 가지 주제, CORS와 CSRF를 다룬다. 이 둘은 프레임워크를 떠나 모든 웹 애플리케이션에서 발생할 수 있는 취약점이며, Spring Security의 기본 원리를 제대로 이해하기 위해서는 필수 개념이다.

이번 장에서는 Spring Security의 Stateful 인증(JSESSIONID)을 무상태(Stateless) JWT 구조로 대체한다. 기존 JSESSIONID + XSRF-TOKEN 쿠키 기반 인증은세션에 사용자 상태를 저장하고, 서버가 사용자 식별을 담당했다.

OAuth2(Open Authorization 2.0)는애플리케이션 간에 리소스 접근 권한을 안전하게 위임하기 위한 개방형 표준 프로토콜이다.

OAuth2와 OpenID Connect를 실무 수준에서 구현하는 가장 현실적인 접근. JWT를 기반으로 한 Stateless 인증은 강력하지만, 기업 환경(Enterprise)에서는 다음과 같은 현실적인 한계가 있다. ➡️ Keycloak.

Keycloak 없이, Spring Security 생태계 안에서 완전한 OAuth2 & OpenID Connect 인증 서버를 구현하기. 이전 편에서는 Keycloak을 이용해 외부 인증 서버를 “임대”하는 방식을 살펴봤다.

HTTPS, 예외 처리, 세션 관리, 이벤트 리스너까지 — Spring Security 실무 핵심을 마무리한다. HTTP(평문 통신)는 데이터가 암호화되지 않은 상태로 전송된다. HTTPS는 SSL/TLS 계층을 통해 요청과 응답을 암호화한다.