WebAuthn 관련 오리진 요청(ROR)이란 무엇인가요?

WebAuthn 관련 오리진 요청(ROR)은 신뢰할 수 있는 도메인 집합이 단일 패스키를 공유할 수 있도록 하는 WebAuthn 표준의 기능입니다. 이를 통해 사용자는 amazon.com, amazon.de, amazon.co.uk와 같은 여러 관련 사이트에서 동일한 패스키로 원활하게 로그인할 수 있습니다.

ROR은 어떻게 작동하나요?

ROR은 기본 도메인(rpID)이 `/.well-known/webauthn`이라는 표준화된 URL에 JSON 파일을 호스팅하는 방식으로 작동합니다. 이 파일에는 해당 rpID를 사용할 수 있도록 승인된 다른 모든 오리진(도메인)이 나열되어 있습니다. 브라우저는 교차 도메인 패스키 사용을 허용하기 전에 이 파일을 확인합니다.

ROR과 연동 로그인(OIDC/SAML)의 차이점은 무엇인가요?

ROR은 동일한 사용자 기반을 가진 여러 도메인에 걸친 *단일* 애플리케이션을 위한 것입니다. 연동 로그인(OIDC/SAML)은 사용자가 한 번 로그인하여 Salesforce나 Office 365와 같은 *여러 별개의* 애플리케이션에 접근하는 진정한 싱글 사인온(SSO)을 위한 것입니다.

ROR 구현의 주요 요구 사항은 무엇인가요?

구현에는 두 가지 핵심 요소가 필요합니다. 1) 서버 측: 기본 rpID 도메인에 `/.well-known/webauthn` 파일을 올바르게 구성하고 제공해야 합니다. 2) 클라이언트 측: 관련된 모든 웹사이트가 WebAuthn API 호출에서 동일한 공유 rpID를 일관되게 사용하도록 해야 합니다.

모든 브라우저가 관련 오리진 요청을 지원하나요?

2024년 말부터 주요 브라우저에서 지원이 시작되었습니다. Chrome과 Edge는 버전 128부터, Safari는 Safari 18(macOS 15 및 iOS 18)부터 ROR을 지원합니다. Firefox는 현재 지원하지 않으므로 폴백 전략이 필요합니다.

WebAuthn 관련 오리진: 교차 도메인 패스키 가이드

1. 서론: 패스키를 위한 디지털 국경 허물기#

패스키는 안전하고 사용자 친화적인 인증을 위한 새로운 표준입니다. FIDO/WebAuthn 표준을 기반으로 구축된 패스키는 공개 키 암호화를 활용하여 피싱 및 크리덴셜 스터핑에 대한 내재적인 저항성을 제공하며, 사용자의 로그인 경험을 단순화하는 동시에 보안 태세를 획기적으로 개선합니다. 기업의 경우, 이는 가시적인 비즈니스 이점으로 이어집니다. 즉, 비밀번호 재설정 및 SMS OTP로 인한 운영 비용을 절감하고, 계정 탈취 사기로 인한 재정적 위험을 완화하며, 더 높은 전환율을 통해 수익을 증대할 수 있습니다.

하지만 WebAuthn의 가장 큰 보안 강점 중 하나인 엄격한 오리진 바인딩 특성은 다양한 디지털 발자국을 가진 글로벌 브랜드와 기업에게 중요한 현실적 과제를 안겨줍니다. 설계상 특정 웹 도메인에 대해 생성된 패스키는 해당 도메인에 암호학적으로 잠기게 되는데, 이는 피싱 공격을 방지하는 기본 원칙입니다. 이는 강력한 보안 기능이지만, 단일 브랜드가 여러 도메인에서 운영될 때 사용자 경험을 분편적이고 혼란스럽게 만듭니다.

이러한 과제의 대표적인 예는 트위터가 X로 리브랜딩한 사례입니다. twitter.com에서 패스키를 만든 사용자는 x.com에서는 이를 사용할 수 없게 되어, 회사는 번거로운 리디렉션을 구현하거나 사용자가 다시 등록하도록 요구해야 했습니다. 이는 도입을 직접적으로 방해하는 마찰을 일으켰습니다. 이는 단지 한 번의 사례가 아닙니다. 아마존과 같은 대기업은 amazon.com, amazon.de, amazon.co.uk와 같은 수많은 국가 코드 최상위 도메인(ccTLD)에서 공통 사용자 계정 시스템을 공유하며 운영됩니다. 패스키 이전 시대에는 비밀번호 관리자가 이러한 복잡성을 능숙하게 처리했지만, WebAuthn의 기본 동작은 각 도메인마다 별도의 패스키를 요구하여 사용자를 좌절시키고 원활한 로그인의 약속을 저해합니다.

