리소스 소유자 비밀번호 자격 증명(ROPC) 허가 유형을 사용 중단해야 하는 이유

소개#

리소스 소유자 비밀번호 자격 증명(ROPC) 허가 유형, 즉 비밀번호 허가 유형은 애플리케이션이 사용자의 사용자 이름과 비밀번호를 액세스 토큰으로 교환할 수 있게 하는 OAuth 2.0 흐름입니다. 이는 처음에는 HTTP 기본 인증 또는 더 보안이 강화된 OAuth 토큰화 흐름을 사용할 수 없는 기존 네이티브 애플리케이션과 같은 레거시 애플리케이션을 지원하기 위해 OAuth 2.0 규격에서 도입되었습니다.

그러나 ROPC 허가 유형은 여러 가지 보안 위험을 초래하며, OAuth 2.0 보안 모범 사례에서 사용해서는 안 됩니다로 지정되었습니다.

최근 우리는 여러 고객으로부터 ROPC 허가 유형 구현에 대한 지침이나 지원 요청을 받았습니다. 이 게시물에서는 특히 새로운 애플리케이션에 대해 ROPC 허가 유형을 사용하는 것을 피해야 하는 이유를 설명하겠습니다.

ROPC 허가 유형 vs. 인증 코드 흐름#

ROPC 허가 유형이 작동하는 방식#

ROPC 허가 유형은 사용자의 사용자 이름과 비밀번호를 액세스 토큰으로 교환하는 간단한 흐름입니다. 클라이언트 애플리케이션이 사용자의 자격 증명을 직접 수집하고 이를 인증 서버로 직접 전송합니다. 인증 서버는 자격 증명을 확인한 후 클라이언트에게 액세스 토큰을 발급합니다.

인증 코드 흐름이 작동하는 방식#

반면에, 인증 코드 흐름은 웹 애플리케이션에 권장되는 OAuth 2.0 흐름입니다. 이는 클라이언트 애플리케이션, 인증 서버, 사용자의 브라우저 간의 여러 단계와 리디렉션을 포함합니다. 인증 코드 흐름은 사용자의 자격 증명을 클라이언트 애플리케이션에 노출하지 않으므로 더 안전합니다.

ROPC 허가 유형과 인증 코드 흐름의 주요 차이점은 ROPC가 사용자의 자격 증명을 클라이언트 애플리케이션에 노출하지만, 인증 코드 흐름은 그렇지 않다는 것입니다. 사용자 자격 증명은 인증 서버 안에 기밀로 유지되어야 합니다. 클라이언트 애플리케이션이 사용자를 대신하여 리소스를 요청할 때, 클라이언트 애플리케이션 측에 최소한의 인증 데이터를 유지하면서 사용자에게 인증하고 클라이언트 애플리케이션을 승인하도록 인증 서버로 리디렉션해야 합니다.

ROPC 허가 유형의 보안 위험#

1. 사용자 자격 증명의 노출#

앞서 언급했듯이, ROPC 허가 유형은 사용자 자격 증명을 클라이언트 애플리케이션에 노출시킵니다. 이는 클라이언트 애플리케이션이 사용자의 자격 증명을 저장하거나 로그할 수 있으며, 사용자의 인지 없이 재승인될 수 있기 때문에 중대한 보안 위험을 초래합니다.

특히 모바일 애플리케이션이나 단일 페이지 애플리케이션(SPA)과 같은 공용 클라이언트 애플리케이션의 경우, 클라이언트 애플리케이션은 자격 증명을 추출하기 위해 쉽게 주입되거나 역엔지니어링될 수 있습니다. 사용자의 브라우저에서 실행 중인 모바일 애플리케이션이나 SPA는 비밀을 기밀로 유지할 수 없습니다. 따라서 사용자 자격 증명을 노출하지 않고는 사용자를 인증할 수 없습니다.

심지어 리소스 소유자가 클라이언트 애플리케이션과 신뢰할 수 있는 관계를 맺고 있다고 해도, 클라이언트 애플리케이션은 전체 인증 과정에서 중간자 역할을 하며, 악의적인 행위자에 의해 타협될 수 있습니다. 악의적인 행위자는 사용자의 자격 증명을 탈취하여 사용자를 가장하여 해당 사용자의 리소스에 액세스할 수 있습니다.

클라이언트 애플리케이션의 보안 상태에 따라 키로거, 피싱 공격 또는 악성 소프트웨어와 같은 여러 가지 방법으로 사용자의 자격 증명을 탈취할 수 있습니다. 특히 클라이언트 자격 증명은 모든 인증 요청 시 네트워크를 통해 전송되므로 자격 증명 인터셉션의 위험이 더욱 증가합니다.

여러 애플리케이션이 ROPC 허가 유형을 사용하는 경우, 자격 증명의 노출 위험은 배가 됩니다.

