Spring Security 내부 흐름 이해하기

 

 매번 인증, 인가에 대한 부분에 대해 제대로 숙지하지 않고, 코드만 가져다가 사용한 경우가 많았다. 회사에서도 이에 대해 다룰 수 있는 기회가 없다 보니 최근 토이 프로젝트로 패션 이커머스 플랫폼을 구현하면서 스프링 시큐리티에 대해 공부도 해보고, 어느 정도 기본적인 이해를 하며 적용하게 되었다.
주로 유데미(Udemy)의 스프링 시큐리티 강의를 듣고 이해한 내용을 정리하였고, 스프링 시큐리티의 기본 동작 흐름에 대해 작성하였다.

 

 

Spring Security란?

Spring 공식 홈페이지(https://spring.io/projects/spring-security)에서는 Spring Security를 아래와 같이 소개하고 있다. 공식 홈페이지가 제일 정확하고 자세하게 설명이 되어있으니 만약 더 알고 싶다면 위 링크로 접근하여 참고해 보길 추천한다.

Spring Security는 강력하고 사용자 정의가 가능한 인증 및 액세스 제어 프레임워크입니다. 이는 Spring 기반 애플리케이션 보안을 위한 사실상의 표준입니다. (구글 번역)

 

 

 

 

Spring Security 사용 이유?

 

 만약 우리가 스프링 시큐리티를 사용하지 않고 직접 인증, 인가에 대한 기능을 코드로 구현한다면 어떨까? 물론 가능하지만 이건 분명 어려운 일이 될 거라 생각한다. 왜냐하면 매일 수 백개의 보안 취약점이 밝혀지고, 보안 위반 사항이 일어나기에 항상 주의를 기울인다는 것이 쉽지 않기 때문이다.

 

 스프링 시큐리티는 기본적인 보안 취약점(CSRF, CORS 등)에 대한 것을 다룰 뿐만 아니라, 매일 새로운 취약점에 대해서도 보안 전문가들이 업데이트를 해준다. 우리는 스프링 시큐리티 프레임워크를 사용함으로써 이에 대해 신경을 쓰지 않고, 비즈니스 로직에 집중해서 개발할 수 있게 된다.

 

 

 

 

Spring Security 흐름

 

 

 

 

스프링 시큐리티의 내부 흐름에 대해 그려보았다. 중요한 부분이니 그림과 설명을 같이 보면서 흐름에 대해 이해해 보자.

 

 

우선 첫 번째로 유저로부터 로그인 자격을 얻기 위한 요청을 받는다. Security Filter는 이 요청을 가로채서 유저가 보낸 Username과 Password를 추출하고, 두 번째 단계에서 인증 객체로 변환한다. 

 이제 Security Filter는 이 요청을 세 번째 흐름인 AuthenticationManager에게 넘기게 된다. 이 AuthenticationManager는 실질적인 인증 로직을 담당하며, 네 번째 흐름에 따라 애플리케이션 내에 어떤 AuthenticationProvider가 존재하는지 확인하는 역할을 한다. AuthenticationProvider는 앱 내부에 여러 개 존재할 수 있으며, 사용자의 요구 사항에 따라 마음껏 구현이 가능하다. 각 AuthenticationProvider는 인증에 대한 성공, 실패를 나타내고, 실패의 경우 남은 AuthenticationProvider에게 인증 시도를 수행하게 된다. 모든 시도에서 인증 실패한 시점에서야 유저에게 인증이 실패했다고 응답하게 된다.

AuthenticationProvider에서 인증 로직을 직접 구현해도 되나, 스프링 시큐리티에서 제공하는 인터페이스, 클래스인 UserDetailsManager, UserDetailsService(다섯 번째)를 활용할 수도 있다.

인증서 내부에는 비밀번호가 있는데, 이 비밀번호를 평문으로 저장하게 되면 보안 측면에서 취약하기 때문에 스프링 시큐리티에서 제공하는 PasswordEncoder(여섯 번째)로 암호화 또는 해싱을 하게 된다.

AuthenticationProvider의 프로세싱이 끝나면 이제 다시 일곱 번째 흐름에 따라 AuthenticationManager에게 넘긴다. 이 정보들은 다시 Security Filter로 전달(여덟 번째)되며, 유저에게 Response를 전달하기 전에 두 번째 과정에서 만든 인증 객체를 아홉 번째 흐름에 따라 Security Context에 저장하게 된다. Security Context에 저장되는 인증 객체에는 인증이 성공적이었는지, 세션 ID는 무엇인지에 대해 저장된다. Security Context에 이러한 정보를 저장하고 있기 때문에 유저의 두 번째 요청부터는 해당 유저의 자격 증명을 요구하지 않게 된다.

성공적으로 인증 정보가 Security Context에 저장되었다면, 유저는 웹 접근이나 REST API로 접근하려 했을 때, 열 번째 흐름에 따라 유저에게 정보가 반환된다.

 

여기까지가 Spring Security의 내부 흐름이다.

 

 

 

 

Spring Security 흐름 (코드)

 

어느 정도 기본적인 흐름에 대한 이해가 갔다면 이제 코드로 내부 흐름을 살펴보자.

우선 Spring Security Filter부터 살펴볼 건데, 필터는 여러 종류가 있지만 그중에서 중요한 역할을 하는 필터 3개만 코드로 확인해 보겠다.

 

 

1-1. Spring Security Filter ( AuthorizationFilter )

 

첫 번째는 AuthorizationFilter이다.

package org.springframework.security.web.access.intercept;

public class AuthorizationFilter extends GenericFilterBean {
    private final AuthorizationManager<HttpServletRequest> authorizationManager;
    private AuthorizationEventPublisher eventPublisher = AuthorizationFilter::noPublish;
    private boolean observeOncePerRequest = true;
    private boolean filterErrorDispatch = false;
    private boolean filterAsyncDispatch = false;

    public AuthorizationFilter(AuthorizationManager<HttpServletRequest> authorizationManager) {
        Assert.notNull(authorizationManager, "authorizationManager cannot be null");
        this.authorizationManager = authorizationManager;
    }

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws ServletException, IOException {
        HttpServletRequest request = (HttpServletRequest)servletRequest;
        HttpServletResponse response = (HttpServletResponse)servletResponse;
        if (this.observeOncePerRequest && this.isApplied(request)) {
            chain.doFilter(request, response);
        } else if (this.skipDispatch(request)) {
            chain.doFilter(request, response);
        } else {
            String alreadyFilteredAttributeName = this.getAlreadyFilteredAttributeName();
            request.setAttribute(alreadyFilteredAttributeName, Boolean.TRUE);

            try {
                AuthorizationDecision decision = this.authorizationManager.check(this::getAuthentication, request);
                this.eventPublisher.publishAuthorizationEvent(this::getAuthentication, request, decision);
                if (decision != null && !decision.isGranted()) {
                    throw new AccessDeniedException("Access Denied");
                }

                chain.doFilter(request, response);
            } finally {
                request.removeAttribute(alreadyFilteredAttributeName);
            }

        }
    }
    
    /* 생략 */

}

 

이 필터는 유저가 접근하고자 하는 URL에 접근을 제한시킨다. doFilter()를 보면 try문 안에서 AuthorizitionManager의 check()를 통해 요청받은 URL이 공개 URL인지 보안 URL인지 체크하고, 공개 URL이라면 유저에게 자격 증명을 요구하지 않고 응답하겠지만, 보안 URL이라면 유저의 접근을 멈추고 해당 요청을 Spring Security Filter Chain의 다음 Filter로 Redirect 한다. 

 

 

 

1-2. Spring Security Filter ( DefaultLoginPageGeneratingFilter )

 

보안 URL로 접근하려 한다면 그다음으로 만나게 되는 필터는 DefaultLoginPageGeneratingFilter 다.

 

package org.springframework.security.web.authentication.ui;

public class DefaultLoginPageGeneratingFilter extends GenericFilterBean {

  /* 생략 */
  
  private String generateLoginPageHtml(HttpServletRequest request, boolean loginError, boolean logoutSuccess) {
        String errorMsg = "Invalid credentials";
        if (loginError) {
            HttpSession session = request.getSession(false);
            if (session != null) {
                AuthenticationException ex = (AuthenticationException)session.getAttribute("SPRING_SECURITY_LAST_EXCEPTION");
                errorMsg = ex != null ? ex.getMessage() : "Invalid credentials";
            }
        }

        String contextPath = request.getContextPath();
        StringBuilder sb = new StringBuilder();
        sb.append("<!DOCTYPE html>\n");
        sb.append("<html lang=\"en\">\n");
        sb.append("  <head>\n");
        sb.append("    <meta charset=\"utf-8\">\n");
        sb.append("    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1, shrink-to-fit=no\">\n");
        sb.append("    <meta name=\"description\" content=\"\">\n");
        sb.append("    <meta name=\"author\" content=\"\">\n");
        sb.append("    <title>Please sign in</title>\n");
        sb.append("    <link href=\"https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta/css/bootstrap.min.css\" rel=\"stylesheet\" integrity=\"sha384-/Y6pD6FV/Vv2HJnA6t+vslU6fwYXjCFtcEpHbNJ0lyAFsXTsjBbfaDjzALeQsN6M\" crossorigin=\"anonymous\">\n");
        sb.append("    <link href=\"https://getbootstrap.com/docs/4.0/examples/signin/signin.css\" rel=\"stylesheet\" crossorigin=\"anonymous\"/>\n");
        sb.append("  </head>\n");
        sb.append("  <body>\n");
        sb.append("     <div class=\"container\">\n");
        
        /* 생략 */
    }

}

 

우리가 스프링 시큐리티 설정 후 보안 URL에 접속하려고 하면 로그인ID, 비밀번호 입력 페이지를 볼 수 있는데 바로 이 필터가 그 역할을 수행한다. generateLoginPageHtml()를 보면 로그인 페이지를 만드는 html 코드가 작성되어 있는 것을 볼 수 있다.

 

 

 

1-3. Spring Security Filter ( UsernamePasswordAuthenticationFilter )

 

마지막으로 알아볼 필터는 UsernamePasswordAuthenticationFilter이다.

 

package org.springframework.security.web.authentication;

public class UsernamePasswordAuthenticationFilter extends AbstractAuthenticationProcessingFilter {

	/* 생략 */

	@Override
	public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response)
			throws AuthenticationException {
		if (this.postOnly && !request.getMethod().equals("POST")) {
			throw new AuthenticationServiceException("Authentication method not supported: " + request.getMethod());
		}
		String username = obtainUsername(request);
		username = (username != null) ? username.trim() : "";
		String password = obtainPassword(request);
		password = (password != null) ? password : "";
		UsernamePasswordAuthenticationToken authRequest = UsernamePasswordAuthenticationToken.unauthenticated(username,
				password);
		// Allow subclasses to set the "details" property
		setDetails(request, authRequest);
		return this.getAuthenticationManager().authenticate(authRequest);
	}

	/* 생략 */

}

 

