교차 도메인 로그인 조각 모음

Eiji Kitamura

최신 비즈니스 아키텍처는 여러 개의 고유한 도메인에 걸쳐 있는 경우가 많습니다. 조직은 마케팅을 위한 brand.example, 핵심 제품을 위한 service-app.example, 고객 서비스를 위한 support-portal.example과 같이 다양한 기능을 위한 전용 환경을 유지합니다. 사용자가 이러한 속성을 탐색할 때 통합된 싱글 사인온(SSO) 환경을 제공하는 것이 이상적입니다. 하지만 엔지니어링팀은 단편화를 유발하는 임시 기술을 사용하여 이러한 도메인을 통합하는 경우가 많습니다. 이로 인해 비밀번호 관리자 자동 완성 흐름이 중단되고 패스키 도입이 지연되어 기본 제공 브라우저 사용자 인증 정보 관리가 중단됩니다.

서로 다른 조직 도메인 간의 교차 도메인 로그인 조각화를 보여주는 다이어그램
여러 웹 속성에서 교차 도메인 ID 단편화

동일한 계정이 여러 도메인에 걸쳐 있는 경우 사용자는 도메인이 동일한 조직에 속한다는 것을 인식하고 로그인할 때 동일한 사용자 인증 정보를 제공해야 합니다. 최악의 경우 사용자는 중복 계정을 만들거나 피싱 웹사이트에 비밀번호를 제공합니다.

메타데이터, 교차 출처 iframe, ID 제휴, 하위 도메인 통합과 같은 아키텍처 표준 및 솔루션을 사용하여 교차 도메인 ID 단편화를 해결하고 원활한 사용자 여정을 제공하는 방법을 알아보세요.

일반적인 해결 방법

조직은 여러 가지 기존 기술을 사용하여 교차 도메인 여정을 유지합니다. 이러한 방법은 일반적이지만 브라우저가 더 엄격한 개인 정보 보호 경계와 보안 표준을 적용함에 따라 구조적 장애물에 직면합니다.

CORS 가져오기 요청

도메인이 독립적으로 작동하는 경우 프런트엔드는 교차 출처 fetch() 요청에 의존하는 경우가 많으며, 이는 교차 출처 리소스 공유 (CORS) 를 사용하여 안전하게 허용할 수 있는 중앙 집중식 인증 API를 대상으로 합니다. 브라우저가 교차 사이트 쿠키를 차단하거나 제한하는 경우가 많으므로 개발자는 Set-Cookie 헤더에 의존하는 대신 JSON 페이로드 내에서 JSON 웹 토큰 (JWT)과 같은 인증 토큰을 반환하도록 이러한 API를 명시적으로 설계할 수 있습니다.

계정 데이터베이스 공유

복잡한 프런트엔드 통합 없이 백엔드에서 ID를 통합하려면 사용자 데이터 저장소를 중앙 집중화하면 됩니다. 여러 도메인이 동일한 데이터베이스에 대해 인증하지만 프런트엔드 로그인 환경은 별도로 유지됩니다. 이로 인해 사용자는 동일한 사용자 인증 정보를 사용한 도메인을 기억해야 하므로 사용자 환경이 저하됩니다.

분리된 로그인 문제

기술적 해결 방법으로 기본 기능을 구현할 수 있지만 원활한 여정을 제공하지는 못합니다. 분리된 로그인 흐름은 사용성과 보안을 모두 저해하는 마찰 지점을 도입합니다.

비밀번호 관리자 단편화

가장 큰 마찰 지점은 비밀번호 관리자의 중단입니다. 비밀번호 관리자는 저장된 사용자 인증 정보를 등록된 특정 출처에 바인딩합니다. 이렇게 하면 브라우저가 동일한 조직에 속하더라도 여러 도메인에서 자동 완성을 제공하지 못합니다.

사용자가 저장된 사용자 인증 정보가 있는 도메인에서 조직의 새 도메인으로 전환하면 비밀번호 관리자가 관계를 인식하지 못하고 자동 완성 메시지를 트리거하지 않습니다. 이로 인해 수동 입력 마찰이 발생합니다. 사용자는 사용자 인증 정보를 조회하거나 비밀번호를 재설정하거나 중복 계정을 만들어야 합니다.

비밀번호 관리자가 이러한 속성에서 신뢰할 수 없는 것으로 입증되므로 사용자는 이러한 사이트의 도구를 포기할 수 있습니다. 대신 다른 곳에서 재사용하기 위해 기억하기 쉬운 취약한 비밀번호를 만드는 경우가 많아 조직의 전반적인 보안이 저하됩니다.

피싱 게이트웨이