이러한 핵심적인 도입 장애물을 해결하기 위해 W3C는 WebAuthn 표준에 새로운 기능인 **관련 오리진 요청(Related Origin Requests, ROR)**을 도입했습니다. 이 강력한 메커니즘은 신뢰할 수 있는 도메인 집합이 단일 패스키를 공유할 수 있는 표준화되고 안전한 방법을 제공하여, 브랜드의 전체 디지털 생태계에 걸쳐 통합되고 원활한 인증 경험을 만듭니다. 이 심층 가이드에서는 ROR의 기술적 기반을 탐색하고, 구현에 대한 실용적인 가이드를 제공하며, 현대 인증 아키텍처에 대한 전략적 의미를 분석합니다.

ROR의 도입은 WebAuthn 표준이 크게 성숙했음을 보여줍니다. 초기 사양은 핵심 암호화 및 보안 원칙을 확립하는 데 우선순위를 두었으며, 자격 증명을 신뢰 당사자 ID(rpID)에 엄격하게 바인딩하는 것이 안티-피싱 설계의 초석이었습니다. 아마존이나 구글과 같은 기업의 대규모 엔터프라이즈 배포가 현실화되면서 이러한 경직성으로 인한 실질적인 마찰이 명백해졌습니다. 이러한 마찰은 모든 패스키 프로젝트의 궁극적인 성공 척도인 높은 사용자 채택률을 달성하는 데 직접적인 장애물이 됩니다. ROR의 개발은 이러한 기업의 피드백에 대한 직접적인 응답이며, 표준의 실용적인 진화를 보여줍니다. 이는 보안 프로토콜이 광범위한 성공을 거두기 위해서는 그 사용성이 배포하는 조직의 복잡한 비즈니스 현실과 브랜딩 전략을 수용할 수 있도록 확장되어야 한다는 점을 인정하는 것입니다.

이 종합 가이드는 WebAuthn 관련 오리진 요청을 구현하기 위한 다섯 가지 중요한 질문에 답합니다:

왜 패스키는 여러 도메인에서 작동하지 않을까요? WebAuthn의 오리진 바인딩 보안 모델과 실제적인 마찰 지점 이해하기
관련 오리진 요청은 기술적으로 어떻게 작동하나요? 브라우저 유효성 검사 흐름과 .well-known URI 메커니즘 심층 분석
ROR을 구현하려면 무엇이 필요한가요? 실용적인 코드 예제를 통한 단계별 서버 및 클라이언트 측 구성
언제 연동 로그인 대신 ROR을 선택해야 할까요? ROR과 OIDC/SAML 접근 방식을 비교하는 전략적 의사 결정 프레임워크
브라우저 호환성 및 보안 고려 사항은 어떻게 처리하나요? 현재 지원 매트릭스 및 보안 모범 사례

더 자세한 기술 정보는 공식 WebAuthn 관련 오리진 요청 설명서를 참조하세요.

2. 근본적인 문제: WebAuthn의 신뢰 당사자 ID 및 오리진 범위 지정#

관련 오리진 요청 솔루션의 우아함을 완전히 이해하려면, 그 존재를 필요하게 만든 기본 기술 개념인 웹의 동일 출처 정책과 WebAuthn의 신뢰 당사자 ID(rpID) 범위 지정 규칙을 먼저 이해하는 것이 중요합니다. 이러한 메커니즘은 웹 보안의 기초이지만, ROR이 완화하도록 설계된 바로 그 마찰을 만들어냅니다.

2.1 웹 오리진과 동일 출처 정책#

웹 "오리진"은 콘텐츠가 제공되는 프로토콜(예: https), 도메인(예: app.example.com), 포트(예: 443)의 고유한 조합으로 정의되는 중요한 보안 개념입니다. 동일 출처 정책(Same-Origin Policy)은 한 오리진에서 로드된 스크립트가 다른 오리진의 리소스와 상호 작용하는 것을 제한하는 브라우저가 강제하는 보안 메커니즘입니다. 이는 웹 보안의 중요한 요소로, 잠재적으로 악의적인 문서를 효과적으로 격리하고 예를 들어 사기성 웹사이트가 다른 탭에 있는 사용자의 인증된 웹메일 세션에서 민감한 데이터를 읽는 것을 방지합니다.

2.2 신뢰 당사자 ID(rpID)#

WebAuthn 생태계에서 "신뢰 당사자"(RP)는 사용자가 인증하려는 웹사이트나 애플리케이션입니다. 모든 패스키는 생성 시점에 **신뢰 당사자 ID(rpID)**에 암호학적으로 바인딩됩니다. rpID는 해당 자격 증명의 범위와 경계를 정의하는 도메인 이름입니다.

기본적으로 rpID는 패스키가 생성되는 오리진의 유효 도메인입니다. WebAuthn의 범위 지정 규칙에 따르면 오리진은 자신의 도메인과 같거나 등록 가능한 도메인 접미사인 rpID를 설정할 수 있습니다. 예를 들어, https://www.accounts.example.co.uk에서 실행되는 스크립트는 다음과 같은 rpID로 패스키를 생성할 수 있습니다:

www.accounts.example.co.uk (전체 도메인)
accounts.example.co.uk
example.co.uk

이러한 유연성 덕분에 한 하위 도메인에서 생성된 패스키를 동일한 상위 도메인의 다른 하위 도메인에서 사용할 수 있으며, 이는 일반적이고 필요한 패턴입니다. 하지만 규칙은 접미사가 아닌 rpID를 설정하는 것을 엄격히 금지합니다. www.accounts.example.co.uk의 동일한 스크립트는 .com이 다른 최상위 도메인이기 때문에 example.com이라는 rpID로 패스키를 생성할 수 없습니다.

이러한 엄격한 바인딩은 중요한 목적을 수행합니다: 도메인 범위별로 자격 증명을 분리하는 것입니다. mybank.com용으로 생성된 패스키는 악성 사이트가 mybank.com의 합법적인 rpID를 주장할 수 없기 때문에 phishing-site.com에서는 사용할 수 없습니다. 브라우저는 심지어 해당 패스키를 옵션으로 제시하지도 않습니다.

하지만 rpID 자체는 주된 피싱 방지 제어 수단이 아닙니다. WebAuthn의 피싱 보호는 실제로는 clientDataJSON 객체 내의 오리진 검증에서 비롯됩니다. 모든 WebAuthn 절차 중에 브라우저는 요청을 시작한 _정확한 오리진_을 포함한 중요한 컨텍스트가 담긴 JSON 객체를 생성합니다. 이 전체 객체는 인증자의 개인 키로 암호학적으로 서명됩니다. 서버(신뢰 당사자)는 이 서명을 반드시 확인해야 하며, 결정적으로 서명된 clientDataJSON의 오리진 필드가 예상되는 신뢰할 수 있는 값과 일치하는지 검증해야 합니다. 이 오리진 검증이 피싱 공격을 막는 것입니다.

관련 오리진 요청을 사용하면 rpID 범위 지정이 완화되어, 브라우저가 .well-known/webauthn 파일을 검증한 후 bar.com이 foo.com의 rpID를 합법적으로 주장할 수 있게 됩니다. 하지만 오리진 검증 요구 사항은 변경되지 않습니다. clientDataJSON은 여전히 오리진을 bar.com으로 사실대로 보고합니다. foo.com의 서버는 이 서명된 데이터를 수신하고 검증하며, 요청이 bar.com에서 왔다는 것을 확인합니다. 그런 다음 서버는 인증을 수락하기 전에 bar.com이 예상되는 관련 오리진인지 확인해야 합니다. 이는 핵심적인 오리진 검증 원칙을 희생하지 않으면서도 더 큰 유연성을 허용하는 다층적인 접근 방식을 보여줍니다.

3. 해결책: 관련 오리진 요청의 작동 방식#

관련 오리진 요청 메커니즘은 도메인이 패스키 공유를 목적으로 신뢰 관계를 공개적으로 선언할 수 있는 우아하고 표준화된 방법을 도입합니다. 이는 잘 알려진 웹 패턴인 /.well-known/ URI를 활용하여 브라우저가 참조할 수 있는 검증 가능하고 기계가 읽을 수 있는 "허용 목록"을 만듭니다.

핵심 개념은 간단합니다. 관련 사이트 집합의 기본적이고 표준적인 rpID 역할을 하는 도메인은 표준화된 "잘 알려진" URL인 https://{rpID}/.well-known/webauthn에 특별한 JSON 파일을 호스팅할 수 있습니다. 이 파일은 해당 기본 rpID 하에서 패스키를 생성하고 사용할 수 있도록 공식적으로 승인된 다른 모든 오리진을 명시적으로 나열하는 공개적인 선언문 역할을 합니다.

브라우저의 유효성 검사 흐름은 현재 오리진과 요청된 rpID 간의 불일치를 감지할 때마다 트리거됩니다:

https://example.co.uk와 같은 "관련" 사이트의 사용자가 패스키 작업(생성 또는 인증)을 시작합니다. 이때 클라이언트 측 코드는 다른 도메인(예: example.com)을 rpID로 지정합니다.
브라우저는 이 불일치를 감지합니다. 이전 규칙 하에서는 즉시 SecurityError가 발생했을 것입니다.
ROR 지원을 통해 브라우저는 실패하기 전에 주장된 rpID의 잘 알려진 URL인 https://example.com/.well-known/webauthn으로 안전한 HTTPS GET 요청을 보냅니다. 이 요청은 사용자 개인 정보 보호 및 추적 방지를 위해 사용자 자격 증명(쿠키 등) 없이, 그리고 리퍼러 헤더 없이 이루어집니다.
브라우저는 서버로부터 JSON 응답을 받습니다. 파일을 파싱하고 현재 오리진(https://example.co.uk)이 JSON 객체 내의 origins 배열에 있는지 확인합니다.
오리진이 허용 목록에서 발견되면, WebAuthn 작업은 example.com을 유효한 rpID로 사용하여 계속 진행할 수 있습니다. 오리진이 발견되지 않거나 파일이 없거나 형식이 잘못된 경우, 작업은 이전과 같이 실패합니다.

/.well-known/ URI를 사용하기로 한 결정은 의도적인 것이며, ROR을 서비스 검색 및 도메인 제어 검증을 위한 기존 웹 표준과 일치시킵니다. RFC 8615에 정의된 이 URI 경로는 Let's Encrypt SSL 인증서 발급을 위한 acme-challenge나 웹사이트를 안드로이드 애플리케이션에 연결하기 위한 assetlinks.json 등 수많은 중요 프로토콜에서 이미 사용되고 있습니다. 이 관례를 채택함으로써 W3C는 본질적으로 도메인 소유권을 암시하는 패턴을 활용합니다. 이 특정하고 표준화된 경로에 파일을 배치하려면 해당 도메인의 웹 서버에 대한 관리 제어 권한이 있어야 합니다. 이는 간단하면서도 효과적인 제어 증명을 제공하여 신뢰 선언을 검증 가능하게 만듭니다. example.com의 소유자가 example.co.uk를 관련 오리진으로 나열하는 파일을 제공하면, 이는 검증 가능한 주장입니다. 이러한 웹 네이티브 접근 방식은 표준화 과정에서 고려되었지만 기각된 대안들, 즉 암호화 키를 사용하여 인증에 서명하는 것(RP 키)이나 도메인 기반이 아닌 무작위 식별자(RP UUID)를 사용하는 것보다 훨씬 간단하고 강력합니다. ROR은 신뢰 관계를 기존의 잘 알려진 웹의 도메인 제어 모델에 기반을 둡니다.

4. 관련 오리진을 위한 실용적인 구현 가이드#

관련 오리진 요청을 구현하려면 오리진을 승인하기 위한 서버 측 변경과 공유 rpID를 호출하기 위한 클라이언트 측 변경이 모두 조율되어야 합니다. 이 섹션에서는 도메인 전반에 걸쳐 통합된 패스키 경험을 활성화하는 데 필요한 실용적인 코드와 구성 세부 정보를 제공합니다.

4.1 서버 측: .well-known/webauthn으로 오리진 승인하기#

기본 rpID를 호스팅하는 서버는 관련 오리진의 허용 목록을 게시할 책임이 있습니다.

4.1.1 파일 위치 및 형식#

승인 파일은 기본 rpID 도메인의 루트를 기준으로 정확한 경로인 /.well-known/webauthn에 위치해야 합니다. 이 파일이 다음 조건 하에 제공되는 것이 중요합니다:

프로토콜: HTTPS를 통해 제공되어야 합니다.
Content-Type: HTTP 응답 헤더의 Content-Type은 application/json으로 설정되어야 합니다.
파일 확장자: URL에 .json 확장자를 포함해서는 안 됩니다. 올바른 경로는 /webauthn.json이 아닌 /webauthn입니다.

4.1.2 JSON 구조#

파일은 origins라는 하나의 키를 가진 단일 JSON 객체를 포함해야 하며, 그 값은 문자열 배열입니다. 배열의 각 문자열은 승인되는 전체 오리진(프로토콜, 도메인 및 선택적 포트)입니다.

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

예시: example.com이라는 rpID의 경우, 파일은 https://example.com/.well-known/webauthn에서 제공되어야 합니다(.json 확장자 없음).

4.2 클라이언트 측: 공유 rpID 호출하기#

서버가 .well-known/webauthn 파일로 구성되면, 모든 관련 도메인은 WebAuthn API 호출에서 동일한 공유 rpID를 일관되게 사용해야 합니다. 이 조율은 ROR이 올바르게 작동하는 데 매우 중요합니다.

주요 조율 요구사항:

백엔드 책임: 서버는 암호화 챌린지를 생성하고, 자격 증명 생성 및 인증 요청 모두에 공유 rpID를 지정합니다.
프론트엔드 책임: 모든 클라이언트 애플리케이션(example.com, example.co.uk, example.de)은 동일한 공유 rpID를 브라우저의 navigator.credentials API에 전달해야 합니다.
구성 관리: 공유 rpID는 모든 관련 사이트에서 일관되게 적용되는 중요한 전역 구성 값으로 취급되어야 합니다.

단 하나의 사이트에서라도 구성이 잘못되어 공유 값 대신 자신의 오리진을 rpID의 기본값으로 사용하게 되면, 해당 도메인의 사용자를 위한 통합 패스키 경험이 깨지게 됩니다.

중요: 서버는 모든 요청에 대해 clientDataJSON의 origin 필드를 반드시 확인하여, 승인된 관련 오리진 중 하나와 일치하는지 확인해야 합니다. 이 오리진 검증이 주된 피싱 보호 메커니즘입니다.

5. 권장 사항: 통합된 브랜드 경험에는 ROR, 진정한 SSO에는 OIDC를 선택하세요#

관련 오리진 요청(ROR)과 연동 ID 프로토콜(OIDC/SAML)은 서로 다른 문제를 해결합니다. ROR은 싱글 사인온(Single Sign-On)을 대체하는 것이 아니라, 특정하고 좁은 사용 사례를 다루는 보완재입니다.

5.1 관련 오리진 요청을 사용해야 할 때#

ROR은 동일한 사용자 데이터베이스를 공유하는 여러 관련 도메인에 분산된 단일 논리적 애플리케이션에 적합합니다:

여러 국가 코드 TLD를 운영하는 단일 브랜드 (예: amazon.com, amazon.de, amazon.co.uk)
모든 도메인이 동일한 백엔드 인증 시스템과 사용자 데이터베이스를 공유
리디렉션 기반 흐름을 피하고 각 도메인에 대한 컨텍스트 인증을 유지하고 싶을 때
도메인이 5개 레이블 제한 내에 있을 때
사용자가 모든 도메인을 하나의 응집력 있는 서비스로 경험해야 할 때

ROR이 제공하는 것: 동일한 패스키가 모든 관련 도메인에서 작동하여, 사용자가 각 지역 사이트마다 별도의 패스키를 만들 필요가 없어집니다.

5.2 연동 로그인(OIDC/SAML)을 사용해야 할 때#

별개의 애플리케이션 간의 진정한 싱글 사인온을 위해서는 연동 ID 프로토콜을 사용하세요:

별도의 사용자 데이터베이스나 ID 시스템을 가진 여러 서비스
사용자가 여러 다른 애플리케이션(Salesforce, Office 365, 내부 도구)에 접근해야 하는 기업 시나리오
제3자 애플리케이션 통합
중앙 집중식 접근 제어, 감사 추적, ID 거버넌스가 필요할 때
관련 오리진의 5개 레이블 제한을 초과할 때

OIDC/SAML이 제공하는 것: 사용자가 ID 제공자(Identity Provider)(IdP)에서 한 번 로그인하면 보안 토큰을 통해 여러 서비스 제공자(SP)에 접근할 수 있는 중앙 집중식 인증입니다.

중요: 패스키는 두 가지 접근 방식 모두와 함께 사용할 수 있습니다. 연동 SSO를 위해 중앙 집중식 IdP에 패스키를 구현하거나, 다중 도메인 단일 애플리케이션을 위해 ROR을 사용할 수 있습니다. 인증 방법이 아닌 아키텍처에 따라 선택하세요.

6. 패스키 아키텍처를 위한 전략적 고려사항#

ROR은 강력한 기술적 해결책이지만, 그 구현은 신중한 전략적 결정이어야 합니다. 아키텍트와 제품 관리자는 강력하고 미래에도 경쟁력 있는 인증 시스템을 구축하기 위해 ROR의 이점과 대안 패턴을 비교하고 그 한계를 이해해야 합니다.

6.1 5개 레이블 제한 이해하기#

ROR의 핵심 제약 조건은 "레이블 제한"입니다. 여기서 "레이블"은 유효 최상위 도메인에 한 수준을 더한 것(eTLD+1), 즉 도메인 이름의 등록 가능한 부분을 의미합니다. 예를 들면 다음과 같습니다:

shopping.com, shopping.co.uk, shopping.ca는 모두 **"shopping"**이라는 단일 레이블을 공유합니다.
myshoppingrewards.com은 **"myshoppingrewards"**라는 새롭고 별개의 레이블을 도입합니다.
travel.shopping.com은 여전히 "shopping" 레이블에 속합니다.

WebAuthn 레벨 3 사양은 브라우저 구현이 origins 목록에서 최소 5개의 고유 레이블을 지원하도록 요구합니다. 2025년 현재, 이 최소 5개 레이블보다 더 많이 지원하는 것으로 알려진 브라우저는 없습니다. 따라서 조직은 이 엄격한 제한을 염두에 두고 ROR 배포를 설계해야 합니다. 즉, 5개를 사실상의 최댓값으로 취급해야 합니다.

이 제한은 오용을 방지하기 위해 의도적으로 설계된 남용 방지 메커니즘입니다. 이는 공유 호스팅 제공업체(예: wordpress.com)와 같은 주체가 수천 개의 관련 없는 고객 하위 도메인에서 작동할 수 있는 범용 패스키를 만드는 것을 막아 보안 모델을 훼손하는 것을 방지합니다.

대부분의 조직, 심지어 대규모 다국적 브랜드에게도 이 5개 레이블 제한은 충분합니다. 예를 들어, 아마존의 다양한 국가 코드 TLD(amazon.com, amazon.de, amazon.co.uk 등)는 모두 "amazon" 레이블을 공유하므로, "audible"이나 "zappos"와 같은 포트폴리오 내 다른 브랜드를 위해 4개의 추가 레이블 슬롯이 남습니다.

6.2 배포 전략: 신규(Greenfield) 시스템 vs. 기존 시스템#

ROR 구현의 복잡성은 새로운 시스템에 도입되는지 아니면 기존 시스템에 개조되는지에 따라 크게 달라집니다.

신규 배포: 새로운 프로젝트의 경우 전략은 간단합니다. 처음부터 단일의 표준 도메인을 공유 rpID로 선택해야 합니다(예: 기본 .com 도메인). 그런 다음 이 rpID는 첫날부터 모든 관련 웹사이트 및 애플리케이션의 구성에 일관되게 사용되어야 합니다.
기존 배포: 도메인 전반에 걸쳐 이미 다른 rpID로 패스키가 배포된 시스템에 ROR을 개조하는 것은 훨씬 더 복잡합니다. 기존 패스키는 원래의 rpID에 영구적으로 바인딩되어 있으므로 직접적인 마이그레이션은 불가능합니다. 이 시나리오에서 권장되는 접근 방식은 "식별자 우선" 로그인 흐름을 구현하는 것입니다. 사용자에게 먼저 사용자 이름이나 이메일을 입력하라는 메시지를 표시합니다. 그런 다음 백엔드는 조회를 수행하여 기존 패스키가 어떤 rpID와 연결되어 있는지 확인합니다. 마지막으로 사용자는 인증 절차를 완료하기 위해 해당 rpID에 해당하는 올바른 오리진으로 리디렉션됩니다. 성공적으로 로그인한 후에는 원래 사이트로 다시 리디렉션될 수 있습니다. 이는 신중한 계획과 구현이 필요한 상당한 아키텍처 작업입니다.

7. 실제 사례: 주요 브랜드들이 관련 오리진을 구현하는 방법#

유명 기업들이 관련 오리진 요청을 어떻게 구현하는지 이해하면 자체 배포 전략에 대한 귀중한 통찰력을 얻을 수 있습니다. 다음은 실제 구현을 기반으로 한 예시입니다(2025년 10월 기준):

7.1 Microsoft의 구현#

Microsoft는 인증 인프라에 ROR을 사용합니다. login.microsoftonline.com의 실제 구성은 다음과 같습니다:

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

이러한 보수적인 접근 방식은 Microsoft의 기업 및 소비자 로그인 포털 간의 패스키 공유를 가능하게 하면서 집중된 보안 경계를 유지합니다.

7.2 Shopify의 구현#

Shopify는 일부 도메인 간의 인증을 통합하기 위해 ROR을 구현합니다:

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

이 구성은 Shopify가 주요 플랫폼을 Shop 앱과 연결할 수 있게 하여, 관련 오리진에 대한 집중적인 접근 방식을 보여줍니다.

7.3 Amazon의 구현#

Amazon은 상당히 큰 파일을 가지고 있습니다:

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

이 패턴을 사용하면 브랜드는 기본 .com 도메인을 rpID로 사용하면서 지역별 도메인 전반에 걸쳐 통합된 패스키 인증을 제공할 수 있습니다.

7.4 구현 패턴 및 모범 사례#

이러한 실제 사례들은 몇 가지 핵심 패턴을 보여줍니다:

기본 도메인을 rpID로 사용: 모든 회사가 기본 .com 도메인을 표준 rpID로 사용합니다.
논리적 그룹화: 오리진은 기술 아키텍처보다는 비즈니스 기능별로 그룹화됩니다.
보수적인 범위: 대부분의 구현은 5개 레이블 제한보다 훨씬 적게, 일반적으로 3~4개의 오리진을 사용합니다.
하위 도메인 전략: 많은 곳에서 브랜드 일관성을 유지하기 위해 기본 도메인의 하위 도메인을 사용합니다.

8. 브라우저 지원 및 보안#

현대 웹 표준으로서 ROR은 보안을 최우선으로 고려하여 설계되었으며 주요 브라우저에서 활발하게 채택되고 있습니다.

8.1 보안 모델#

관련 오리진 요청은 WebAuthn의 핵심적인 피싱 방지 보장을 손상시키지 않습니다. 이 메커니즘은 강력한 보안 태세를 유지하도록 신중하게 설계되었습니다:

오리진 검증: 논의된 바와 같이, 브라우저는 서명된 clientDataJSON에 요청의 실제 오리진을 여전히 포함합니다. 신뢰 당사자 서버는 이 오리진을 반드시 검증하여 요청이 예상된 소스에서 오는지 확인해야 하며, 이를 통해 손상된 관련 오리진이 다른 오리진을 사칭하는 것을 방지합니다.
보안 페치: 브라우저가 .well-known/webauthn 파일에 보내는 요청은 HTTPS를 통해 이루어집니다. 또한 사양에서는 이 페치가 자격 증명(예: 쿠키) 없이, 그리고 Referer 헤더 없이 수행되어야 한다고 규정합니다. 이는 요청이 사용자 정보 유출이나 교차 사이트 추적 목적으로 사용되는 것을 방지합니다.
서버 보안: .well-known/webauthn 파일 자체는 중요한 보안 자산이 됩니다. 기본 rpID를 호스팅하는 웹 서버를 장악한 공격자는 잠재적으로 이 파일을 수정하여 자신의 악성 도메인을 허용 목록에 추가할 수 있습니다. 따라서 이 파일을 제공하는 인프라를 보호하는 것이 가장 중요합니다.

8.2 브라우저 및 플랫폼 지원#

관련 오리진 요청은 WebAuthn 레벨 3 사양의 기능입니다. 브라우저 지원은 2024년 말부터 시작되었습니다:

운영 체제	브라우저 / 플랫폼	버전 지원	상태
안드로이드	Chrome, Edge	128+	✅ 지원됨
Chrome OS	Chrome, Edge	128+	✅ 지원됨
iOS / iPadOS	모든 브라우저(Safari)	iOS 18+	✅ 지원됨
macOS	Chrome, Edge	128+	✅ 지원됨
macOS	Safari	Safari 18 (macOS 15+)	✅ 지원됨
Ubuntu	Chrome, Edge	128+	✅ 지원됨
Windows	Chrome, Edge	128+	✅ 지원됨
모든 플랫폼	Firefox	지원 안 됨	⚠️ 폴백 사용

주요 사실:

Chrome 및 Edge: 버전 128(2024년 8월)에서 ROR 지원 추가
Safari: Safari 18에서 ROR 지원 추가, macOS 15 및 iOS 18에서 사용 가능(2024년 9월)
Firefox: 현재 ROR 미지원, 기능 감지 및 폴백 플로우 구현 필요

기능 감지 및 폴백#

오래된 브라우저나 Firefox를 지원해야 하는 애플리케이션의 경우, 폴백 전략을 구현하세요:

기능 감지: PublicKeyCredential.getClientCapabilities()를 사용하여 ROR 지원 여부 확인
식별자 우선 흐름: 사용자 이름/이메일 입력 요청, 사용자의 관련 rpID 조회 후 인증을 위해 적절한 오리진으로 리디렉션
점진적 성능 저하: ROR을 사용할 수 없는 경우 사용자가 도메인별로 별도의 패스키를 생성하도록 허용

데이터는 2025년 10월 기준 현재 지원 매트릭스를 기반으로 합니다.

9. Corbado가 도와드릴 수 있는 방법#

관련 오리진 요청을 구현하려면 여러 기술 팀 간의 신중한 조율과 WebAuthn 프로토콜에 대한 깊은 전문 지식이 필요합니다. Corbado의 패스키 도입 플랫폼은 다중 도메인 패스키 배포를 위한 엔터프라이즈급 솔루션을 제공하여 이러한 복잡성을 제거합니다.

9.1 간소화된 ROR 구현#

Corbado는 다음과 같은 방법으로 관련 오리진 요청의 기술적 복잡성을 처리합니다:

자동화된 구성: 우리 플랫폼은 적절한 보안 헤더와 JSON 형식을 갖춘 필수 .well-known/webauthn 파일을 자동으로 생성하고 호스팅합니다.
다중 도메인 대시보드: 전체 도메인 포트폴리오에 걸쳐 관련 오리진을 구성하기 위한 중앙 집중식 관리 인터페이스
검증 도구: ROR 구성이 모든 브라우저와 플랫폼에서 올바르게 작동하는지 확인하기 위한 내장 테스트 및 검증 기능

9.2 엔터프라이즈급 보안 및 규정 준수#

기술적 구현을 넘어 Corbado는 기업이 필요로 하는 보안 프레임워크를 제공합니다:

오리진 검증: 관련 도메인 남용을 방지하기 위한 clientDataJSON 오리진 자동 검증
감사 로깅: 규정 준수 및 보안 모니터링을 위해 모든 관련 도메인에 걸친 패스키 사용의 포괄적인 추적
사고 대응: 의심스러운 교차 도메인 인증 시도에 대한 실시간 경고 및 자동화된 대응

9.3 마이그레이션 및 통합 지원#

기존 패스키 배포가 있는 조직을 위해 Corbado는 다음을 제공합니다:

레거시 마이그레이션 도구: 기존 rpID 구성의 자동 분석 및 마이그레이션 경로 추천
식별자 우선 흐름: 전환 기간 동안 복잡한 다중 rpID 시나리오를 처리하는 사전 구축된 로그인 구성 요소
API 통합: 기존 인증 인프라와 원활하게 통합되는 RESTful API 및 SDK

9.4 시작하기#

귀사를 위해 관련 오리진 요청을 구현할 준비가 되셨나요? Corbado의 전문가 팀이 전체 디지털 생태계에 걸쳐 통합된 패스키 경험을 설계하고 배포하는 데 도움을 드릴 수 있습니다. 특정 요구 사항과 일정에 대해 논의하려면 저희 솔루션 팀에 문의하세요.

10. 결론: 다중 도메인 패스키를 위한 원활한 미래#

패스키의 약속은 사용자에게 더 안전하면서도 현저하게 더 간단한 미래를 제공하는 능력에 있습니다. 그러나 이 미래가 전 세계적인 규모로 현실이 되려면, 표준은 현대 디지털 브랜드의 아키텍처적 복잡성을 수용해야 합니다. 엄격하게 도메인에 바인딩된 패스키로 인해 발생하는 마찰은 다각적인 온라인 존재감을 가진 조직의 채택에 있어 중요한 장애물이었습니다.

WebAuthn 관련 오리진 요청은 이 문제에 대한 표준화되고 안전하며 우아한 해결책을 제공합니다. 단일 패스키가 신뢰할 수 있는 관련 도메인 집합에서 원활하게 작동하도록 허용함으로써, ROR은 사용자 혼란과 불만의 주요 원인을 제거합니다.

이 가이드는 WebAuthn 관련 오리진 요청을 구현하기 위한 다섯 가지 중요한 질문을 다루었습니다:

왜 패스키는 여러 도메인에서 작동하지 않을까요? WebAuthn의 오리진 바인딩 보안 모델은 피싱을 방지하기 위해 패스키를 특정 도메인에 암호학적으로 잠그지만, 이는 브랜드가 다른 국가 TLD와 같은 여러 도메인에서 운영될 때 마찰을 일으킵니다.
관련 오리진 요청은 기술적으로 어떻게 작동하나요? ROR은 표준화된 .well-known/webauthn 파일을 사용하여 검증 가능한 관련 도메인 허용 목록을 생성하며, 브라우저는 보안 HTTPS 페치 프로세스를 통해 교차 도메인 패스키 사용을 검증할 수 있습니다.
ROR을 구현하려면 무엇이 필요한가요? 구현에는 .well-known/webauthn 매니페스트 파일의 서버 측 구성과 모든 관련 오리진에서 일관되게 공유 rpID를 사용하기 위한 클라이언트 측 조율이 필요합니다.
언제 연동 로그인 대신 ROR을 선택해야 할까요? 공유 사용자 데이터베이스를 가진 관련 도메인 전반의 통합된 브랜드 경험에는 ROR을 사용하고, 별개의 애플리케이션 간의 진정한 SSO나 5개 레이블 제한을 초과할 때는 OIDC/SAML을 사용하세요.
브라우저 호환성 및 보안 고려 사항은 어떻게 처리하나요? ROR은 Chrome/Edge 128+, macOS 15+의 Safari, iOS 18+의 주요 브라우저에서 지원되며, 오래된 브라우저를 위한 폴백 전략은 식별자 우선 흐름을 통해 사용할 수 있습니다.

핵심 요약#

기술 팀과 제품 리더에게 필수적인 사항은 다음과 같습니다:

ROR은 국가별 TLD가 다르거나 대체 브랜딩을 사용하는 경우와 같이 여러 도메인에 걸쳐 있는 단일 논리적 애플리케이션에 대해 통합된 패스키 경험을 가능하게 합니다.
구현에는 조율된 노력이 필요합니다. 서버 측 .well-known/webauthn 파일은 기본 rpID의 도메인에 게시되어야 하며, 모든 클라이언트 측 애플리케이션은 동일한 공유 rpID를 사용하도록 구성되어야 합니다.
ROR 사용 결정은 전략적인 것입니다. 특정 사용 사례에 훌륭한 도구이지만, 특히 이질적인 애플리케이션 간의 진정한 싱글 사인온(Single Sign-On) 시나리오에서는 보다 전통적인 연동 로그인 아키텍처(OIDC/SAML)와 비교하여 신중하게 고려해야 합니다.

관련 오리진 요청과 같은 기능은 비밀번호 없는 운동의 지속적인 추진력에 필수적입니다. 이는 표준 기관이 실제 구현 문제를 해결하려는 의지를 보여주며, 패스키의 이점인 비교할 수 없는 보안과 손쉬운 사용자 경험이 가장 크고 복잡한 조직에도 접근 가능하도록 보장합니다. 이 기능이 보편적인 브라우저 지원을 받게 되면, 진정으로 글로벌하고 비밀번호 없는 인터넷으로 가는 마지막 장벽을 허무는 데 중요한 역할을 할 것입니다.