attemptAuthentication()를 보면 HttpServletRequest로부터 username과 password를 추출하고, UsernamePasswordAuthenticationToken 객체를 생성한다. UsernamePasswordAuthenticationToken 은 Authentication 인터페이스의 구현체라고 보면 된다. 이 객체는 authenticate()를 호출하여 AuthenticationManager에게 넘기게 된다.

 

 

 

2. AuthenticationManager ( ProviderManager )

 

AuthenticationManager 또한 인터페이스이기 때문에 ProviderManager라는 구현체를 사용한다.

 

package org.springframework.security.authentication;

public class ProviderManager implements AuthenticationManager, MessageSourceAware, InitializingBean {

	/* 생략 */
    
	@Override
	public Authentication authenticate(Authentication authentication) throws AuthenticationException {
		Class<? extends Authentication> toTest = authentication.getClass();
		AuthenticationException lastException = null;
		AuthenticationException parentException = null;
		Authentication result = null;
		Authentication parentResult = null;
		int currentPosition = 0;
		int size = this.providers.size();
		for (AuthenticationProvider provider : getProviders()) {
			if (!provider.supports(toTest)) {
				continue;
			}
			if (logger.isTraceEnabled()) {
				logger.trace(LogMessage.format("Authenticating request with %s (%d/%d)",
						provider.getClass().getSimpleName(), ++currentPosition, size));
			}
			try {
				result = provider.authenticate(authentication);
				if (result != null) {
					copyDetails(authentication, result);
					break;
				}
			}
			catch (AccountStatusException | InternalAuthenticationServiceException ex) {
				prepareException(ex, authentication);
				// SEC-546: Avoid polling additional providers if auth failure is due to
				// invalid account status
				throw ex;
			}
			catch (AuthenticationException ex) {
				lastException = ex;
			}
		}
     
     /* 생략 */
     
    }
    
