작성자

• 조상준

작성일

• 25.3.13

작성목적

• 요즘 프로젝트 진행 간에, 온보딩 문서를 자주 작성하는데, 팀내 추가 되는 서버 팀원들과 혹은 현재 함께 작업하는 팀원들의 이해도를 맞추기 위함이다. 각자 작업하는 파트가 다르기에 추후 장애 상황에 빠르게 대처하고, 불필요한 커뮤니케이션 비용을 줄이기 위해 아래 문서를 작성한다.

작성 후기

• 작성하고 보니, 이미 구현된 코드를 읽으면서 고려하지 않았던 Securtiy의 추가적인 기능을 여러가지 배워간다. 이미 보증된 보안기능을 제공하는 구현체(Spring Security)를 역으로 읽어가다 보니, 고려해야할 보안사항에 대한 키워드도 접할 수 있었다. 이래서 오픈소스를 읽어야 하나.. 예를 들어, Security의 userDetails Caching 기능이나, Timing Attack을 방지하는 대안 등 아래에 기술 하였다.

먼저 현재 프로젝트에 구현된 securtiy의 시퀀스 정리를 구분하자

• 로그인 시퀀스 (인증부터 AT,RT발급)
• API 요청에 앞선 AT 인증 & 만료시 에러 응답 시퀀스
• RT로 AT를 재발급 시퀀스
• 로그아웃 시퀀스
• Security 구현에 처음 접하는 팀원도 이해할 수 있도록 코드 수준까지 깊이있게 정리하였습니다. 추후 온보딩에 추가하면 좋을 것 같습니다.

1. 로그인 시퀀스

1. /api/auth/login Path로 로그인 요청이 오면, EmailPasswordAuthenticationFilter가 가로채어 (사진의 인증을 처리하는 필터 Authentication Filter 구현체이다.) attemptAuthentication() 메소드를 실행

   • EmailPasswordAuthenticationFilter의 정확한 상속관계

     • OncePerRequestFilter (Spring Security의 기본 필터) → AbstractAuthenticationProcessingFilter (인증을 위한 기본 로직 포함) → UsernamePasswordAuthenticationFilter (username + password 인증 필터)
     • 여기서 EmailPasswordAuthenticationFilter는 프로젝트 상황에 맞게 UsernamePasswordAuthenticationFilter를 커스텀한 필터이다.

   • attemptAuthentication() 메소드 내부 동작흐름

     

     • request body을 json 파싱하여 인증에 필요한 email과 password를 추출하고 이를 UsernamePasswordAuthenticationToken 에 담아, AuthenticationManager에게 인증 책임을 넘긴다.(AuthenticationManager.authenticate(authToken);) → 그림의 3번까지 수행
     • 여기서 **UsernamePasswordAuthenticationToken은 Authentication와 CredentialsContainer를 구현한 AbstractAuthenticationToken를 상속받는다. 클라이언트 측에서 받은 인증용 객체이며, 따라서 AuthenticationManager.**authenticate()의 파라미터는 Authentication타입이다!