2. ROPC는 사용자 동의를 지원하지 않습니다#

ROPC 허가 유형은 사용자 동의를 지원하지 않습니다. 클라이언트 애플리케이션이 사용자의 자격 증명을 직접 수집하는 경우, 사용자는 클라이언트 애플리케이션의 자신의 리소스에 대한 액세스를 검토하고 승인할 기회를 가지지 못합니다. 이는 사용자의 개인 정보와 신뢰를 침해하는 것입니다.

사용자는 어떤 클라이언트 애플리케이션이 자신의 리소스에 액세스할 수 있는지를 결정해야 할 권리가 있으며, 이는 특히 GDPR과 같은 데이터 보호 규정을 준수하기 위해 필수적입니다.

3. ROPC는 다중 요소 인증을 지원하지 않습니다#

다중 요소 인증(MFA)은 사용자가 리소스에 액세스하기 위해 두 개 이상의 인증 요소를 제공하도록 요구하는 보안 구현입니다. 이는 인증 과정에 추가적인 보안 계층을 추가합니다. ROPC 허가 유형은 MFA를 지원하지 않으며, 대신 인증 과정을 단일 요소로 제한하고, 토큰 요청은 오직 사용자 자격 증명에만 기반을 둡니다. SMS OTP, 이메일 OTP 또는 WebAuthn과 같은 챌린지 기반 인증 메커니즘을 ROPC 허가 유형으로 구현하는 것은 불가능합니다.

ROPC는 현대 애플리케이션과 호환되지 않습니다#

ROPC 허가 유형은 현대 IAM 시스템의 싱글 사인온(SSO) 또는 연합된 신원(Federated Identites)을 지원할 수 없는 레거시 애플리케이션을 지원하기 위해 설계되었습니다.

1. ROPC는 SSO와 호환되지 않습니다#

싱글 사인온(SSO)은 사용자가 한 번 로그인하면 여러 애플리케이션에 쉽게 액세스할 수 있는 현대적인 인증 구조입니다.

SSO 구조에서는 중앙 집중식 IdP가 중요한 역할을 합니다. IdP는 사용자의 인증 세션을 관리하고 클라이언트 애플리케이션에게 토큰을 발급합니다. 클라이언트 애플리케이션은 사용자의 자격 증명을 직접 수집할 필요가 없으며, 사용자의 자격 증명은 IdP 내에서 기밀로 유지됩니다.

ROPC 허가 유형은 SSO를 지원하지 않습니다. 이는 클라이언트 애플리케이션이 사용자의 자격 증명을 직접 수집해야 하며, SSO 구조를 깨뜨립니다. OpenID Connect (OIDC)나 SAML과 같은 현대적인 SSO 시스템과 호환되지 않습니다.

2. ROPC는 연합된 신원과 호환되지 않습니다#

SSO 구조와 유사하게, 연합된 신원은 사용자가 기존 신원으로 여러 타사 애플리케이션에 액세스할 수 있도록 합니다. 사용자는 Google, Facebook 또는 Twitter와 같은 여러 사회적 계정을 중앙 집중식 IdP에 연결하고, 이 사회적 계정을 사용하여 클라이언트 애플리케이션을 인증할 수 있습니다. 모든 연합된 신원은 IdP에 의해 관리되며, 클라이언트 애플리케이션은 사용자의 인증 세부 정보를 인지하지 못합니다.

ROPC 허가 유형은 반대로 클라이언트 애플리케이션이 사용자의 자격 증명을 직접 수집하도록 요구합니다. 이는 클라이언트 애플리케이션이 연합된 신원을 지원하는 능력을 제한하고, 사용자의 신원 데이터를 클라이언트 애플리케이션에 노출시킵니다.

결론#

리소스 소유자 비밀번호 자격 증명(ROPC) 허가 유형은 중대한 보안 위험을 초래하는 레거시 OAuth 2.0 흐름으로, 사용 중단해야 합니다. 이는 사용자 자격 증명을 클라이언트 애플리케이션에 노출시키며, MFA나 SSO와 같은 현대적인 보안 메커니즘을 지원하지 않습니다. 애플리케이션에서 ROPC 허가 유형을 사용하는 것을 강력히 피하는 것을 권장합니다. ROPC 허가 유형에 의존하는 레거시 인증 시스템이 있는 경우, 인증 코드 흐름이나 클라이언트 자격 증명 흐름과 같은 더 안전한 OAuth 2.0 흐름으로 마이그레이션하는 것을 고려하십시오.

애플리케이션에 안전한 사용자 인증 및 권한 부여 서비스를 통합하거나 레거시 비밀번호 기반 인증 시스템에서 더 안전한 OAuth 2.0 흐름으로 마이그레이션하는 데 도움이 필요하다면, 연락해 주십시오. 우리는 여러분이 안전하고 현대적인 애플리케이션을 구축할 수 있도록 도와드리겠습니다.