OAuth 2.0에서 리프레시 토큰(Refresh Token)은 액세스 토큰을 재발급하는 데 사용되며, 장기간 유효성을 가집니다. 이때 리프레시 토큰 재사용 공격(Refresh Token Replay Attack)을 방지하기 위해 롤링(Rotation) 전략이 권장됩니다. 리프레시 토큰 롤링의 정확한 동작 방식과 이점이 무엇인지 설명하고, 롤링 전략을 구현할 때 발생할 수 있는 잠재적인 문제점(예: 동시 요청 처리, 클라이언트 상태 관리)과 이에 대한 해결 방안을 제시해 주십시오.
힌트 · 리프레시 토큰 롤링은 매 사용마다 새 토큰을 발급하고 이전 토큰을 무효화하여 재사용 공격을 방지합니다. 동시성 문제 해결을 위해 이전 토큰 허용 기간 설정, 트랜잭션 처리 등을 고려해야 합니다.
모범답안
OAuth 2.0에서 리프레시 토큰 롤링은 리프레시 토큰을 사용하여 액세스 토큰을 갱신할 때마다 새로운 리프레시 토큰을 발급하고, 기존 리프레시 토큰은 즉시 무효화하는 방식입니다. 이렇게 하면 공격자가 탈취한 리프레시 토큰을 재사용하더라도, 이미 무효화되었기 때문에 공격이 실패합니다.
롤링 전략의 이점은 리프레시 토큰 탈취 시도를 효과적으로 막을 수 있다는 점입니다. 하지만 동시 요청 처리 문제가 발생할 수 있습니다. 예를 들어, 클라이언트가 동시에 여러 개의 갱신 요청을 보내면, 첫 번째 요청으로 토큰이 갱신된 후 나머지 요청은 무효화된 토큰을 사용하게 됩니다.
이러한 문제를 해결하기 위해 몇 가지 방법을 고려할 수 있습니다. 첫째, 이전 리프레시 토큰을 일정 기간 동안 유효하게 유지하는 것입니다. 이 기간 동안에는 이전 토큰으로도 갱신 요청을 처리할 수 있습니다. 둘째, 갱신 요청 처리 시 트랜잭션을 사용하여 토큰 발급과 무효화를 원자적으로 처리하는 것입니다. 셋째, 클라이언트 측에서 갱신 요청에 대한 멱등성을 보장하도록 구현하는 것입니다. 즉, 동일한 요청이 여러 번 전송되더라도 결과가 동일하도록 해야 합니다. 마지막으로, 클라이언트가 새로운 리프레시 토큰을 안전하게 저장하고 관리하도록 하는 것이 중요합니다.
읽었다면, 이제 직접 답해볼 차례예요
패스잇 앱에서 이 질문에 말로 답하면 AI가 꼬리질문까지 이어가며 1:1 코칭합니다.
함께 보는 인증 / 인가 (JWT · OAuth) 면접 질문
- Stateless한 JWT의 특성에도 불구하고, 서버 측에서 특정 JWT를 강제로 무효화(Revocation)해야 하는 상황이 발생할 수 있습니다. 이러한 상황에서 JWT를 무효화할 수 있는 전략들을 설명해 주세요.
- 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 또는 OpenID Connect 기반의 인증/인가 시스템을 설계할 때, API Gateway의 역할과 토큰 전달(Token Propagation) 전략에 대해 설명해 주십시오. 특히, 클라이언트로부터 받은 액세스 토큰을 백엔드 서비스들이 안전하고 효율적으로 검증하고 활용할 수 있도록 하는 방법에 대한 여러 접근 방식(예: 토큰 변환, 토큰 전달, 인가 정보 캐싱)을 비교하고, 각 방식의 장단점 및 적절한 사용 시나리오를 제시해 주십시오.
- 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) 측면의 주요 사항들을 설명하고, 이를 통해 얻을 수 있는 이점과 발생할 수 있는 문제점을 제시해 주십시오.