Spring Security #3 아키텍처 이해하기, 인증 및 인가 원리

스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security - 인프런 | 강의

필터는 자바 웹 표준인 Servlet 2.3버전부터 추가된 기능이다.

스프링 시큐리티는 서블릿 필터 기반으로 동작하는 프레임워크이다.

 

2022.03 추가(리뷰내용)

Provider를 따로 만들지 않고, 그냥 기본 AuthenticationManager.authenticate(new token())을 호출해버린경우

 

단순히 패스워드를 비교하는 로직이라 따로 Provider를 만들지 않고, 시큐리티의 기본 프로바이더로 처리했습니다.
나중에 추가적인 인증이 필요하게 되면
public class CustomAuthenticationProvider implements AuthenticationProvider 같은 걸 추가하도록 하겠습니다 😀

---

시큐리티가 알아서 해준다라고 설명하니 조금 불안해서, 직접 코드를 뜯어봤는데

1. 로그인 과정에서 아래 코드를 실행합니다.

• authenticationManager의 구현체인 ProviderManager를 통해 해당 토큰을 처리할 수 있는 프로바이더를 찾습니다.

Authentication authentication = authenticationManager.authenticate(
            new UsernamePasswordAuthenticationToken(username, password)
        );

 

2. 따로 등록해둔 프로바이더가 없기 때문에, 기본 프로바이더인 DaoAuthenticationProvider 가 동작합니다.

• 이 프로바이더는 매니저에 등록된 UserDetailsService와 PasswordEncoder를 사용합니다.

    // SecurityConfig.java
    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(accountDetailsService).passwordEncoder(passwordEncoder());
        auth.authenticationProvider(jwtAuthenticationProvider); // 이건 JwtAuthToken 을 처리하는 Provider
    }

 

• DaoAuthenticationProvider 는 아래 클래스를 상속하며, UsernamePasswordAuthenticationToken 를 support 합니다.

public abstract class AbstractUserDetailsAuthenticationProvider{
... 생략 ...
	@Override
	public boolean supports(Class<?> authentication) {
		return (UsernamePasswordAuthenticationToken.class.isAssignableFrom(authentication));
	}

	@Override
	public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        ...
      try {
		      this.preAuthenticationChecks.check(user);
	              additionalAuthenticationChecks(user, (UsernamePasswordAuthenticationToken) authentication);
	 	  } 
	    catch (AuthenticationException ex) {
            ...
          }
        return createSuccessAuthentication(principalToReturn, authentication, user);
      }
}

 

3. 즉, Provider.authenticate(...)가 실행되면, 아래의 로직이 실행됩니다.

public class DaoAuthenticationProvider extends AbstractUserDetailsAuthenticationProvider {
... 생략 ...
	protected void additionalAuthenticationChecks(UserDetails userDetails,
			UsernamePasswordAuthenticationToken authentication) throws AuthenticationException {
		if (authentication.getCredentials() == null) {
			this.logger.debug("Failed to authenticate since no credentials provided");
			throw new BadCredentialsException(this.messages
					.getMessage("AbstractUserDetailsAuthenticationProvider.badCredentials", "Bad credentials"));
		}
		String presentedPassword = authentication.getCredentials().toString();
		if (!this.passwordEncoder.matches(presentedPassword, userDetails.getPassword())) {
			this.logger.debug("Failed to authenticate since password does not match stored value");
			throw new BadCredentialsException(this.messages
					.getMessage("AbstractUserDetailsAuthenticationProvider.badCredentials", "Bad credentials"));
		}
	}
...
}	

-------------------------------------------------------------

 

💭 스프링 시큐리티의 동작과정(복습)

기본적으로 자바 서블릿 필터의 경우, FilterChain을 구성하여 서블릿이 실행되기 전 필터를 거치게 된다.

 

스프링 시큐리티의 경우 서블릿 필터체인에 DelegatingFilterProxy를 등록한다. 이는 서블릿 필터의 구현체이다.

그리고 해당 필터가 SecurityFilterChain을 호출하고, 스프링에 등록된 빈을 가져와서 의존성을 주입하게 된다.  

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    // Lazily get Filter that was registered as a Spring Bean
    // For the example in DelegatingFilterProxy delegate is an instance of Bean Filter0
    Filter delegate = getFilterBean(someBeanName);
    // delegate work to the Spring Bean
    delegate.doFilter(request, response);
}