2. 위의 메소드 실행으로 AuthenticationManager의 구현체 중 하나인, ProviderManager의 authenticate()가 실행된다. **ProviderManager.**authenticate()를 살펴보면, ProviderManager가 가지고 있는 List<AuthenticationProvider>에서 해당 Authentication을 처리할 수 있는 AuthenticationProvider를 찾는다.

   • 즉, AuthenticationManager(구현체: ProviderManager)의 역할은 파라미터로 받은 인증용 객체 Authentication(여기서는 UsernamePasswordAuthenticationToken)을 인증 처리 할 수 있는 Provider를 찾고, 해당 Provider에게 인증 책임을 넘긴다.

   

   • ProviderManager.authenticate()메소드에 대한 설명을 읽어보면, Authentication object를 처리할 수 있는 AuthenticationProvider를 찾는다.

     • 각 AuthenticationProvider가 순서대로 authenticate()를 실행하는 방식으로 찾는다. (처리 할 수 없다면, AuthenticationException을 던진다.)

   • 만약 여러 개의 Provider가 해당 인증 객체를 처리할 수 있다면?

     • Provider 중에 처음으로 인증에 성공하는 Provider가 인증 결과를 결정한다.

   • 만약 모든 Provider가 해당 인증객체를 처리 할 수 없다면?

     • 먼저, 부모 AuthenticationManager가 있다면 부모에게 인증을 위임한다.

     • 만약, 부모 인증 과정이 실패하는 경우 마지막으로 발생한 AuthenticationException이 최종적으로 던져진다!

       if (result == null && this.parent != null) {
           parentResult = this.parent.authenticate(authentication);
       }
       

   • Provider를 찾았다고 가정하자!

     • 아래의 try 구문에서 해당 Provider의 authenticate(Authentication authentication) 메소드를 실행하여, 인증 책임을 해당 Provider에게 넘긴다.
     • 이후, Provider가 인증을 마친 이후, 인증 결과를 다시 ProviderManager.authentication()메소드로 넘어오면(그림의 8번) result에 담아 Filter에 반환한다.(그림의 9번)
     • 해당 메소드가 인증 결과를 받고, Filter에 넘기는 과정(8,9번)은 아래에서 구체적으로 살펴본다. 또한 모든 Provider가 실패하여 부모 AuthenticationManager가 처리 가능한 인증Provider를 찾은 과정 또한 아래에서 설명한다.

   • 여기서, ProviderManager에서 궁금한 점🤨

     • 해당 인증 객체를 찾는 과정에서 모든 Provider를 다 실행하는 거 같다. 해당 토큰이 처리 가능한지만 보는게 아닌, 모든 메소드를 다 실행시키는 개념인듯.. 이거 좀 단순히 개선할 수 있는 방법이 있지 않을까? 나중에 오픈소스 좀 읽어보자!

3. 다시 짚고 넘어가면, 현재 프로젝트에서 사용 중인 인증 객체(Authentication)는 UsernamePasswordAuthenticationToken이다.

   

   해당 인증 객체를 처리 할 수 있는 Provider는 DaoAuthenticationProvider이다. 따라서 현재 구현사항에 맞게 Provider는 DaoAuthenticationProvider에 집중하여 설명할 것이다.

   // ProviderManager.authenticate 메소드
   try {
   				//**DaoAuthenticationProvider.authenticate()**호출!
   				result = provider.authenticate(authentication); 
   				if (result != null) {
   					copyDetails(authentication, result);
   					break;
   				}
   			}
   

   • 앞서, AuthenticationManager(구현체, ProviderManager)에서, AuthenticationProvider.authenticate 메소드(구현체, **DaoAuthenticationProvider.**authenticate())를 호출했다.
   • Provider의 authentication은 주요 인증 로직을 처리하는 곳이다! 앞서 책임 전가하던 클래스와 다르게 진짜 인증의 책임이 있는 클래스인 셈이다 ㅎ 이제 깊이 있게 살펴보자!
   • DaoAuthenticationProvider를 살펴보면, authenticate()메소드는 DaoAuthenticationProvider에서 찾아볼 수 없다.
   • 사실 DaoAuthenticationProvider는 AbstractUserDetailsAuthenticationProvider를 상속받고 있으며, 해당 AbstractUserDetailsAuthenticationProvider 내부에 authenticate() 메소드가 구현되어 있다.
   • 그럼 DaoAuthenticationProvider는 어떤 역할을 수행하는가?
     • authenticate() 내부에서 수행하는 주요 인증 로직을 오버라이드한 retrieveUser()와 additionalAuthenticationChecks() 메소드에서 구현하고 있다.
   • 즉, AbstractUserDetailsAuthenticationProvider.authenticate()에서 사용하는, retrieveUser()와 additionalAuthenticationChecks()를 DaoAuthenticationProvider에서 재정의하여 사용하고 있는 것이다.

