[Spring Security] Spring Security 맛보기

보안의 필요성

보안은 웹 애플리케이션을 구축할 때 정말 중요한 요소이다. 웹 애플리케이션이 어떤 기능을 제공하냐에 따라 비즈니스 로직을 작성하는 것 이상으로 중요할 수도 있다. 높은 수준의 보안을 유지하기 위해서는 애플리케이션 뿐 아니라 인프라 수준의 보안을 유지하는 것이 필수적이다. 그러나 각 계층에는 각각의 책임이 존재하기 때문에 애플리케이션은 애플리케이션 수준에서 최선의 보안을 제공해야 한다. 인프라의 보안도 마찬가지이다.

 

애플리케이션의 보안을 철두철미하게 보장한다는 것은 상당히 어려운 일이다. 애플리케이션에게 가할 수 있는 공격은 매우 많으며 시간이 지날수록 새로운 공격법도 창발하기 마련이다. 애플리케이션의 로직을 구현하는데 전념해야할 개발자가 이러한 곳에 신경을 쓴다는 것은 상당한 리소스 낭비이다. 오픈소스 보안 프레임워크는 그런 관점에서 매우 훌륭한 선택이다. 보안 전문가들의 기여로 인해 구축된 보안 프레임워크는 꾸준히 업데이트 되고, 개인이 작성하는 것보다 치밀한 방어가 가능하기 때문이다.

 

스프링 생태계에는 Spring Security라는 훌륭한 프레임워크가 있다. Spring Security는 웹 애플리케이션에 필요한 다양한 인증과 인가를 지원하고 그 외에 웹 애플리케이션 보안에 중요한 CSRF 공격 등을 방어할 솔루션도 제공한다. 이것들을 웹 애플리케이션을 개발할 때마다 구현한다는 것은 매우 비효율적이기 때문에 프레임워크를 배우는 것이 낫다고 판단해 Spring Security를 개인적으로 공부 중이고, 그런 Spring Security로 웹 애플리케이션을 구축하며 이해한 프레임워크 구조와 코드를 공유하려한다.

 

Head First! Spring Security

 

그냥 무작정 Spring Security를 프로젝트에 적용해보자. (이번 포스팅에서는 "인증이 필요한 API와 필요하지 않은 API를 구분"하는 실습을 해보겠다)

Spring Security를 기존 프로젝트에 그대로 적용하게 되면 많은 부분이 한번에 바뀌어 혼란스러울 수 있다. 따라서 새로운 프로젝트에 Spring Security를 추가하는 것을 추천한다. 나는 Spring Web과 Spring Security를 추가한 프로젝트에서 진행했고, 추후 이 프로젝트에 Spring Data JPA 등을 추가해 데이터베이스를 연동해 사용자 기반 인증과 인가를 구현하려고 한다.

 

Spring initializr나 Intellij IDE에서 Spring Web, Spring Security를 의존성에 추가하고 프로젝트를 빌드하자.