DelegatingFilterProxy 는 스프링 빈이 아니다. 서블릿 필터라서 실제 동작은 FilterChainProxy(스프링 Bean)에 위임한다.

즉 DelegatingFilter는 보안과 관련된 처리를 하지 않는다.

@EnableWebSecurity를 적으면 앱 시작시에 SecurityFilterAutoConfiguration 객체가 DelegatingFilter를 등록한다.

이후 WebSecurityConfiguration가 springSecurityFilterChain 이름의 스프링빈(=FilterChainProxy 클래스)을 등록한다.

전체적인 동작과정은 이러하다. DelegatingFilterProxy만 서블릿 필터이고, 나머진 AppContext에서 스프링 빈으로 관리된다.

 

 

• FilterChainProxy는 요청과 응답을 스프링 시큐리티 필터 체인에 위임하는 역할을 담당한다.
  [서블릿 ➡ 스프링 시큐리티의 진입점]이며, 서블릿에서 문제가 발생한다면 해당 객체에서 예외가 발생한다.

이미지 출처 https://limdevbasic.tistory.com/19

 

• FilterChainProxy는 앱당 하나지만, SecurityFilterChain은 여러 개로 구성할 수도 있다.
  즉 아래 그림처럼 DelegatingFilterProxy(필터)에 있는 FilterChainProxy(스프링 빈)에서
  HTTP URL에 따라 다른 스프링 시큐리티 체인이 작동하도록 구성할 수도 있다.
  

  

  SecurityFilterChain은 여러 개로 구성할 수도 있다.

  

  FilterChainProxy 코드를 보면 시큐리티 필터체인을 리스트로 가지고 있다.

📑 사용하는 입장에서의 동작과정

사용하는 입장에서 그림으로 그려보면 아래와 같다.

 

WebSecurityConfigurerAdpater를 통해 HttpSecurity를 생성한다.

import org.springframework.context.annotation.Configuration;
import org.springframework.core.annotation.Order;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

@Configuration
@EnableWebSecurity
@Order(0)
public class SecurityConfig1 extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.antMatcher("/admin/**")
            .authorizeRequests()
            .anyRequest().authenticated()
            .and()
            .httpBasic(); // HTTP BASIC 방식
    }
}

//.. 다른 패키지 ..//
@Configuration
@Order(1) // 이거 없으면 IllegalStateException: @Order on WebSecurityConfigurers must be unique. 발생
public class SecurityConfig2 extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
            .anyRequest().permitAll()
            .and()
            .formLogin(); // FORM LOGIN 방식
    }
}

FilterChainProxy는 Order 순서대로 먼저 비교한다. (비교하는데 각 필터의 RuestMacher를 사용)

예제처럼 여러개의 필터 체인을 사용하는 경우, Order(~) 순서는 넓은 범위의 보안설정을 먼저 적용해주는게 좋다.

숫자가 낮을 수록 Order(0) 우선순위가 높다.

 

실제 코드로 살펴보기 (FilterChainProxy)

FilterChainProxy 객체는 등록된 시큐리티 필터체인을 filters라는 리스트로 관리한다.

실제 FilterChainProxy를 보면 먼저 Request 요청에 따라 알맞은 시큐리티 필터체인을 선택한다.

리스트에 있는 시큐리티 필터들을 반복문으로 하나씩 request와 비교(matches)한다.

그 중 제일 먼저 찾은 필터를 사용하는데,
비교하는데 사용된 matches 메서드를 까보면 해당 시큐리티 필터 체인의 requestMatcher 객체를 이용한다.

 

📌 그래서 여러개의 스프링시큐리티 설정을 만들 때(=체인이 여러 개일 때) @Order가 필수인 것이다.

URL 요청이 같다면 @Order에 등록된 순서대로 먼저 필터가 매칭된다. 

 

앞에서 배웠지만 각각의 스프링 시큐리티 필터체인은, 따로 등록하지 않아도 많은 기본 필터가 적용되어있다.

이 필터들도 서블릿 필터( chain.doFilter() )처럼 동작하며 순서가 있다. 적용되는 순서와 종류는 공식문서를 참고하자.

알고있으면 좋긴한데, 워낙 종류가 많기도하고 모른다고해서 사용하는데 문제가 생기지는 않는다.