    /* 생략 */

}

 

 

ProviderManager는 이름 그대로 프레임워크 내에 존재하는 사용 가능한 모든  Authentication Provider 들의 매니저 역할을 한다. authenticate() 내부를 보면 for문으로 모든 AuthenticationProvider를 가져오고, 인증 성공, 실패 여부를 확인한다. 만약 AuthenticationProvider가 두 개 이상 존재하고, 첫 번째 AuthenticationProvider에서 인증이 성공한다면 그 이후의 AuthenticationProvider는 건너뛰게 된다. 반대로 AuthenticationProvider의 인증이 실패했다면 다음 AuthenticationProvider에게 인증 여부를 확인한다.

 

 

 

 

3. AuthenticationProvider ( DaoAuthenticationProvider )

 

이번에는 스프링 시큐리티가 기본적으로 제공하는 AuthenticationProvider를 살펴볼 것이다. 기본 흐름에서 ProviderManager는 DaoAuthenticationProvider라는 AuthenticationProvider 구현체를 호출한다.

 

package org.springframework.security.authentication.dao;

public class DaoAuthenticationProvider extends AbstractUserDetailsAuthenticationProvider {

    /* 생략 */
    
    @Override
    protected final UserDetails retrieveUser(String username, UsernamePasswordAuthenticationToken authentication)
            throws AuthenticationException {
        prepareTimingAttackProtection();
        try {
            UserDetails loadedUser = this.getUserDetailsService().loadUserByUsername(username);
            if (loadedUser == null) {
                throw new InternalAuthenticationServiceException(
                        "UserDetailsService returned null, which is an interface contract violation");
            }
            return loadedUser;
        }
        catch (UsernameNotFoundException ex) {
            mitigateAgainstTimingAttack(authentication);
            throw ex;
        }
        catch (InternalAuthenticationServiceException ex) {
            throw ex;
        }
        catch (Exception ex) {
            throw new InternalAuthenticationServiceException(ex.getMessage(), ex);
        }
    }

