MSA 환경에서 인증, 인가는 어디서 처리하는 게 옳을까?

1. 개요

MSA를 도입하면서, 혹은 고려하면서 대부분의 사람들이 인증 인가에 대한 고민을 하게 될거라 생각한다.

 

 

나도 Spring Cloud를 사용한 MSA 아키텍처 구조로 개발을 진행하면서 인증, 인가에 대한 고민을 하게 됐다. 구글링 해보면 크게 2가지 방법으로 나뉘었다. 

 

1. Gateway에서 모든 인증, 인가 처리

 

2. 각 Micro Service 에서 인증, 인가 처리

 

 

 

 

이 두 가지 방법 중 어떤걸 선택해야 할 지에 대해 많은 고민을 했다. 결론부터 얘기하면 현재는 Gateway에서 인증 처리, 각 Micro Service에서 인가 처리를 하는 것으로 결정했다.

 

하지만, 서비스를 운영해본게 아니고 학습하는 단계이기 때문에 내 생각이 틀릴 수도 있다. 그리고 각자 개발하는 서비스의 도메인, 성격, 트래픽 등 많고 다양한 요인들에 따라 결정은 달라질 것이다. 그럼에도 불구하고 만약 어떤 이유 때문에 내 생각이 틀렸다 생각이 들면 다시 돌아와서 글을 이어서 작성할 예정이다. 

 

 

 

 

 

 

 

 

 

 

 

2. Gateway에서 인증, 인가 처리

spring security 와 같은 라이브러리와 마찬가지로, spring api gateway도 필터가 많이 활용된다. 여러 필터들을 선언 해두면, 해당 필터들을 거쳐서 실제 서비스로 라우팅이 된다.

 

여러 Filter들을 구현하고 Bean으로 등록만 해주면 동작할 수 있는데 순서 또한 조정할 수 있다. 

 

필터가 호출되는 방식은 일반적인 다른 필터와 마찬가지이다. 만약 순서를 지정하지 않으면 마음대로 동작하게 된다. 

 

 

 

Spring Cloud에서는 이런 Filter들을 구현하기 위해 AbstractGatewayFilterFactory 라는 추상 클래스를 제공해준다. 이 클래스를 상속 받아 overriding을 통해 JwtFilter를 구현할 수 있다. 

 

 

 

Gateway에서 인증 처리

@Slf4j
@Component
public class JwtAuthenticationFilter extends AbstractGatewayFilterFactory<JwtAuthenticationFilter.Config> {

    private final JwtTokenProvider jwtProvider;

    public JwtAuthenticationFilter(JwtTokenProvider jwtProvider) {
        super(Config.class);
        this.jwtProvider = jwtProvider;
    }

    @Override
    public GatewayFilter apply(Config config) {
        return (exchange, chain) -> {
            String authorizationHeader = exchange.getRequest().getHeaders().getFirst(HttpHeaders.AUTHORIZATION);
            if (authorizationHeader != null && authorizationHeader.startsWith("Bearer ")) {
                String token = authorizationHeader.substring(7);

                // 만료 체크 & 토큰 검증
                if (jwtProvider.isExpiration(token)) {
                    log.info("access token 만료");
                    throw new DelegationTokenExpiredException("토큰 만료");
                }

                String loginId = jwtProvider.getLoginId(token);
                String role = jwtProvider.getRoles(token);

                // 사용자 정보를 헤더에 추가
                ServerHttpRequest modifiedRequest = exchange.getRequest().mutate()
                        .header("X-User-Id", loginId)
                        .header("X-User-Roles", role)
                        .build();

                // 새 요청을 포함한 Exchange 생성
                exchange = exchange.mutate().request(modifiedRequest).build();
            }
            return chain.filter(exchange);
        };
    }

    public static class Config {
    }
}

 

기존 모놀로식 아키텍처에서 JWT를 사용할 때 OncePerRequestFilter를 상속받아 구현한 JwtFilter와 굉장히 유사하다. 

 

헤더에 토큰이 있다면 검증하고, 다음 필터를 실행한다. 나는 다른 micro service에서 현재 로그인한 사용자를 얻기 위해 header에 값을 추가로 담아줬다. 

 

이렇게 설정한 Filter는 application.yml 에서 적용시킬 수 있다. 

 

 

 

- api gateway 의 application.yml