디버그를 찍어보면, http.formLogin()은 13개의 시큐리티 필터체인이 순서대로 동작함을 알 수 있다.

따로 필터를 등록하지 않더라도, 시큐리티 사용 시 기본적으로 추가되는 필터들이 있다.

 

 

💭 인증(Authentication)

인증은 로그인처럼, 내가 누구인지 증명하는 것이다.

인증 시 id와 password를 HTTP요청에 담고, 서버에 전달된다.

서버에서 인증 후, 인증 객체(User + 권한정보)에 담아 SecurityContext에 담고 전역적으로 사용할 수 있게 제공해준다.

Authentication authentication = SecurityContexHolder.getContext().getAuthentication()

이 객체에서는 아래와 같은 정보를 얻을 수 있다.

• principal : 사용자 아이디 혹은 User 객체를 저장
• credentials : 사용자 비밀번호 (보안상 인증이후 인증객체에는 사용할 수 없게 아예 비워두기도 함)
• authorities : 인증된 사용자의 권한 목록
• details : 인증 부가 정보 (나중에 언급)
• Authenticated : 인증 여부

인증객체가 생성되는 과정

인증정보는 SecurityContext에 담고 전역적으로 사용할 수 있게 제공해준다. 이게 어떻게 가능한걸까?

스프링시큐리티의 AuthenticationProcessingFilter에서 인증에 성공하면 시큐리티 컨텍스트에 인증개체를 넣는다.

정확히는 현재 스레드의 ThreadLocal 메모리에 SecurityContextHolder를 두고 static 메서드로 SecurityContext를 꺼낸다.

그리고 인증이 완료되면 HttpSession에 인증개체를 저장해서 스레드가 없어지더라도 전역적으로 사용할 수 있다.

그래서 SecurityContextHolder를 거치지않고, HttpSession에서 SecurityContext 객체를 바로 꺼내올 수도 있다.

 

✨ HttpSession이 뭐였더라..?

HTTP는 기본적으로 비연결성을 지향합니다.
즉 항상 클라이언트-서버가 연결되어있는게 아니라, 요청에 따른 응답 이후에는 연결이 끊어지게 됩니다.
그래서 내가 요청을 3번 보내더라도 서버 입장에서는 다른사람 3명이 각각 보내는 것과 같습니다. 상태가 없어요.

 

HTTP를 이용한 웹에서 로그인을 구현방법은 여러가지만, 대표적으로 HttpSession 객체를 이용 할 수 있습니다.

서버(WAS의 서블릿컨테이너)에서는 요청을 보내는 브라우저 단위로 Session 메모리를 생성합니다.
그리고 브라우저 요청이 들어오면 서블릿 컨테이너는 request 안에 HttpSession 객체를 생성하고, 

* 참고로 session을 요청하지 않으면 서블릿 컨테이너에서 HttpSession 객체를 만들지 않도록 최적화되어있음.

현재 서버 세션 메모리에 있는 세션을 JSESSIONID 로 찾아서 연결시켜줍니다. 

 

조금 정리해보자면

1. 서블릿 컨테이너가 Request마다 HttpSession 객체를 만듭니다. 
정확히는 httpServletRequest.getSession() 메서드가 호출되면 HttpSession 객체를 만들어서 반환합니다.

1-1. 참고로 스프링에서도 HttpSession을 그대로 받아와서 사용합니다.

다만 HttpSession을 @Autowired로 사용하면 HttpSession 객체를 프록시로 만들어서 Lazy하게 불러옵니다. 
즉 httpSession.setAttribute() 메서드를 호출하는 시점에 서블릿 컨테이너에서 요청하고 생성됩니다.
물론 컨트롤러 메서드 인자로 바로 받아오면 method(HttpSession session) 즉시 HttpSession을 받아옵니다.