    /* 생략 */

}

 

 

먼저 DaoAuthenticationProvider 클래스가 상속받고 있는 AbstractUserDetailsAuthenticationProvider 클래스를 확인해 보자.

 

package org.springframework.security.authentication.dao;

public abstract class AbstractUserDetailsAuthenticationProvider
		implements AuthenticationProvider, InitializingBean, MessageSourceAware {
        
    /* 생략 */    
    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        Assert.isInstanceOf(UsernamePasswordAuthenticationToken.class, authentication,
                () -> this.messages.getMessage("AbstractUserDetailsAuthenticationProvider.onlySupports",
                        "Only UsernamePasswordAuthenticationToken is supported"));
        String username = determineUsername(authentication);
        boolean cacheWasUsed = true;
        UserDetails user = this.userCache.getUserFromCache(username);
        if (user == null) {
            cacheWasUsed = false;
            try {
                user = retrieveUser(username, (UsernamePasswordAuthenticationToken) authentication);
            }
            catch (UsernameNotFoundException ex) {
                this.logger.debug("Failed to find user '" + username + "'");
                if (!this.hideUserNotFoundExceptions) {
                    throw ex;
                }
                throw new BadCredentialsException(this.messages
                    .getMessage("AbstractUserDetailsAuthenticationProvider.badCredentials", "Bad credentials"));
            }
            Assert.notNull(user, "retrieveUser returned null - a violation of the interface contract");
        }
        try {
            this.preAuthenticationChecks.check(user);
            additionalAuthenticationChecks(user, (UsernamePasswordAuthenticationToken) authentication);
        }
        catch (AuthenticationException ex) {
            if (!cacheWasUsed) {
                throw ex;
            }
            // There was a problem, so try again after checking
            // we're using latest data (i.e. not from the cache)
            cacheWasUsed = false;
            user = retrieveUser(username, (UsernamePasswordAuthenticationToken) authentication);
            this.preAuthenticationChecks.check(user);
            additionalAuthenticationChecks(user, (UsernamePasswordAuthenticationToken) authentication);
        }
        this.postAuthenticationChecks.check(user);
        if (!cacheWasUsed) {
            this.userCache.putUserInCache(user);
        }
        Object principalToReturn = user;
        if (this.forcePrincipalAsString) {
            principalToReturn = user.getUsername();
        }
        return createSuccessAuthentication(principalToReturn, authentication, user);
    }
    /* 생략 */        
}

 