이 중단은 피싱 게이트웨이로 작동합니다. 비밀번호 관리자가 인식되지 않는 도메인에서 자동 완성을 거부하는 것은 기본 방어 메커니즘입니다. 사용자가 여러 URL에 사용자 인증 정보를 수동으로 입력하도록 요구하면 의도치 않게 사용자가 피싱 공격의 피해자가 되도록 학습하게 됩니다.

패스키 로드블록

패스키를 사용하면 마찰이 증가합니다. WebAuthn의 핵심 보안 아키텍처는 패스키를 지정된 신뢰 당사자 ID (RP ID)에 암호화 방식으로 엄격하게 바인딩합니다.

이로 인해 'RP ID 트랩'이 생성됩니다. 브라우저가 교차 도메인 액세스를 거부하므로 brand.example에 등록된 패스키는 service-app.example에서 사용할 수 없습니다. 사용자에게 모든 사이트에 대해 고유한 패스키를 등록하라는 메시지가 표시되지 않도록 하려면 이러한 속성을 단일 RP ID로 통합해야 합니다.

ID 연속성을 설정하려면 임시 로그인 통합에서 벗어나 인식된 아키텍처 표준을 채택해야 합니다.

  • 메타데이터 구성 파일 사용: 디지털 애셋 링크 및 관련 출처 요청과 같은 메타데이터 파일을 호스팅하여 암호화 신뢰 체인을 설정합니다. 이렇게 하면 여러 도메인과 모바일 앱에서 원활한 사용자 인증 정보 및 패스키 공유가 가능합니다. 이 접근 방식은 기존 웹 인프라의 복잡한 재설계가 필요하지 않은 ID 단편화에 대한 저비용의 자동 수정입니다.
  • 교차 출처 iframe 사용: 신뢰 당사자 내에 중앙 집중식 인증 출처를 iframe으로 삽입하여 여러 사이트에서 저장된 사용자 인증 정보와 패스키를 연결합니다. 이 접근 방식은 권한 정책 및 파티션 쿠키를 사용하여 CSP 및 교차 문서 메시징을 통해 엄격한 보안 경계를 유지하면서 원활한 인라인 로그인 환경을 지원합니다.
  • 표준 ID 제휴 따르기: OpenID Connect와 같은 업계 표준 프로토콜을 채택하여 전용 ID 공급업체 (IdP) 도메인에서 인증을 중앙 집중화합니다. 이렇게 하면 취약한 통합을 안정적이고 확장 가능한 퍼스트 파티 솔루션으로 대체하여 보안 리디렉션을 통해 로그인 여정을 공식화합니다.
  • 하위 도메인 통합: 공통 루트 아래의 하위 도메인으로 전환합니다. 이렇게 하면 와일드카드 쿠키를 통한 원활한 세션 공유와 등록 가능한 전체 도메인에서 패스키 연속성이 가능합니다. 많은 비밀번호 관리자가 공유 루트 도메인을 인식하고 관련 하위 도메인에서 저장된 사용자 인증 정보를 자동으로 제안할 수 있습니다.

메타데이터 구성 파일 사용

교차 도메인 ID의 주요 과제는 저장된 사용자 인증 정보의 단편화입니다. 비밀번호 관리자는 여러 도메인과 앱을 완전히 격리된 항목으로 취급하므로 한 속성에 저장된 사용자 인증 정보를 다른 속성에 자동 완성할 수 없습니다.

단편화를 해결하려면 웹사이트 구조를 변경하는 대신 비밀번호 관리자의 동작을 구성하면 됩니다. 조직은 특정 메타데이터 구성 파일을 호스팅하여 서로 다른 도메인과 애플리케이션이 동일한 조직에 속한다고 암호화 방식으로 주장할 수 있습니다. 이렇게 하면 운영체제, 브라우저, 비밀번호 관리자가 이 관계를 인식하고 ID 컨텍스트를 자동으로 연결하여 속성 간에 비밀번호와 패스키를 공유할 수 있습니다. 이 접근 방식은 웹 도메인이 통합된 경우에도 웹 기반 비밀번호와 패스키를 모바일 애플리케이션과 공유하는 데 필요합니다.

두 개의 서로 다른 구성 파일을 사용하여 여러 플랫폼과 생태계를 지원하는지 확인하세요.

