Spring Security - 인증/인가와 FilterChain (w. JWT, Authorization)

인증/인가와 Spring Security의 SecurityFilterChain과 대해 알아봅니다.

GOAL

• 인증, 인가에 대해 명확하게 이해한다.
• Spring Security의 FilterChain의 작동 방식에 대해 이해한다.
• Bearer와 Basic 인증의 차이를 이해한다.

인증 / 인가

먼저 간단하게 인증과 인가에 대해서 정리해보자.

 

인증(AuthN)

사용자의 정체를 묻는 것으로 리소스에 접근하려는 사용자가 정말 그 사람인지를 물어보는 것이다. 사용되는 방식으로는 아이디/비밀번호, OTP, 인증서, 소셜 로그인 토큰 등이 있다. 보통 인증 요청이 실패한다면 401 Unauthorized 예외로 처리하게 된다. (재인증 필요)

 

인가(AuthZ)

사용자의 권한을 검증하는 것으로 인증을 마친 사용자가 정말 이 행동을 해도 되는가를 물어보는 것이다. 사용되는 방식으로는 역할, 권한, 소유자 여부 등이 있다. 보통 인가 요청이 실패한다면 403 Forbidden 예외로 처리하게 된다. (인증은 됐지만 권한이 부족함)

 

일반적인 애플리케이션에서의 흐름은 다음과 같다.

1. 로그인 성공 -> 서버가 세션이나 토큰에 신원 정보를 담아 발급

2. 클라이언트는 매 요청마다 세션/토큰이 유효한지 확인하여 인증하고, 엔드포인트/리소스에 대한 역할, 권한, 소유권 등을 검사하며 인가한다.

 

인가는 인증된 사용자한테만 판단할 수 있다. 위에서 설명한 것처럼 "사용자가 이 리소스를 사용할 자격이 있는가?"를 판단하는 행위이기 때문에 사용자가 누구인지 알 수 있어야 권한을 판단할 수 있다. 즉, 인증(Authentication)이 선행되지 않으면 인가의 대상이 없게 된다.

 

 

Spring Security에서의 인증 / 인가

그렇다면 Spring에서 자주 사용되는 Spring Security에서는 어떻게 인증 / 인가를 처리할까? Spring Security에서는 모든 요청을 보안 필터 체인(SecurityFilterChain) 안으로 집어넣고, 규칙에 따라 인가 여부를 판단한다.

 

SecurityFilterChain이란?

보안 필터 체인은 위에서 언급한 것처럼 요청이 들어올 때 인증과 인가를 처리하는 핵심 매커니즘이다. 기본적인 컨셉은 HTTP 요청이 들어올 때, Spring Security가 등록해 둔 여러 보안 필터들을 순서대로 실행하는 것이다. Spring은 서블릿 위에서 동작하기 때문에, 서블릿 기본 필터 체인이 존재한다. Spring Security는 서블릿 필터 체인 위에 추가적으로 보안 필터 체인을 올려서 실행한다.

 

상세하게 흐름을 살펴보자면 다음과 같다.

1. Client의 HTTP 요청

2. Tomcat이 요청을 받아 Filter Chain을 돌림

3. 모든 체인을 실행 후 DispatcherServlet로 전달

-> DispatchServlet이 필터 체인의 마지막 서블릿이라고 생각할 수 있다.

 

Spring Security에서 JWT 사용하기

보통 Spring Security를 사용했던 사람들이라면 JWT 커스텀 필터를 만드는 경우, .addFilterBefore({커스텀 필터}, UsernamePasswordAuthenticationFilter.class) 이런 식으로 적용했을 것이다. addFilterBefore 메서드는 두 번째 인자로 받은 필터 클래스 이전에 첫 번째 인자의 필터를 실행하겠다는 메서드이다. 해당 필터는 로그인 시 입력값을 처리하는 구간에 위치한다. 따라서 해당 필터 이전에 위치하겠다는 의미는 "JWT로 먼저 인증해보고 Authentication이 없으면, 그때 폼 로그인으로 인증 시도"라는 의미가 된다. 대부분 JWT를 사용하는 경우 formLogin을 사용하지 않아서 해당 필터는 의미없는데, 그럼에도 대부분 해당 필터 이전에 배치하는 이유는 필터 체인 전체 순서에서도 인증 시점 근처에 배치하여 인증 단계 직전에 JWT를 인증한다라는 의도를 코드에서 드러나도록 하는 것이다.

 

* 빈으로 등록하면 자동 실행 아닌가요?

• @Component(혹은 @Bean 타입이 Filter)로 등록하면 스프링 부트가 전역 서블릿 필터로 자동 등록하여 시큐리티 체인 밖에서 따로 돌게 된다.
• 인증 필터는 반드시 시큐리티 체인 안에서 정해진 지점에 끼워 넣어야 의도한 순서로 동작하기 때문에 HttpSecurity.addFilterBefore(...)로 시큐리티 체인에 명시적으로 추가

 

 

Authorization - Bearer과 Basic

위에서 인증과 인가, Spring Security에 대해 알아보았다. 지난 번에 JWT에 대해 알아보았는데, JWT를 사용할 때는 보통 헤더의 Authorization 필드에 Bearer 필드와 함께 JWT를 보냈을 것이다. 그럼 Bearer란 무엇일까? 왜 Bearer를 사용할까?

 

Authorization 헤더에 들어가는 인증 방식에는 두 가지가 있다.

1. Bearer (RFC 6750)

Bearer 인증 방식은 OAuth 2.0 프레임워크에서 사용하는 토큰 인증 방식으로, “Bearer”은 소유자라는 뜻인데, “이 토큰의 소유자에게 권한을 부여해줘”라는 의미라고 한다. 필드에 들어가는 값은 무작위 난수 문자열(opaque token)이거나 JWT 같은 서명된 토큰이다. 토큰이 곧 권한 증표이고, 누가 들고 있든 그 토큰만 있으면 그 사용자로 인정해 준다는 개념이다.

아이디/비밀번호는 로그인 시에만 한 번 서버로 보내고 이후에는 토큰만 주고받아 아이디와 비밀번호 유출에 대한 걱정이 덜하다는 장점이 있다. 또한 토큰에 만료 시간(exp), 권한(scope/roles), 유저 식별자(sub) 등을 담아둘 수 있어서 세밀한 인가, 만료 정책을 조정가능하다.

 

2. Basic (RFC 7617)

이름처럼 기본적인 인증 방식으로 인증 정보로 사용자 ID, 비밀번호를 사용한다. {사용자 ID}:{비밀번호} 문자열을 만든 다음 Base64로 인코딩한 값을 Authorization 헤더에 넣는 방식이다.

 

Basic 인증 방식의 가장 큰 장점은 간단함이다. 사용자 ID와 비밀번호 외에 로그인 페이지나 별도의 인증 정보를 요구하지 않기 때문에 단순하고 구축하기 쉽다는 장점이 있다.

하지만 Basic 인증 방식은 아이디 비밀번호가 Base64만 적용되고 그대로 전송되기 때문에 굉장히 위험하다. 또한 Basic 인증 방식만으로는 사용자 권한을 정교하게 제어할 수 없다. 사용자가 꼭 필요한 리소스에만 권한을 주는 게 좋은데, Basic 인증 방식으로 세세하게 사용자의 권한을 설정하려면 추가 구현이 필요하게 된다.

 

참고

https://spring.io/projects/spring-security

Spring Security

 

https://docs.tosspayments.com/blog/everything-about-basic-bearer-auth

Basic 인증과 Bearer 인증의 모든 것 | 토스페이먼츠 개발자센터