Skip to main content Link Menu Expand (external link) Document Search Copy Copied

created at 2023-03-29

인증/권한 설정

제가 구현하고자 하는 부분을 인증/권한부여 파트만 간단하게 도식화해서 나타낸다면 아래의 그림과 같을거에요.

img

여기의 문제점은 micro service가 늘어날 수록, 세션에 대한 부담이 늘어난다는 것입니다. 그래서 redis 캐시 db로 RDS로 가는 부담을 줄이고자 하였지만 서비스가 추가됨에 따라 redis 또한 버티기 어려울 것으로 예상되요.

그래서! 애초에 부담을 전체 서버로 돌리고자 JWT 토큰을 사용할 것입니다. 그렇게 된다면 아래와 같이 플로우가 바뀌겠죠?

img

더 간단하게 나타내면 다음과 같겠죠?

img

상세한 로직은 아래와 같습니다.

  1. Spring-Cloud-Gateway에서 구동 이전 configuration 을 AWS-Secret의 JWT-secret 에서 읽어와 세팅합니다.
  2. 게이트웨이에서 최우선순위 인증 필터를 적용하여 토큰인증이 실패한다면, /login 으로 redirecting 합니다.
...
    try {
        redirectURI = buildURI(requestRoute);
    } catch (URISyntaxException e) {
        e.printStackTrace();
    }
    
    // JWT TOKEN Verification //
    ...
        
    // JWT 인증 실패 시, Redirecting to AUTH service GET /login
    ServerHttpRequest modifiedRequest = exchange
            .getRequest()
            .mutate()
            .uri(redirectURI) // 리다이랙트
            .build();
    
    ServerWebExchange modifiedExchange = exchange
            .mutate()
            .request(modifiedRequest)
            .build();
    
    // JWT 토큰 정상일 떄,
    exchange.getAttributes().put(GATEWAY_REQUEST_URL_ATTR, redirectURI);
    
    return chain.filter(modifiedExchange);

즉, 계속해서 Auth 서비스에 매번 인증을 요구하는 것이 아니라 AWS-secret 에 저장해둔 공유 secret 키로 JWT 토큰을 발행해서 모든 Micro Service 마다 공통된 시그니처 확인 로직을 가지고 인증을 수행할 수 있도록 하였습니다. 인증의 부하를 분산시킨 것이죠. 물론 세션 관리의 장점을 포기하긴 했지만, 정말 동시사용자가 많은 경우를 고려하여 JWT 토큰을 사용하였습니다.