여러 웹 도메인에서 패스키를 사용 설정하고 패스키 로드블록을 해결하기 위해 개발자는 관련 출처 요청 (ROR) 파일을 /.well-known/webauthn에서 호스팅할 수 있습니다. ROR은 동일한 패스키 RP ID를 안전하게 공유할 수 있는 승인된 도메인을 명시적으로 선언합니다. 관련 출처 요청에 관해 자세히 알아보려면 관련 출처 요청으로 사이트 전반에서 패스키 재사용 허용을 참고하세요.

  • 장점:
    • 최종 사용자를 위한 백그라운드 수정: 백그라운드에서 완전히 작동하므로 UX에 눈에 띄는 변경사항 없이 자동 완성 단편화를 자동으로 해결하고 OS 또는 브라우저 수준에서 패스키 연속성을 설정합니다.
    • 간단한 구현: 정적 JSON 파일 호스팅만 필요한 저비용 솔루션입니다. 백엔드 재설계 또는 복잡한 토큰 교환 로직이 필요하지 않습니다.
    • 기존 인프라 유지: 브랜드를 변경하거나 도메인을 통합하지 않고도 교차 도메인 여정을 크게 개선할 수 있습니다.
  • 단점:
    • 플랫폼 제약 조건: 플랫폼은 일반적으로 ROR에 엄격한 제한을 적용합니다. 예를 들어 Chrome은 단일 RP ID를 최대 5개의 연결된 eTLD+1 라벨로 제한합니다. 예를 들어 example.co.uk와 example.de는 동일한 example eTLD+1 라벨을 공유하지만 example-rewards.com은 별도의 example-rewards 라벨을 사용합니다. 광범위하거나 다양한 도메인 포트폴리오를 관리하는 경우 이러한 제한이 충분하지 않을 수 있습니다.
    • 운영 지연 시간 증가: 메타데이터 파일을 해결하려면 추가 네트워크 왕복이 필요하므로 브라우저가 인증을 처리할 때 지연 시간이 추가됩니다.
메타데이터 구성 파일이 서로 다른 도메인 간에 저장된 사용자 인증 정보를 공유하기 위한 트러스트 관계를 설정하는 방법을 보여주는 다이어그램
메타데이터 구성 파일을 사용하여 사용자 인증 정보 공유 사용 설정

교차 출처 iframe 사용

ROR 도메인 제한으로 인해 메타데이터 구성 파일 접근 방식을 사용할 수 없는 경우 교차 출처 iframe 요소는 교차 도메인 로그인 문제를 해결하는 강력한 표준 지원 경로를 제공합니다.

중앙 집중식 인증 출처 (예: auth.brand.example)를 신뢰 당사자 (예: brand.example) 내에 iframe으로 삽입하면 일반적인 양식 필드와 최신 API 모두와 상호작용할 수 있습니다. 비밀번호의 경우 브라우저의 사용자 인증 정보 관리자는 자동 완성 작업을 iframe의 출처 (auth.example)와 연결합니다. 이렇게 하면 사용자가 여러 사이트에서 중앙 집중식 사용자 인증 정보에 원활하게 액세스할 수 있습니다.

패스키의 경우 상위 창에서 권한 정책 프레임워크를 사용하여 iframe 액세스 권한을 부여해야 iframe이 WebAuthn을 호출하여 자체 출처의 RP ID에 대해 인증할 수 있습니다. 두 흐름 모두에서 CSP (콘텐츠 보안 정책)는 클릭재킹 및 교차 사이트 스크립팅과 같은 공격으로부터 사용자를 보호하는 데 유용합니다. 인증이 완료되면 파티션 쿠키로 세션이 설정되고 토큰이 상위 창으로 안전하게 다시 전송됩니다. postMessage()

  • 장점:
  • 단점:
    • 구현 제약 조건: 이 아키텍처에는 전문 엔지니어링이 필요합니다. 신뢰할 수 있는 상위 도메인으로 삽입을 제한하고 클릭재킹을 방지하기 위한 엄격한 CSP (frame-ancestors), WebAuthn API를 사용 설정하기 위한 HTTP 권한 정책 구성, 출처 스푸핑 및 CSRF 공격을 완화하기 위한 안전하고 검증된 교차 문서 메시징 (postMessage())이 필요합니다. iframe 내 패스키에서 권장사항을 알아보세요.
다른 사이트 간에 사용자 인증 정보와 패스키를 연결하기 위한 교차 출처 iframe 인증 흐름을 보여주는 다이어그램
교차 출처 iframe 인증 흐름

표준 ID 제휴 따르기

