Token 방식으로 인증 인가를 처리하려고 하는데, 그 처리를 모든 MicroService가 자체적으로 하기에는 각자 다른 DB를 사용할 예정이라 한계가 있고, 공통된 코드가 많이 발생해 비효율적임. 그래서 API Gateway에서 인증/인가를 공통적으로 처리를 하고 라우팅을 할 생각인데 API Gateway에서 이를 처리하기 위한 방법으로 크게 두가지가 존재함.
API Gateway에서의 인증 인가 처리..
방법1
인증이 필요한 요청을 API Gateway -> 인증 서비스(유저 서비스)로 인증 요청 및 응답 처리 -> 해당 요청에 알맞는 마이크로서비스 로 처리하는 방법이다. 해당 방법을 활용하면 역할 및 책임이 확실하게 나누어져(API Gateway는 요청 라우팅 및 로드밸런서 역할, 인증서비스는 인증 역할) API Gateway와 인증 서비스 각각 역할에 맞는 알맞는 기술과 그 책임을 강화할 수 있게 된다. 하지만 두번의 네트워크 통신을 거쳐야하고, 인증서비스의 부하가 올 수 있다고 생각한다.
방법2
API Gateway에서 직접 인증, 인가 처리를 하는 방법이다. 따라서 인증이 필요한 요청은 앞의 방법과 다르게 API Gateway -> 해당 요청에 알맞는 마이크로서비스가 된다. API Gateway에 과도한 책임이 주어지는 단점이 있지만, 네트워크를 한번만 타게 되고, 인증 서비스를 두어도 되지 않아도된다. (리소스가 적다)
결정
해당 개인 레포는 특별한 보안 없이 단순히 jwt Token의 유효성만 검사하면 되기 때문에 API Gateway에서 직접 인증/인가 처리를 하도록 할 예정이다. (인증 서비스를 굳이 따로 둬서 개발 리소르를 늘릴 필요가 없다고 생각함)
방법
토큰에 대한 검증을 하기 위해서는 DB 접근이 필요한데 API Gateway는 Spring Cloud Gateway(Webflux기반)를 활용하기 때문에 Reactive DB Driver가 필요하다. 이를 위해서 User에 대한 DB는 MongoDB를 활용할 것이다. ( 문서 많음, 자체 Reactive Driver 제공)
개요
Token 방식으로 인증 인가를 처리하려고 하는데, 그 처리를 모든 MicroService가 자체적으로 하기에는 각자 다른 DB를 사용할 예정이라 한계가 있고, 공통된 코드가 많이 발생해 비효율적임. 그래서 API Gateway에서 인증/인가를 공통적으로 처리를 하고 라우팅을 할 생각인데 API Gateway에서 이를 처리하기 위한 방법으로 크게 두가지가 존재함.
API Gateway에서의 인증 인가 처리..
방법1 인증이 필요한 요청을 API Gateway -> 인증 서비스(유저 서비스)로 인증 요청 및 응답 처리 -> 해당 요청에 알맞는 마이크로서비스 로 처리하는 방법이다. 해당 방법을 활용하면 역할 및 책임이 확실하게 나누어져(API Gateway는 요청 라우팅 및 로드밸런서 역할, 인증서비스는 인증 역할) API Gateway와 인증 서비스 각각 역할에 맞는 알맞는 기술과 그 책임을 강화할 수 있게 된다. 하지만 두번의 네트워크 통신을 거쳐야하고, 인증서비스의 부하가 올 수 있다고 생각한다.
방법2 API Gateway에서 직접 인증, 인가 처리를 하는 방법이다. 따라서 인증이 필요한 요청은 앞의 방법과 다르게 API Gateway -> 해당 요청에 알맞는 마이크로서비스가 된다. API Gateway에 과도한 책임이 주어지는 단점이 있지만, 네트워크를 한번만 타게 되고, 인증 서비스를 두어도 되지 않아도된다. (리소스가 적다)
결정
해당 개인 레포는 특별한 보안 없이 단순히 jwt Token의 유효성만 검사하면 되기 때문에 API Gateway에서 직접 인증/인가 처리를 하도록 할 예정이다. (인증 서비스를 굳이 따로 둬서 개발 리소르를 늘릴 필요가 없다고 생각함)
방법