마이크로서비스 아키텍처 환경에서 OAuth 2.0 또는 OpenID Connect 기반의 인증/인가 시스템을 설계할 때, API Gateway의 역할과 토큰 전달(Token Propagation) 전략에 대해 설명해 주십시오. 특히, 클라이언트로부터 받은 액세스 토큰을 백엔드 서비스들이 안전하고 효율적으로 검증하고 활용할 수 있도록 하는 방법에 대한 여러 접근 방식(예: 토큰 변환, 토큰 전달, 인가 정보 캐싱)을 비교하고, 각 방식의 장단점 및 적절한 사용 시나리오를 제시해 주십시오.
힌트 · API Gateway는 토큰 검증, 인가 정보 추출, 백엔드 서비스로의 토큰 전달을 담당합니다. 토큰 변환은 백엔드 서비스의 복잡성을 줄이지만 게이트웨이 부하를 높이고, 원본 토큰 전달은 백엔드 서비스가 직접 처리해야 합니다.
모범답안
마이크로서비스 환경에서 OAuth 2.0/OpenID Connect 기반 인증/인가 시스템 설계 시 API Gateway는 중요한 역할을 합니다. 클라이언트로부터 받은 액세스 토큰을 검증하고, 인가 정보를 추출하여 백엔드 서비스로 전달하는 것이 핵심입니다.
토큰 전달 전략은 크게 세 가지로 볼 수 있습니다. 첫째, 토큰 변환은 API Gateway가 토큰을 검증하고 필요한 정보만 담은 새로운 토큰(예: JWT)을 생성하여 백엔드 서비스에 전달하는 방식입니다. 백엔드 서비스의 복잡성을 줄이지만, 게이트웨이의 부하가 증가할 수 있습니다. 둘째, 원본 토큰 전달은 API Gateway가 받은 토큰을 그대로 백엔드 서비스에 전달하는 방식입니다. 백엔드 서비스가 직접 토큰을 검증해야 하므로 복잡성이 증가하지만, 게이트웨이의 부하를 줄일 수 있습니다. 셋째, 인가 정보 캐싱은 API Gateway가 토큰 검증 후 인가 정보를 캐싱하여 반복적인 검증 요청을 줄이는 방식입니다. 성능을 향상시킬 수 있지만, 캐시 관리 전략이 중요합니다.
각 방식은 트레이드오프가 존재합니다. 토큰 변환은 백엔드 서비스가 단순할 때, 원본 토큰 전달은 백엔드 서비스가 토큰 검증 로직을 처리할 수 있을 때, 인가 정보 캐싱은 API 호출 빈도가 높을 때 적합합니다. 상황에 따라 적절한 방식을 선택해야 합니다.
읽었다면, 이제 직접 답해볼 차례예요
패스잇 앱에서 이 질문에 말로 답하면 AI가 꼬리질문까지 이어가며 1:1 코칭합니다.
함께 보는 인증 / 인가 (JWT · OAuth) 면접 질문
- OAuth 2.0 Authorization Code Flow에서 PKCE(Proof Key for Code Exchange)를 사용하는 것이 일반적입니다. 하지만 더욱 강화된 보안을 위해 DPoP(Demonstration of Proof-of-Possession) 또는 CIBA(Client Initiated Backchannel Authentication)와 같은 확장 기능들이 논의되고 있습니다. 이들 중 하나를 선택하여, 해당 기술이 OAuth 2.0/OpenID Connect 기반 시스템의 어떤 보안 취약점을 해결하고, 실제 구현 시 고려해야 할 설계 및 운영상의 주요 사항들을 설명해 주십시오.
- 대규모 분산 환경에서 JWT(JSON Web Token) 기반의 액세스 토큰을 사용하는 경우, 특정 사용자의 세션을 강제로 만료시키거나 토큰을 즉시 무효화해야 할 필요가 발생할 수 있습니다. JWT는 자체 검증 가능(self-contained)하다는 특성 때문에 서버에서 직접 관리하기 어렵습니다. 이러한 분산 환경에서 JWT의 즉각적인 무효화를 효과적으로 구현하기 위한 여러 전략(예: 블랙리스트, 체크리스트, 짧은 만료 시간과 리프레시 토큰 활용 등)과 각 전략의 장단점, 그리고 시스템 부하 및 일관성 측면에서의 고려사항을 설명해 주십시오.
- OAuth 2.0에서 리프레시 토큰(Refresh Token)은 액세스 토큰을 재발급하는 데 사용되며, 장기간 유효성을 가집니다. 이때 리프레시 토큰 재사용 공격(Refresh Token Replay Attack)을 방지하기 위해 롤링(Rotation) 전략이 권장됩니다. 리프레시 토큰 롤링의 정확한 동작 방식과 이점이 무엇인지 설명하고, 롤링 전략을 구현할 때 발생할 수 있는 잠재적인 문제점(예: 동시 요청 처리, 클라이언트 상태 관리)과 이에 대한 해결 방안을 제시해 주십시오.
- OAuth 2.0 또는 OpenID Connect 인증 흐름에서 발생할 수 있는 CSRF(Cross-Site Request Forgery), XSS(Cross-Site Scripting), Open Redirect와 같은 일반적인 웹 취약점들이 인증 과정에 어떻게 영향을 미칠 수 있는지 구체적인 공격 시나리오를 들어 설명해 주십시오. 또한, 각 취약점에 대한 효과적인 방어 메커니즘(예: `state` 파라미터, `redirect_uri` 유효성 검사, CSP, SameSite Cookie)을 제시하고, 이들을 인증 시스템 설계에 어떻게 반영할 것인지 설명해 주십시오.
- OpenID Connect는 OAuth 2.0 위에 아이덴티티 레이어를 추가하여 사용자 인증을 제공합니다. 표준 스코프(profile, email 등) 외에, 특정 비즈니스 요구사항을 만족시키기 위해 커스텀 스코프(Custom Scope)와 클레임(Custom Claim)을 정의하여 사용할 수 있습니다. 커스텀 스코프와 클레임을 설계하고 구현할 때 고려해야 할 보안 및 상호 운용성(Interoperability) 측면의 주요 사항들을 설명하고, 이를 통해 얻을 수 있는 이점과 발생할 수 있는 문제점을 제시해 주십시오.
- 대규모 엔터프라이즈 환경에서 여러 서비스와 애플리케이션 간에 통합된 사용자 인증 및 인가(Federated Identity Management)를 구현하기 위해 OpenID Connect를 활용하는 방안을 설명해 주십시오. 특히, 여러 Identity Provider(IdP)를 연동해야 하는 시나리오(예: 소셜 로그인, 기업 SSO)에서 OpenID Connect 브로커링(Brokering) 또는 프록싱(Proxying) 패턴의 필요성과 동작 원리를 설명하고, 이 패턴을 도입할 때의 장단점과 주요 설계 고려사항을 제시해 주십시오.