2. HttpSession 객체를 통해 서블릿 컨테이너 안의 세션메모리에 접근 가능합니다.
세션 메모리는 브라우저 단위로 만들어지며, JSESSIONID을 기준으로 각 세션메모리를 구분해서 사용합니다.
(실제 톰캣의 세션생성 코드가 궁금하다면 https://semtax.tistory.com/92 참고)

물론 세션메모리도 서버에 부담이 되기때문에, 보통은 마지막 요청에서부터 30~60분정도만 유지되도록 만들어둡니다.

 

📑 SecurityContextHolder란

📌SecurityContext 

• 객체가 저장되는 보관소로 필요 시 언제든지 Authentication 객체를 꺼내어 쓸 수 있도록 제공되는 클래스
• ThreadLocal 에 저장되어 아무 곳에서나 참조가 가능하도록 설계함
• 인증이 완료되면 세션 저장소(HttpSession) 에 저장되어 어플리케이션 전반에 걸쳐 전역적인 참조가 가능하다

 

📌SecurityContextHolder

SecurityContext 저장소이다. Http 세션에 있는 S.C를 꺼내 Holder에 저장해둔다.

스프링 시큐리티에 있는 Holder 객체를 이용해서 위치와 상관없이 전역적으로 SecurityContext에 접근이 가능하다.

SecurityContext에 대해 아래와 같이 3가지 저장방법을 제공한다.

import org.springframework.security.core.context.SecurityContextHolder;

SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHEADLOCAL);

• MODE_THREADLOCAL(기본값) : 스레드당 SecurityContext 객체를 할당
• MODE_INHERITABLETHREADLOCAL : 메인 스레드와 자식 스레드에 관하여 동일한 SecurityContext 를 유지
• MODE_GLOBAL :  응용 프로그램에서 단 하나의 SecurityContext를 저장한다 (➡ Static 변수 사용)

SecurityContextHolder 소스코드. 그럴일은 거의 없겠지만 이를 커스텀해서 사용할 수도 있다.

MODE_INHERITABLETHREADLOCAL는 부모스레드, 자식스레드는 안써봤다면 생소할 수도 있는데

한 스레드(부모)안에서 새로운 스레드(자식)을 만드는 경우를 말한다. ThreadLocal은 스레드마다 주어지는 메모리이므로, 당연히 별도의 설정없이는 부모와 자식의 SecurityContext가 공유되지 않는다.

@GetMapping("/home")
public String helloHome(){
	
    // 자식 스레드 생성
    new Thread(
    	new Runnable(){
            @Override
            public void run(){
            	// 아래 메서드는 다른 Context를 반환한다. 현재 스레드와 공유되지 않는다.
                // 즉 방금 로그인을 해서 세션에 저장되었어도 여기에서는 사용할 수 없다. 
                Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
            }
        }
    ).start();
}

 

이를 그림으로 그려보면, 아래와 같다.

참고로 HttpSession에서는 SPRING_SECURITY_CONTEXT 라는 이름으로 자장된다.

위에서도 언급했지만, SecurityContextHolder에서 아무대서나 인증개체를 꺼내올 수 있다.

Authentication authentication = SecurityContextHolder.getContext().getAuthentication()

이름 그대로 Security Context 저장소이며, 아래와 같이 clear메서드로 현재 컨텍스트를 날려버릴 수도 있다.

SecurityContextHolder.clearContext() // SecurityContext 기존 정보 초기화

 

익명 사용자

• 새로운 SecurityContext를 생성하여 Holder에 저장한다.
• AnonymousAuthentication-Filter에서 AnonymousAuthentication-Token 객체를 SecurityContext에 저장한다.

 

인증 시

• 새로운 SecurityContext를 생성하여 Holder에 저장한다.
• UsernamePasswordAuthenticationFilter에서 인증 성공 후, S.C에 usernmaePasswordAuthentication을 저장
• 인증이 최종 완료되면 S.C PesistenceFilter가 세션에 S.C를 저장한다. (SPRING_SECURITY_CONTEXT : S.C 객체)

 

인증 후 

• 세션에서 S.C를 꺼내어 Holder에 저장한다.
• S.C안에서 Authentication 객체가 존재하는지 판단하고, 있다면 인증 과정없이 인증을 유지한다.

 

참고로 MODE_GLOBAL 모드가 아니라면, Http 응답이후에는 필요없으므로 Holder에서 S.C를 삭제한다.

SecurityContextHolder.clearContext() // 세션에는 남아있음. 현재 스레드 메모리 삭제

그래서 실제 필터순서도 2번째에 위치되어있다.

1번 인덱스에 SecurityContextPesistenceFilter가 매 요청마다 세션에서 S.C를 꺼내 Holder에 저장한다.

별거없다. 현재 세션에 S.C가 존재하는지 확인 후, 있다면 꺼내고 없다면 다음 필터로 이동.

 

 

 