4. 이제 AbstractUserDetailsAuthenticationProvider.authenticate()를 깊이있게 살펴보자

   

   1. 입력된 authentication 객체가 UsernamePasswordAuthenticationToken인지 확인한다.
      • 만약 다른 타입의 Authentication 객체가 전달되면 메시지와 함께 예외를 발생한다. (IllegalArgumentException)

   

   1. 사용자 이름(username) 추출
      • 해당 클래스에 정의 되어 있는 determineUsername()를 통해 이름을 추출한다.
      • 앞서 우리 서비스에서 username에 email을 넣었음을 잊지 말자

   

   1. 먼저 캐시에서 사용자 정보(UserDetails)가 있는지 조회한다.

      • 기본적으로 Spring Security는 사용자 정보를 캐싱할 수 있다. userCache는 기본적으로 비활성화 되어 있으며, 우리 서비스도 사용하지 않는다.
      • (userDetails의 캐싱가 궁금하다면, 다음 공식문서를 참고하자 https://docs.spring.io/spring-security/reference/servlet/authentication/passwords/caching.html) https://medium.com/@arpytoth/spring-security-caching-issue-3e62c21372f4
      • 따라서 캐싱된 user가 없기에, if (user == null) 구문에 진입한다.

   2. retrieveUser메소드에서 UserDetailsService에서 사용자 정보 조회

      • if문 안에서 본격적인 사용자 인증 로직을 시작한다.
      • 코드의 try문에서 retrieveUser()문을 호출하여, 사용자를 검색한다. retrieveUser메소드는 앞서 말한대로, DaoAuthenticationProvider에서 재정의(override)하여 구현 되어 있다. 따라서 DaoAuthenticationProvider.retrieveUser 메소드를 살펴보자

      

      • 먼저 인자로, String username**, UsernamePasswordAuthenticationToken** authentication를 받는다. 즉, 해당 메소드는 첫번째 인자인 username으로 DB에서 사용자를 찾고, 두번째 인자 authentication에 들어있는 password를 비교하여, 사용자 인증을 진행한다.
      • 본격적인 사용자 검색에 앞서, 한가지 보안 작업을 미리 수행한다. prepareTimingAttackProtection()을 실행하는데, 이는 타이밍 공격(Timing Attack)을 막기 위한 보안 기능이다.

        • 타이밍 공격을 간단히 설명하자면, 존재하는 계정의 요청 시간과, 존재하지 계정의 요청 시간이 다름을 이용해, 유효한 계정을 찾아내는 공격을 의미한다.

          

          

        • 따라서 Security는 prepareTimingAttackProtection()를 통해, 유효하지 않는 사용자의 경우에도 Password를 비교하는 로직을 수행할 수 있도록, 임의의 문자열(USER_NOT_FOUND_PASSWORD)을 해싱한(encode)한 값을 유효하지 않은 사용자의 비밀번호로 필드 값에 저장해두고, 비밀번호 비교 로직 실행 유무에 따른 시간 차이를 없애기 위한 준비를 해두는 것이다.

        • 자세한 내용은 추후 학습하고 문서화 할 계획이다.

      • 먼저, Authentication 객체(즉, 사용자한테 입력받은 username(우리는 username에 email이 저장), password)에서 email을 꺼내어 UserDetailsService에서 사용자 정보를 조회한다.
      • 해당 조회

5. 내부적으로 Provider를 찾고 UserService에 접근하는 로직은 별도로 작성하지 않음.(이미 구현되어 있어서 그냥 쓰면됨) 구체적으로 설명하면, Authentication을 인자로 받은 authenticationManager는(즉, 구현체는 ProvideManager) 해당Authentication을 기반으로 provider를 찾는다. 즉, 현 상황에서는 Authentication을 상속받은 UsernamePasswordAuthenticationToken에 맞는 provider를 찾아줄 것. authenticationManager 구현체인, providerManager 코드 읽어보면 감옴

6. 즉, provider를 찾으면, 해당 provider는 userDetailsService에 UsernamePasswordAuthenticationToken 의 사용자 username(현 구현에서는 username필드에 email을 넣어둠) 을 보내어 해당 정보를 DB에서 찾음

7. db에서 찾아 userdeatils에 담아 다시 provider에 보내줌