OpenID Connect와 같은 표준 ID 제휴를 채택하는 것은 계정 시스템을 유지하는 강력하고 지속 가능한 접근 방식입니다. 이 접근 방식은 인증 워크플로를 auth.brand.example과 같은 단일 전용 ID 공급업체 (IdP) 도메인으로 통합하여 공식화합니다. 확립된 프로토콜을 사용하면 애플리케이션이 사용자를 이 중앙 허브로 리디렉션하여 인증한 후 토큰 전송을 안전하게 수신하여 타겟 도메인에서 로그인을 완료합니다. 표준 제휴는 Google 계정으로 로그인과 같은 서드 파티 로그인과 자주 연결되지만 취약한 해결 방법을 대체하는 퍼스트 파티 솔루션으로 완전히 유효하고 널리 사용됩니다.

  • 장점:
    • 일반적인 엔지니어링 언어: 개발자는 특정 맞춤형 프로토콜을 학습하거나 유지할 필요가 없습니다. 확립된 업계 지식과 포괄적인 라이브러리를 사용할 수 있습니다. 패키지 솔루션도 있습니다.
    • 실전 테스트를 거친 안정성: 표준 프로토콜은 입증되고 안전하며 임시 구현보다 훨씬 취약하지 않습니다.
    • 간편한 확장: 조직에서 나중에 새로운 서드 파티 서비스와 제휴하거나 인수를 통합해야 하는 경우 ID 인프라가 이미 사용자 인증 정보를 제공할 수 있도록 준비되어 있습니다.
    • 일관된 UX: 사용자는 중앙 집중식 IdP 페이지를 브랜드의 권위 있는 출처로 인식하여 사용자 인증 정보가 언제 어디에서 필요한지 정확히 파악합니다.
  • 단점:
    • 높은 통합 오버헤드: 중앙 집중식 IdP를 개발하거나 중앙 집중식 IdP로 이전하면 통합 오버헤드가 높아지고 전문 보안 전문 지식이 필요합니다. 조직은 보안 리디렉션 기반 패턴을 지원하기 위해 연결된 모든 애플리케이션을 안전하게 리팩터링하는 데 투자해야 합니다.
    • 중단을 유발하는 리디렉션: 인증 흐름에서는 사용자를 출처 사이트에서 중앙 집중식 ID 공급업체 페이지로 리디렉션해야 하므로 원활한 인라인 로그인 환경이 방지됩니다.
중앙 집중식 인증을 위해 OpenID Connect와 같은 표준 프로토콜을 사용하는 ID 제휴 흐름을 보여주는 다이어그램
표준 ID 제휴 흐름

하위 도메인 통합

또 다른 구조적 접근 방식은 서로 다른 디지털 속성을 공통 등록 가능 루트 도메인 (eTLD+1) 아래로 이동하여 모든 도메인을 통합하는 것입니다. 여기에는 brand.example 및 service-app.example과 같은 별도의 도메인을 www.brand.example 및 service.brand.example과 같은 하위 도메인으로 전환하는 것이 포함됩니다.

  • 장점:
    • 통합 사용자 인증 정보 관리: 비밀번호 관리자는 루트 도메인을 인식하고 모든 하위 도메인을 단일 항목으로 취급하여 중복 메시지와 비밀번호 수동 입력을 없앨 수 있습니다.
    • 패스키 연속성: 개발자는 패스키 RP ID를 등록 가능한 도메인으로 기본적으로 범위 지정하여 연결된 모든 하위 도메인에서 패스키 지원을 즉시 확장할 수 있습니다. 이 경우 brand.example의 RP ID는 www.brand.example과 service.brand.example 모두에서 작동합니다.
    • 간편한 세션 공유: 도메인 구조를 통합하면 와일드카드 쿠키를 사용하여 단일 세션을 공유할 수 있습니다 (예: 쿠키를 Domain=brand.example로 범위 지정).
  • 단점:
    • 브랜딩 및 이전 제약 조건: 이 접근 방식은 조직에서 고유한 최상위 도메인을 요구하는 경우 잠재적인 브랜딩 제한을 부과할 수 있습니다. 이전은 복잡하며 HTTP 리디렉션을 신중하게 관리하고 기존 교차 출처 구성을 광범위하게 수정해야 합니다.
세션 및 패스키 공유를 지원하기 위해 등록 가능한 공통 루트 도메인 아래에 하위 도메인을 통합하는 방법을 보여주는 다이어그램
공통 루트 아래의 하위 도메인 통합

결론

ID 연속성을 달성하려면 임시 로그인 통합에서 확립된 인증 표준으로 전환해야 합니다. 제휴, 도메인 통합, iframe, 메타데이터와 같은 확립된 관행에 대해 비즈니스 제약 조건을 평가하면 UX 마찰을 없애고 생태계 전반에서 인증을 개선할 수 있습니다.

관련 주제에 관해 자세히 알아보려면 블로그를 팔로우하고 Chrome의 ID 포털에서 더 많은 리소스를 살펴보세요.