[Spring] Spring Security 맛보기

미루고 미루던 Spring Security를 슬슬 공부할 때가 된 듯 하다.... 그날이 왔도다

Spring 흐름에 대한 간단한 설명

Spring 흐름에 대한 자세한 설명

1. Spring Security란

Spring Security는 Spring 기반의 애플리케이션의 보안을 담당하는 스프링 하위 프레임워크이다.

로그인, 보안을 위한 인증 • 인가들을 개발하기 위해선 Spring Security를 많이 사용한다.

2. Spring Security 원리

Spring Security의 흐름은 다음과 같다.

요청(Request) → 필터(Filter) → 인증(Authentication) → 인가(Authorization)

(1) 요청(Request)

여기서 요청(Request)란 클라이언트가 서버로 보내는 모든 HTTP 요청을 의미한다.

서버는 한 번 인증했다고 해서 계속 로그인 상태임을 기억하지 않고, 기억력이 없는 존재(Stateless)로 설계된다.

따라서 요청이 들어올 때 마다 "이 요청을 보낸 사람이 아까 그 사용자라는 증거가 어딨지" 라는 생각을 하는데, 그 증거가 바로 JWT 토큰이고, 그걸 검사하는 것이 JWTFilter이다.

CRUD와 같은 여러 RestfulAPI 요청이 들어올 때 마다, Authorization 헤더에 있는 JWT를 JWTFilter가 매번 확인한다.

(2) 필터(Filter)

요청이 들어오면 필터 체인(Filter Chain)이 여러 필터들을 나열해서, 요청이 들어올 때 마다 이 필터들을 줄줄이 검사하게 된다.

대표적인 필터는 아래와 같다.

• UsernamePasswordAuthenticationFilter(일반 로그인) : 폼 기반 인증 처리 - LoginRequest와 같은 ID/PW 요청을 처리하고 Authentication 객체를 생성한다.
• JWTAuthenticationFilter / JWTAuthorizationFilter(JWT 로그인) : JWT 기반 인증 처리 - 요청 헤더의 JWT 토큰을 추출하여 사용자를 인증한다(사용자가 구현하는 필터).
• SecurityContextPersistenceFilter : 인증 정보 유지 - 인증 성공 후 SecurityContext에 Authentication 객체를 저장하거나 조회한다. 요청이 시작될 때 이전에 저장된 SecurityContext가 있다면 읽어서 불러오고(JWT에선 보통 비활성화됨) 요청이 끝나면 SecurityContext를 clear(삭제)한다.
• ExceptionTranslationFilter : 예외 처리 - 인증 및 인가 예외를 처리하고 적절한 HTTP 응답 코드를 반환한다.
• FilterSecurityInterceptor(마지막 권한 체크) : 최종 인가 처리 - 리소스 접근 전 마지막으로 권한(Authority)을 확인하여 인가(Authorization)를 결정한다. - 일반 Interceptor과 헷갈리지 말것.

참고

• Persistence : 지속성, 끈기
• SecurityContext :  스프링 시큐리티에서 "지금 이 요청을 보낸 사람에 대한 인증(로그인)정보가 들어 있는 작은 가방" 같은 느낌. 스프링에서 JWT같은 인증 과정을 걸쳐서 "인증된 사용자"임이 확인이 되면, 그 인증 결과를 SecurityContext에 보관한다. 이 SecurityContext 안에 들어 있는 정보는 Authentication 객체이다. 
• Authentication 객체 : 인증의 결과를 담고 있는 핵심 객체. 누가 요청했는지(username), 그 사람의 권한(ROLE_USER, ROLE_ADMIN), 인증이 됬는지(Boolean) 이 들어있다.
• Authentication 객체의 역할 - GPT피셜👽

1. 사용자 정보 (Principal & Credentials)
Principal (주체): 현재 시스템에 접근하려는 사용자를 나타냅니다. 보통 사용자 이름(username), 사용자 ID, 또는 사용자 상세 정보(UserDetails) 객체 자체가 될 수 있습니다.
Credentials (자격 증명): 사용자의 비밀번호나 토큰과 같이 사용자가 자신이 주장하는 사람임을 증명하는 데 사용되는 정보입니다. 인증이 완료된 후에는 보안을 위해 이 정보는 보통 지워집니다.
2. 인증 상태 (Authenticated)
isAuthenticated() 메서드를 통해 이 객체가 나타내는 사용자가 인증되었는지(true) 또는 인증 전인지(false) 상태를 나타냅니다.
3. 권한 정보 (Authorities)
인증된 사용자가 가진 권한 목록(GrantedAuthority)을 담고 있습니다. 예를 들어, ROLE_ADMIN, ROLE_USER 등의 정보를 담고 있어, 이후 인가(Authorization) 단계에서 사용자가 특정 리소스에 접근할 수 있는지 판단하는 근거가 됩니다.

필터가 차례 차례 요청을 넘기는데, 필터 중간에 인증이 완료된다면 뒤의 필터들은 인증이 완료된 유저 정보(SecurityContext)를 그대로 사용한다.

따라서 인증이 완료됬다면 SecurityContext 생성 & Authentication 객체가 저장된다. 

(3) 인증(Authentication)

1) AuthenticationManager가 진짜로 로그인을 검증

로그인 시도(아이디/비밀번호 인증)가 들어오면 AuthenticationManager가 등장에서 다음을 수행한다.

