이 강의에서는 OAuth2 프레임워크의 클라이언트 자격 증명 부여 유형(Client Credentials Grant Type)을 사용하여 게이트웨이 서버를 보안하는 방법에 대해 자세히 설명하겠습니다. 이 게이트웨이 서버는 마이크로서비스 네트워크의 엣지 서버(Edge Server) 역할을 합니다.
전체적인 흐름 설명
우선, 이 클라이언트 자격 증명 부여 유형을 사용하여 우리의 게이트웨이 서버를 어떻게 보안할 것인지에 대해 설명하겠습니다. 클라이언트 자격 증명 부여 유형은 일반적으로 두 개의 백엔드 서버 간의 통신에서 사용됩니다.
시나리오:
-
클라이언트 애플리케이션: 이 애플리케이션은 외부 서비스, 외부 API, 혹은 외부 백엔드 서버일 수 있습니다. 이 애플리케이션은 마이크로서비스 네트워크와 통신하려고 합니다.
-
인증 서버(Auth Server): 우리의 인증 서버는 Keycloak을 사용하여 설정할 것이며, Easy Bank 마이크로서비스 네트워크 내에서 작동할 것입니다.
-
게이트웨이 서버(Resource Server): 이 서버는 리소스 서버 역할을 하며, 외부에서 오는 모든 요청에 대해 유효한 액세스 토큰을 요구할 것입니다.
단계별 클라이언트 자격 증명 부여 유형 흐름
-
클라이언트 애플리케이션의 요청: 클라이언트 애플리케이션은 인증 서버에 클라이언트 자격 증명(클라이언트 ID 및 클라이언트 비밀)을 제공하여 액세스 토큰을 요청합니다.
-
인증 서버의 응답: Keycloak 인증 서버는 클라이언트 자격 증명을 검증한 후, 클라이언트 애플리케이션에 액세스 토큰을 발급합니다.
-
게이트웨이 서버로의 요청: 클라이언트 애플리케이션은 발급받은 액세스 토큰을 사용하여 게이트웨이 서버에 요청을 보냅니다.
-
게이트웨이 서버의 액세스 토큰 검증: 게이트웨이 서버는 받은 액세스 토큰을 인증 서버에 검증 요청을 보내어, 토큰의 유효성을 확인합니다.
-
인증 서버의 응답: 인증 서버는 게이트웨이 서버에 액세스 토큰의 유효성을 확인해주며, 게이트웨이 서버는 클라이언트 애플리케이션의 요청을 처리합니다.
-
게이트웨이 서버의 응답: 게이트웨이 서버는 유효한 요청임을 확인한 후, 요청을 개별 마이크로서비스(예: 계좌, 대출, 카드 마이크로서비스)로 전달합니다. 마이크로서비스로부터 응답을 받은 후, 게이트웨이 서버는 이를 클라이언트 애플리케이션에 전달합니다.
보안 강화를 위한 추가 설명
개별 마이크로서비스(계좌, 대출, 카드 등)를 직접 보호하지 않으면, 외부 클라이언트 애플리케이션이 이들 마이크로서비스를 직접 호출할 수 있는 가능성이 있습니다. 이를 방지하기 위해, 이러한 마이크로서비스를 방화벽이나 Docker 네트워크 뒤에 배포하여 외부 클라이언트 애플리케이션이 직접 접근하지 못하도록 할 수 있습니다.
게이트웨이 서버는 마이크로서비스 네트워크의 유일한 진입점으로 설정되어, 모든 외부 요청이 게이트웨이 서버를 통해서만 이루어지도록 보장됩니다. 이를 통해 각 마이크로서비스에 대한 보안 부담을 줄이고, 성능 저하를 방지할 수 있습니다.
요약
- 클라이언트 자격 증명 부여 유형은 주로 두 백엔드 서버 간의 보안 통신에 사용됩니다.
- 게이트웨이 서버는 리소스 서버 역할을 하여 외부 요청에 대해 유효한 액세스 토큰을 요구합니다.
- Keycloak은 인증 서버로서 클라이언트 자격 증명을 검증하고 액세스 토큰을 발급합니다.
다음 단계
이제 다음 강의에서 Keycloak 설정 및 클라이언트 애플리케이션 등록 방법을 살펴보겠습니다. 이 과정을 통해 실제 예제를 구현하며 개념을 더욱 명확히 할 것입니다.
감사합니다, 다음 강의에서 뵙겠습니다. 안녕히 계세요!
