MSA 패턴에서 마이크로서비스의 인증

일반적으로 모든 마이크로서비스를 위한 인증 및 인가를 API Gateway에게 위임할 때, 인프라 수준에서 망 구분을 하여 외부에서 직접 마이크로서비스에 접근이 불가능하게 합니다. 또한, 각 마이크로서비스에서는 특정 API Gateway에서만 온 요청을 처리하도록 접근 가능한 호스트 IP를 제한하죠. > 많은 레퍼런스와 자료들을 찾아보니 인증과 인가 로직은 게이트웨이에서 대신 처리하고 뒷단의 각 마이크로서비스들은 신경쓸 필요 없이 비즈니스 로직에만 집중할 수 있다고 하는데요. 질문 내용 중 위 부분에 대해서 약간의 오해를 하고 계신 것 같은데요. 여기서 신경 쓸 필요가 없다라는 말은 각 마이크로서비스들이 인증/인가 관련해서 아예 할 것이 없다는 것이 아니라, 이미 API Gateway에서 처리했기 때문에 불필요한 작업(예: 사용자 DB 조회, 인가 서비스 호출)을 최소화할 수 있다는 것으로 이해하시는 것이 좋을 것 같습니다. 하나의 요청을 여러 마이크로서비스가 분담하는 MSA의 특성 상 API Gateway 뿐만 아니라 마이크로서비스 간에도 서로 요청/응답을 주고 받기 때문에 별도의 server-to-server 인증을 구현하기도 하고요. 인증 토큰에 사용자의 정보를 담아서 전송하는 경우도 있어서 그 데이터를 읽으려면 마이크로서비스에서 서명된 토큰을 검증하는 작업 등이 필요할 수도 있습니다.

질의하신 내용이 잘 설명된 블로그 글을 공유드립니다! https://medium.com/spoontech/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B5%AC%EC%A1%B0-msa-%EC%9D%98-%EC%9D%B8%EC%A6%9D-%EB%B0%8F-%EC%9D%B8%EA%B0%80-authorization-authentication-a595179ab88e

MSA(Microservices Architecture)에서의 인증과 인가에 대한 구성은 다양한 방식으로 이루어질 수 있습니다. 보통 API Gateway는 클라이언트로부터의 요청을 받아 인증 및 인가 로직을 처리하고, 실제 마이크로서비스에 대한 호출을 중개하는 역할을 수행합니다. 그러나 게이트웨이를 우회하여 직접 마이크로서비스에 접근하는 위험은 있을 수 있습니다. 마이크로서비스에 인가 로직이 없는 경우, 게이트웨이를 우회하여 직접 마이크로서비스에 접근할 수 있는 문제가 발생할 수 있습니다. 따라서 인가 로직은 여전히 중요한 부분이며, 마이크로서비스에도 적절한 인가 체계를 구현해야 합니다. 일반적으로 인가 로직은 게이트웨이와 마이크로서비스 양쪽에서 구현할 수 있습니다. 게이트웨이에서는 요청을 검증하고 필요한 인가 체계를 적용한 후, 검증된 요청만이 마이크로서비스로 전달됩니다. 마이크로서비스 자체에서도 요청을 받아들이기 전에 추가적인 인가 로직을 수행할 수 있습니다. 구체적인 아키텍처 구성은 프로젝트의 요구사항과 보안 정책에 따라 다를 수 있습니다. 일반적으로는 게이트웨이에서 인증 및 인가를 처리하고, 마이크로서비스에서는 추가적인 인가 로직을 수행하는 방식을 채택합니다. 이를 위해 OAuth, JWT(JSON Web Tokens), API 토큰 등을 사용하여 인증과 인가를 구현할 수 있습니다. 또한, 필요에 따라 API Gateway와 마이크로서비스 간에 보안 프로토콜(예: HTTPS)을 사용하여 통신을 암호화할 수도 있습니다. MSA의 보안은 중요한 측면이므로, 실제 구현 시 보안 전문가와의 협업이 필요할 수 있습니다. 보안 요구사항과 적절한 보안 솔루션을 고려하여 아키텍처를 구성하는 것이 좋습니다. 또한, 보안 감사 및 모니터링 도구를 활용하여 시스템의 보안 상태를 지속적으로 확인하고 개선하는 것도 중요합니다.