• 유저 정보(loadUserByUsername) 가져오기
• 비밀번호 확인
• 성공하면 Authentication 객체 생성
• SecurityContext에 저장

이걸로 "로그인 됨" 상태가 만들어진다.

 

2) SecurityContext에 사용자 정보 저장

SecurityContext는 "이번 요청에서 인증된 유저 정보 저장소"이다.

• 인증에 성공하면 Authentication 객체를 저장
• 컨트롤러에서 @AuthenticationPrincipal 같은 것을 쓰면 그 정보를 읽을 수 있다.
• 요청이 끝나면 사라진다.

즉, 한 번의 요청 동안만 로그인 상태를 유지하는 임시 메모장과 같은 것이다.

+ 내 코드를 바탕으로 한 Spring Security이의 흐름

 

단계	주체	동작	결과
1. 요청 생성	Client	사용자 이름과 비밀번호를 담아 로그인 요청(/login)	LoginRequestDTO
2. 인증 요청	AuthService	LoginRequest를 기반을 인증 전 토큰(UsernamePasswordAuthenticatoinToken) 생성	Authentication 객체(Unauthenticated)
3. 인증 위임	LoginHandler	토큰을 AuthenticationManager에게 전달
4. 인증 수행	AuthenticationManager	요청을 처리할 수 있는 AuthenticationProvider에게 위임
5. 사용자 로드	AuthenticationProvider	UserDetailService를 통해 DB에서 사용자 정보(UserDetails) 로드
6. 검증	AuthenticationProvider	PasswordEncoder로 비밀번호 비교
7. 성공, 실패	AuthenticationProvider	성공 시 권한이 담긴 인증 완료 토큰 반환	Authentication 객체(Authenticated)
7. 컨텍스트 저장	AuthService	인증 완료된 Authentication 객체를 SecurityContextHandler에 저장	인증 정보 유지

(4) 인가(Authorizatoin) - 권한 체크

필터 체인의 마지막 쯤에서 FilterSecurityInterceptor가 "이 유저가 이 URL에 접근할 권한이 있는가?"를 체크한다.

• ROLE_USER는 /mypage 가능
• ROLE_ADMIN은 /admin 가능

권한이 없으면 403 Forbidden.

주의!
FilterSecurityInterceptor과 일반 HandlerInterceptor를 헷갈리지 말것.
• FilterSecurityInterceptor : 인증 및 인가 단계에서 실행 및 완료
• 일반 HandlerInterceptor : DispatcherServlet이 핸들러를 찾은 직후, 컨트롤러 실행 '직전'에 동작함

이렇게 이해하면 되겠다

3. Spring MVC 전체 요청 흐름

Client → Filter → DispatcherServlet → Interceptor → Controller

맞다. 이게 내가 원래 공부했던 Spring MVC 패턴이다. 여기에 대입해서 설명할거다.

1. 클라이언트가 요청을 보냄
2. "서블릿 필터"가 먼저 실행됨  ← 여기에 위에서 설명한 Spring Security Filter chain들 있어요🙌
3. DispatcherServlet이 요청을 잡음
4. Interceptor가 동작
5. Controller 실행
6. 응답 반환...

즉 앞서 말한 Spring Security의 흐름은 "Filer Chain"의 내부 모습을 확대해서 본 것이라 봐도 무방하다.

• Interceptor에 대한 정리에 대한 글

DispatcherServlet이란? (복습 겸)

웹 요청이 들어오면 Spring MVC는 그걸 어느 컨트롤러에서 처리해야 하는지 연결해야 하는데, 그 흐름을 조종하는 친구가 DispatcherServlet이다.

• Filter → 학교 정문 경비 아저씨
• DispatcherServlet → 교무실에서 “이 학생 어디 반으로 보내야 하지?” 정리하는 교사
• Controller → 실제 수업(비즈니스 로직)을 담당하는 반

MVC 요청 흐름에서 DispatcherServlet은 중심 허브이다.

 

DispatcherServlet의 역할은 다음과 같다.

• URL을 보고 어떤 Controller을 호출해야 하는지 결정
• Controller 실행
• Controller가 반환 값을 ViewResolver로 전달
• 최종 JSON, HTML을 만들어서 응답 완성

참고로 Dispatch는 급파하다, 파견하다의 의미를 가지고 있으며 받은 요청을 어딘가로 빨리 보내는 서블릿이라는 뜻이다.

Spring이 없는 Java 런타임은 컨트롤러가 존재하지 않기 때문에 서블릿 객체를 생성하고 그것을 web.xml에 일일히 다 등록해야 했는데, DispatcherServlet은 이러한 단점을 해결해준다.

서블릿에 대한 개념은 여기 참조

 

 

[참고 자료]

https://mangkyu.tistory.com/76

[SpringBoot] Spring Security란?

https://prao.tistory.com/entry/Spring-Security-Spring-Security%EC%99%80-JWT-%EC%A0%81%EC%9A%A9-%EA%B3%BC%EC%A0%95

[Spring Security] Spring Security와 JWT 적용 과정

https://jiwon.oopy.io/1cfde91b-5fd3-4851-9419-9045d971d2cf

Spring Security 구조 이해하기

https://velog.io/@seculoper235/2.-DispatcherServlet-%EC%9D%B4%EB%9E%80

2. DispatcherServlet 이란?