dependencies {
  implementation 'org.springframework.boot:spring-boot-starter-security'
  implementation 'org.springframework.boot:spring-boot-starter-web'
  testImplementation 'org.springframework.boot:spring-boot-starter-test'
  testImplementation 'org.springframework.security:spring-security-test'
  testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

 

프로젝트 구축이 완료되었으면 다음과 같은 컨트롤러 코드를 작성하자.

@RestController
public class SecurityController {

    @GetMapping("/authorized")
    public ResponseEntity<?> authorizedRequest() {
        return ResponseEntity.ok().body("Hello authorized user.");
    }

    @GetMapping("/unauthorized")
    public ResponseEntity<?> unauthorizedRequest() {
        return ResponseEntity.ok().body("Hello anonymous user.");
    }
}

 

 

웹 애플리케이션을 구축할 때, 특정 API는 인증(로그인)이 필요한 API가 일수도 있고 어떤 API는 인증이 필요없는 API일 수 있다. 가령 예를 들어, 특정 웹 애플리케이션의 공지사항을 불러오는 API는 모든 사용자에게 오픈하고, 개인 정보가 포함된 API는 인증된 사용자에게만 제공할 수 있다.

 

위 예제에서는 "/authorized"로 요청되는 API는 인증이 필요한 API이고, "/unauthorized"로 요청되는 API는 인증이 필요없는 API로 구축되기를 희망한다.

 

이제, 포스트맨으로 위 URL로 HTTP API를 요청하게 되면 두 API 모두 401 에러를 내보내게 된다.

※ 401 에러 코드는 요청된 리소스에 대한 유효한 인증 자격 증명이 없기 때문에 반환되는 에러 코드다. (링크)

 

별도의 설정을 하지 않았는데 모든 API가 인증이 필요한 API로 설정되어있다. 그 이유는 다음 코드를 보며 이해해보자.

 

SecurityFilterChain

SpringBootWebSecurityConfiguration 이라는 클래스 내부에 선언된 필터 체인을 반환하는 메서드 코드이다.

(참고로, Intellij IDE를 사용중이라면 쉬프트를 2번 눌러 클래스 파일을 검색할 수 있다)

 

@Bean
@Order(SecurityProperties.BASIC_AUTH_ORDER)
SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests((requests) -> requests.anyRequest().authenticated()); // -- 1
    http.formLogin(withDefaults()); // -- 2
    http.httpBasic(withDefaults()); // -- 3
    return http.build(); // -- 4
}

 

 

각 코드를 해석하자면 다음과 같다.

Line #1: 모든 HTTP 요청에 대해 authenticated 되어야한다.

Line #2: Form 요청에 대해서도 인증 과정이 수행된다.

Line #3: HTTP basic 인증 방식으로도 인증한다.

Line #4: 최종적으로 http 변수를 빌드하여 SecurityFilterChain 객체를 생성하고 빈으로 등록한다.

 

그리고 이 메서드에 달린 주석은 다음과 같은데 해석하면 다음과 같다.

 

Web Security를 위한 기본 설정 값. 만약 SecurityFilterChain 객체를 구현하고 빈으로 등록하면 이 Bean은 완전히 무효되고 사용자(개발자)가 원하는대로 동작하도록 할 수 있다.

 

기본 FilterChain이 모든 HTTP 요청에 대해 인증이 필요하도록 설정해두었기 때문에 위와 같이 401 에러가 발생한 것이다. 새롭게 SecurityFilterChain을 선언해 우리가 원하는대로 동작하도록 바꾸어보자!

 

사용자 정의 SecurityFilterChain

우선, 별도의 클래스를 선언하고 클래스 레벨에 @Configuration 어노테이션을 명시해 내부 메서드들이 모두 Bean으로 등록되게 하자.

@Configuration
public class ProjectSecurityConfig {

    /*
      @Configuration을 선언함으로써, 이 클래스 내부의 모든 Bean이 스캔되고 등록된다.
     */

}

 

이제, 다음과 같이 작성해 "/authorized" URL로 들어오는 API는 인증이 필요하도록, "unauthorized" URL로 들어오는 API는 인증이 필요하지 않도록 설정해보자.

 

@Bean
SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests((requests) -> requests 
            .requestMatchers("/authorized").authenticated() // -- 1
            .requestMatchers("/unauthorized").permitAll()); // -- 2
    http.formLogin(withDefaults());
    http.httpBasic(withDefaults());
    return http.build();
}

 

1. "/authorized" URL에 대한 API 요청은 모두 인증이 필요하도록 설정한다.
2. "/unauthorized" URL에 대한 API 요청은 인증이 필요없도록 허용한다.

필터 체인에 대한 구조는 여기 링크에서 확인할 수 있다. (스프링에 대한 내공이 아직 부족해 해당 내용을 완전히 이해하진 못했는데 앞으로 해나갈 예정이다)

 

이렇게 설정을 해두고 빌드를 한 뒤 API 요청을 날려보면... 의도한 대로 동작하는 것을 확인할 수 있다!

 

만약 원하는대로 동작하지 않는다면?

• @Configuration을 적용한 클래스 파일의 위치를 확인해보자. 컴포넌트 스캔의 대상이 되는 위치에 있는가?
• SecurityFilterChain 내에서 requests.requestMatchers() 의 파라미터로 전달한 URL이 정확히 기입되었는지 확인하자.