📑 인증(Authentication) Flow

• 모든 요청은 Manager를 통해 진행된다. 하지만 Manager는 일종의 컨트롤러이고, 실제 인증은 Provider에 위임한다.
• Provider는 인증과정을 담당하며, 유저 데이터 조회가 필요하다면 UserDetailsService에 UserDeatils객체를 요청한다.
• UserDetailsService는 Repository에게 데이터를 요청하는 서비스객체이며, User를 UserDetails로 감싸 반환한다.
• 이렇게 Provider가 UserDetails를 받아 인증과정을 거쳐, 인증에 실패한다면 적절한 예외를 발생시킨다.
• 인증에 성공한다면 Provider는 UserDetails와 인가정보(authorities)를 한 객체 Authentication으로 만들어 반환하고
• 최종적으로 Manager가 Filter에 Authentication객체를 반환하면, 필터에서 S.C에 인증 값을 최종적으로 저장한다.

예외 발생시 Filter는 등록된 FailHandler를 실행한다.

이렇게 인증이 완료된 Autentication은 현재 Holder의 S.C에 저장되고, S.C는 세션에 저장된다.

이후 새로운 요청이 들어올 때, Holder가 S.C를 세션에서 꺼내와서 사용하고, 응답이후 S.C를 clear한다.

 

즉 S.C는 Http 요청-응답과 같은 생명주기를 가지며 서버에 있는 Holder를 통해 가져오고, 저장한다.

참고로 AuthenticationProvider에서 유저 검증 실패시, 아래와 같은 예외를 발생시킨다.

 

 

📑 인증 매니저 (AuthenticationManager)

매니저는 일종의 컨트롤러라고 했다. 실제 동작은 ProviderManager를 통해 진행된다.

provider는 우리가 직접 추가할 수 있다.

예를 들어 Form 인증요청이 들어왔다면, 이 인증이 가능한 Provider객체(Dao..Provider)를 찾아서 인증을 처리한다.

선택된 Provider 객체가 인증에 성공하면 매니저에게 Authentication 객체에게 반환하는 형식이다.

ProviderManager가 적절한 Provider를 찾는 과정

 

ProviderManager에는 parent 속성 값을 넣을 수 있다. (*상속 아님)

이는 현재 ProviderManager에 처리가능한 Provider가 없다면, 해당 parent값에 있는 ProvierManager에게 요청을 한다.

마치 트리 탐색처럼 처리가능한 Provider를 찾을 때까지 진행한다. 못찾았다면 예외 발생

참고로 스프링 시큐리티 초기화 과정에서, 기본값은 모든 provider를 탐색하지 않도록 만들어져있다.

AuthenticationManagerBuilder를 사용해서 이를 변경하면 parent가 연결되어 모든 Provider를 탐색하도록 바꿀 수 있다.

 

 

 

📑 인증 처리자 (AuthenticationProvider)

Filter ➡ Manager ➡ Provider.support(~) 를 통해 적절한 객체를 찾았다면 provider에서는 아래와 같이 동작된다.

특별한건 없고, Provider는 User객체를 직접 다루는게 아니라, UserDetails 객체로 다루게 된다.

모든 검증이 완료되면 Authentication 객체를 만들어 유저정보(Principal)와 권한정보를 담아 반환한다. 

인증 성공시 유저정보(pricipal), 비밀번호(credential), 권한(authorities)을 Authentication에 담는다.

인증 성공이후, S.C에 인증객체를 저장한다. 그리고 successHandler를 실행한다.

 

 

💭 인가(Authorization)

인증이 내가 누구인지 확인하는 과정이었다면,

인가는 누구인지 확인은 했으나 권한이 있는지 확인하는 과정이다.

스프링 시큐리티는 크게 3가지 계층으로 Authorization을 제공해준다.

• 웹 계층은 우리가 흔히 사용하는 URL, 즉 화면 단위의 권한을 지정하는 것을 말한다.
• 서비스 계층은 AOP와 인터셉터를 이용한 기능 단위의 보안기능이다. ➡ 서비스 메서드에 권한을 설정할 수 있다.
• 도메인 계층은 객체단위의 보안 기능이다. ➡ File, DB에 접근권한을 설정할 수 있다.

 