spring:
  application:
    name: apigateway
  cloud:
    gateway:
      routes:
        - id: todo-app
          uri: lb://TODO-APP
          predicates:
            - Path=/todo-app/**

        - id: temp-server
          uri: lb://TEMP-SERVER
          predicates:
            - Path=/temp-server/**

        - id: member-server
          uri: lb://MEMBER-SERVER
          predicates:
            - Path=/member-server/**

      default-filters:
        - JwtAuthenticationFilter # 모든 라우트에서 기본적으로 적용

 

 

 

 

Gateway에서 인가 처리

@Slf4j
@Component
public class JwtAuthenticationFilter extends AbstractGatewayFilterFactory<JwtAuthenticationFilter.Config> {

    private final JwtTokenProvider jwtProvider;

    public JwtAuthenticationFilter(JwtTokenProvider jwtProvider) {
        super(Config.class);
        this.jwtProvider = jwtProvider;
    }

    @Override
    public GatewayFilter apply(Config config) {
        return (exchange, chain) -> {
            String authorizationHeader = exchange.getRequest().getHeaders().getFirst(HttpHeaders.AUTHORIZATION);
            if (authorizationHeader != null && authorizationHeader.startsWith("Bearer ")) {
                String token = authorizationHeader.substring(7);

                // 만료 체크
                if (jwtProvider.isExpiration(token)) {
                    log.info("access token 만료");
                    throw new DelegationTokenExpiredException("토큰 만료");
                }

                // 토큰 검증
                String loginId = jwtProvider.getLoginId(token);
                String role = jwtProvider.getRoles(token);

				/* 추가 */
                // 권한 체크
                if (config.getRequiredRole() != null && !role.contains(config.getRequiredRole())) {
                    log.info("권한 부족: 필요한 역할 = {}, 사용자의 역할 = {}", config.getRequiredRole(), role);
                    throw new ResponseStatusException(HttpStatus.FORBIDDEN, "해당 리소스에 접근 권한이 없습니다.");
                }

                // 사용자 정보를 헤더에 추가
                ServerHttpRequest modifiedRequest = exchange.getRequest().mutate()
                        .header("X-User-Id", loginId)
                        .header("X-User-Roles", role)
                        .build();

                // 새 요청을 포함한 Exchange 생성
                exchange = exchange.mutate().request(modifiedRequest).build();
            }
            return chain.filter(exchange);
        };
    }

	/* 추가 */
    @Data
    public static class Config {
//         필터 구성에 필요한 설정 정보를 추가
        private String requiredRole;
    }
}

 

 