AbstractUserDetailsAuthenticationProvider 클래스의 authenticate()로 실제 인증 로직이 구현되고 있는 것을 확인할 수 있다.

먼저 username을 불러온 후 구현 클래스(DaoAuthenticationProvider)에 정의되어 있는 retriveUser()를 호출하는데, 여기서 retriveUser()를 자세히 살펴보면, 스프링 시큐리티에서 제공하는 UserDetailService의 도움을 받는 것을 확인할 수 있다. UserDetailService도 인터페이스이기 때문에 기본 로직에서는 이에 대한 구현체로 InMemoryUserDetailsManager를 사용한다.

 

package org.springframework.security.provisioning;

public class InMemoryUserDetailsManager implements UserDetailsManager, UserDetailsPasswordService {

	/* 생략 */
	@Override
	public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
		UserDetails user = this.users.get(username.toLowerCase());
		if (user == null) {
			throw new UsernameNotFoundException(username);
		}
		return new User(user.getUsername(), user.getPassword(), user.isEnabled(), user.isAccountNonExpired(),
				user.isCredentialsNonExpired(), user.isAccountNonLocked(), user.getAuthorities());
	}
    
	/* 생략 */

}

 

코드를 보면 알 수 있듯이 InMemoryUserDetailsManager 클래스는 UserDetailsManager 인터페이스를 상속받고 있고, loadUserByUsername()를 통해 인메모리에 저장되어 있는 유저 정보를 반환한다.

DaoAuthenticationProvider를 통해 인증이 성공적으로 수행되었다면 이 응답은 ProviderManager에 전달되고, 유저는 이제 보안 URL에 접근할 수 있게 된다.

 

여기까지가 코드로 살펴본 스프링 시큐리티의 기본 흐름이다.

 

 

 

마치며

Spring Secutiry의 내부 흐름과 기본으로 제공하는 Filter, AuthenticationManager,  AuthenticationProvider 클래스를 통해 어떤 식으로 유저 정보를 받아 인증 객체로 저장되는지 알아보았다. 다음 글에서는 Spring Security와 JWT, OAuth2를 토이프로젝트에 적용했던 경험에 대해 작성해 보겠다.