인가는 스프링 시큐리티 필터체인중, 가장 마지막 필터인 FilterSecurityInterceptor 필터에서 이루어진다.

• [앞의 필터들에서 인증된 사용자]에 대하여 특정 요청의 승인/거부 여부를 최종적으로 결정 
   ➡ 인증 객체 없이 보호자원에 접근을 시도할 경우 AuthenticationException 을 발생
   ➡ 인증 후 자원에 접근 가능한 권한이 존재하지 않을 경우 AccessDeniedException 을 발생
• 권한 제어 방식 중 HTTP 자원의 보안을 처리하는 필터
• 권한 처리를 AccessDecisionManager에게 맡김

 

 

📑 FilterSecurityInterceptor 의 동작

앞에서 인증객체가 만들어졌다면, SecurityMetadataSource 객체를 통해 필요한 권한정보를 가져온다.

참고로 인증 객체가 있으나, 인가(권한)정보가 없는 경우에도 별다른 동작을 하지 않는다.

가져온 attributes에는 우리가 설정한 권한 정보값들이 들어가있다.

그리고 AccessDecisionManager에게 권한정보를 주게되면, 현재 인증개체가 권한이 있는지를 판단한다.

 

 

물론 인증과 비슷하게 매니저는 컨트롤러 역할이며, 실제 인가는 AccessDecisionVoter 객체가 담당한다.

접근이 거부되면 FilterSecurityInterceptor를 호출한 ExceptionTranslationFilter에 예외를 반환한다.

필터 이름이 인터셉터인 이유는, 그림처럼 ExceptionTranslationFilter가 예외를 받아 처리해주기 때문이다.

 

 

 

📑 인가매니저 (AccessDecisionManager)

하나의 매니저는 여러개의 Voter 객체를 가지며, 인가(접근허용, 거부, 보류)에 해당하는 리턴 값을 받고 최종 판단함.

 

 

📑 AccessDecisionVoter

아래의 정보를 바탕으로 권한을 판단하며, 상수값을 반환함 (접근허용1, 접근거부0, 접근보류-1)

• Authentication 인증 정보( user )
• FilterInvocatior 요청 정보( antMatcher("/user") )
• ConfigAttributes 권한 정보 ( hasRole("USER") )

참고로 아래와 같은 상수 값을 가지고 있음.

• ACCESS_GRANTED (1) 승인
• ACCESS_DENIED (0) 거절
• ACCESS_ABSTAIN (-1) 보류
  보류는 해당 Voter가 판단을 내릴 수 없는 경우 사용함 

antMatcher(String antPattern)// HttpSecurity제공된 ant 패턴과 일치할 때만 호출되도록 구성할 수 있습니다.

mvcMatcher(String mvcPattern)// HttpSecurity제공된 Spring MVC 패턴과 일치할 때만 호출되도록 구성할 수 있습니다.

MVC Matcher(스프링 4.1.1)는 SpringMVC의 HandlerMappingIntrosepctor를 사용합니다. a

Ant Matcher(스프링 3.1)는 아파치의 Ant 문법을 사용합니다. Ant 옛날 빌드도구이고, bulid.xml에 사용되는 문법입니다.
위 두개의 Matcher는 RequestMatcher 인터페이스를 구현하고 있습니다.

 

 

일반적으로 Mvc Matcher가 더 안전합니다. API 서버가 아니라면 Mvc Matcher를 사용하면 됩니다.

antMatchers("/secured") // 해당 URL과 정확히 일치해야 합니다.

mvcMatchers("/secured") // /secured, /secured/ /secured.html /secured.xyz...를 포함합니다
// 이는 스프링 MVC의 @RequestMapping(....)과 같은 URL 규칙입니다.

antMatcher("/users/**") //matches any path starting with /users
antMatchers("/users") //matches only the exact /users URL
mvcMatchers("/users") //matches /users, /users/, /users.html

public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
  .authorizeRequests()
  .antMatchers("/users/movie/**") // matches any path starting with /users/movie
  .hasRole("ADMIN") ...
  }
}

---

💭 스프링 시큐리티 아키텍처 정리

처리할 내용이 없으면 다음 필터로 넘어간다. (chain.doFilter)

마지막 FilterSecurityInterceptor에서 권한(인가)까지 예외없이 완료되면 정상적인 접근이라고 생각하면 된다.