spring:
  cloud:
    gateway:
      routes:
        - id: todo-app
          uri: lb://TODO-APP
          predicates:
            - Path=/todo-app/**
          filters:
            - name: JwtAuthenticationFilter
              args:
                requiredRole: MEMBER

        - id: temp-server
          uri: lb://TEMP-SERVER
          predicates:
            - Path=/temp-server/**
          filters:
            - name: JwtAuthenticationFilter
              args:
                requiredRole: ADMIN

        - id: member-server
          uri: lb://MEMBER-SERVER
          predicates:
            - Path=/member-server/**
          filters:
            - name: JwtAuthenticationFilter
              args:
                requiredRole: MEMBER

 

Config 클래스에서 필터에 필요한 설정 정보를 받을 수 있다. application yml로 부터 어떤 권한이 필요한지 requiredRole 정보를 받고 토큰의 권한 정보와 비교하여 권한 처리를 해주었다. 

 

 

 

 

 

 

 

 

 

 

 

 

 

3. 각 Micro Service에서 인증, 인가 처리

난 Multi Module을 사용하고 있었기 때문에 공통 모듈을 만들어 각 Micro Service에 적용될 Security 설정을 해주었다.

 

 

Common 모듈에서 Security 관련 설정

Security Context에 유저 정보를 넣어줘야 하기 때문에 jwtFilter만 필터로 등록시켜주었다. 

 

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
@EnableMethodSecurity(prePostEnabled = true)
public class SecurityConfig {

    private final JwtFilter jwtFilter;

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
                .csrf(AbstractHttpConfigurer::disable)
                .headers(headers -> headers.frameOptions(HeadersConfigurer.FrameOptionsConfig::disable))
                .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
                .authorizeHttpRequests(authorize -> authorize
                        .requestMatchers("/v3/api-docs/**", "/swagger-ui/**", "/swagger-resources/**").permitAll()
                        .anyRequest().permitAll()
                )
                .addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class);

        return http.build();
    }
}

 

 

@Slf4j
@Component
@RequiredArgsConstructor
public class JwtFilter extends OncePerRequestFilter {

    private final JwtTokenProvider jwtProvider;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
        throws ServletException, IOException {
        try {
            String authorizationHeader = request.getHeader("Authorization");
            String token;
            // 헤더가 null 이 아니고 올바른 토큰이라면
            if (authorizationHeader != null && authorizationHeader.startsWith("Bearer ")) {
                // 토큰 추출
                token = authorizationHeader.substring(7);
                // 만료 체크
                if (jwtProvider.isExpiration(token)) {
                    log.info("access token 만료");
                    throw new DelegationTokenExpiredException("token 만료");
                }

                String loginId = jwtProvider.getLoginId(token);
                Role role = jwtProvider.getRoles(token);

                PrincipalDetails principalDetails = new PrincipalDetails(new MemberDto(loginId, role));

                // 인증 정보 생성
                Authentication authentication = new UsernamePasswordAuthenticationToken(principalDetails, null,
                        principalDetails.getAuthorities());

                // SecurityContextHolder에 인증 정보 설정
                SecurityContextHolder.getContext().setAuthentication(authentication);
            }

            filterChain.doFilter(request, response);
        } catch (Exception e) {
            // response 세팅
            response.setCharacterEncoding("UTF-8");
            response.setContentType("application/json;charset=UTF-8"); // JSON 응답을 UTF-8로 설정
            response.setContentType(APPLICATION_JSON_VALUE);

            response.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
            response.getWriter()
                    .write(e.getMessage());
        }
    }
}

 

 

권한 설정은 어노테이션으로 할 생각이기 때문에 Security Config엔 따로 넣지 않았다. 

 

어노테이션 권한 설정은 여기를 참고

 

 

 

 

인증, 인가가 필요한 모듈에서 Common 모듈 의존성 설정

dependencies {
    implementation project(':common')
}

 

 

 

 

 

 

 

 

 

 

 

4. 각 방법의 장단점

Gateway

• 장점
  • 각 마이크로 서비스에서 인증, 인가 로직이 빠져나가므로, 서비스는 비즈니스 로직에 집중할 수 있다.
  • 각 요청을 Gateway에서 인증하고 나면 이후 마이크로서비스 간의 요청에는 별도의 인증 검증이 필요하지 않으므로 성능이 향상될 수 있다. 
  • 모든 트래픽에 대해 일관된 보안 정책을 적용할 수 있다. 
• 단점
  • 단일 장애점 문제가 발생한다. Gateway에 문제가 생기면 모든 인증이 불가능해지고, 반대로 인증에 문제가 생기면 라우팅 기능에 문제가 발생한다. 
  • 모든 서비스의 다양한 인증 요구사항을 Gateway에 반영해야 하므로, Gateway의 로직이 복잡해질 수 있다.
  • Gateway를 통하지 않고 각 서비스간 호출에 대해선 권한 체크를 할 수 없다. 

 

각 Micro Service

• 장점
  • 각 서비스가 독립적으로 인증, 인가를 진행하므로, 개별 서비스의 권한 요구사항에 맞춰 세부적인 인가 정책을 세울 수 있다.
  • 서비스 간 결합도를 줄여 MSA의 장점을 살릴 수 있다.
  • 세부적인 권한 설정이 가능하다.
• 단점
  • 인증, 인가에 필요한 필터를 여러번 타게 된다. 
  • 각 서비스에 따라 보안 정책을 일관되게 가져가지 못할 수도 있다. 
  • 인증, 인가 코드가 중복된다. 

 

 

두 방법의 장단점을 비교해보면 위와 같이 정리할 수 있을 것 같다. 

 

 

 

 

 

 

 

 

 

 

 

 

5. 최종 결론

최종적으로 인증(토큰 검증)은 Gateway에서 하고, 인가(권한 제어)는 각 마이크로 서비스에서 진행하기로 했다. 

 

API Gateway에서 인가를 진행했을 경우 가장 단점이 인가에 대한 설정을 세세하게 할 수 없고 개발을 하는 사람 입장에서 가독성 또한 좋지 못하다 생각이 들었다.

URI 규칙에 따라 권한을 설정하게 되는데 여러 마이크로 서비스의 API들이 적절히 권한 설정이 됐는지 비교하기 위해선 하나하나 비교해봐야 할 것이다. 

 

뿐만 아니라, service -> service의 요청에선 검증이 되지 않으니 보안적으로도 좋지 못하다고 생각이 들었다. 

 

 

물론 각 마이크로 서비스에서 인증, 인가 로직을 수행하면 중복된 코드, 중복 검증으로 오버헤드가 발생하기도 한다. 

 

코드 중복은 공통 모듈을 사용하여 해결하고,

 

중복 검증으로 발생하는 성능 저하는 미미한 수준이라 판단했다. 만약 수십번의 중복 검증으로 성능 저하가 일어난다면 해당 서비스는 설계가 잘못됐을 가능성이 높다고 생각한다.