이 페이지는 Cloud Translation API를 통해 번역되었습니다.

관련 출처 요청을 통해 사이트 전반에서 패스키 재사용 허용

Maud Nalpas

관련 출처 요청이 해결하는 문제

패스키는 특정 웹사이트에 연결되며 패스키가 생성된 웹사이트에서만 로그인하는 데 사용할 수 있습니다.

이는 신뢰 당사자 ID (RP ID)에 지정되며, example.com 도메인에 대해 생성된 패스키의 경우 www.example.com 또는 example.com일 수 있습니다.

RP ID는 패스키가 모든 곳에서 인증을 위한 단일 사용자 인증 정보로 사용되는 것을 방지하지만 다음과 같은 문제는 발생합니다.

여러 도메인이 있는 사이트: 사용자가 동일한 회사에서 관리하는 여러 국가별 도메인(예: example.com, example.co.uk)에서 동일한 패스키를 사용하여 로그인할 수 없습니다.
브랜드 도메인: 사용자는 단일 브랜드에서 사용하는 여러 도메인(예: acme.com 및 acmerewards.com)에서 동일한 사용자 인증 정보를 사용할 수 없습니다.
모바일 앱: 모바일 앱에는 자체 도메인이 없는 경우가 많아 사용자 인증 정보 관리가 어렵습니다.

ID 제휴를 기반으로 하는 해결 방법과 iframe을 기반으로 하는 해결 방법이 있지만 경우에 따라 불편할 수 있습니다. 관련 출처 요청에서 해결 방법을 제공합니다.

솔루션

관련 출처 요청을 사용하면 웹사이트에서 RP ID를 사용할 수 있는 출처를 지정할 수 있습니다.

이렇게 하면 사용자가 운영하는 여러 사이트에서 동일한 패스키를 재사용할 수 있습니다.

관련 출처 요청을 사용하려면 특정 URL https://{RP ID}/.well-known/webauthn에서 특수 JSON 파일을 제공해야 합니다. example.com가 추가 출처에서 이를 RP ID로 사용하도록 허용하려면 https://example.com/.well-known/webauthn:에서 다음 파일을 제공해야 합니다.

{
    "origins": [
        "https://example.co.uk",
        "https://example.de",
        "https://example-rewards.com"
    ]
}

다음에 이러한 사이트 중 하나에서 example.com를 RP ID로 사용하는 패스키 생성(navigator.credentials.create) 또는 인증(navigator.credentials.get)을 호출하면 브라우저는 요청 출처와 일치하지 않는 RP ID를 감지합니다. 브라우저가 관련 출처 요청을 지원하면 먼저 https://{RP ID}/.well-known/webauthn에서 webauthn 파일을 찾습니다. 파일이 있으면 브라우저는 요청을 실행하는 출처가 해당 파일의 허용 목록에 있는지 확인합니다. 패스키 생성 또는 인증 단계로 진행됩니다. 브라우저가 관련 출처 요청을 지원하지 않으면 SecurityError이 발생합니다.

브라우저 지원

Chrome: Chrome 128부터 지원됩니다.
Safari: macOS 15 베타 3부터 지원되며 모바일 iOS 18 베타 3에서도 지원됩니다.
Firefox: 위치 대기 중

관련 출처 요청을 설정하는 방법

다음 데모에서는 https://ror-1.glitch.me 및 https://ror-2.glitch.me라는 두 사이트의 예를 사용합니다.
사용자가 두 사이트 모두에서 동일한 패스키로 로그인할 수 있도록 하기 위해 관련 출처 요청을 사용하여 ror-2.glitch.me가 ror-1.glitch.me를 RP ID로 사용할 수 있도록 허용합니다.

데모

https://ror-2.glitch.me은 ror-1.glitch.me을 RP ID로 사용하기 위해 관련 출처 요청을 구현하므로 ror-1와 ror-2 모두 패스키를 만들거나 패스키로 인증할 때 ror-1.glitch.me를 RP ID로 사용합니다.
또한 이러한 사이트 전반에 공유 패스키 데이터베이스를 구현했습니다.

다음 사용자 환경을 살펴봅니다.

RP ID가 ror-2가 아닌 ror-1이더라도 ror-2에서 패스키를 생성하고 패스키로 인증할 수 있습니다.
ror-1 또는 ror-2에서 패스키를 만들면 ror-1와 ror-2에서 모두 패스키로 인증할 수 있습니다. ror-2는 ror-1를 RP ID로 지정하므로 이러한 사이트에서 패스키 생성 또는 인증 요청을 하는 것은 ror-1에서 요청하는 것과 같습니다. RP ID는 요청을 출처에 연결하는 유일한 요소입니다.
ror-1 또는 ror-2에서 패스키를 만들면 Chrome에서 ror-1와 ror-2 모두에서 패스키를 자동 완성할 수 있습니다.
이러한 사이트에서 생성된 사용자 인증 정보의 RP ID는 ror-1입니다.

Chrome에서 두 사이트 모두 자동 완성됩니다. — 관련 출처 요청 덕분에 사용자는 ror-1과 ror-2에서 동일한 패스키 사용자 인증 정보를 사용할 수 있습니다. Chrome에서 사용자 인증 정보도 자동 완성합니다.

코드 보기:

ror-1 코드베이스에서 설정된 ./well-known/webauthn 파일을 참고하세요.
ror-2 코드베이스에서 RP_ID_ROR가 발생하는 위치를 확인하세요.

1단계: 공유 계정 데이터베이스 구현

사용자가 site-1와 site-2에서 동일한 패스키로 로그인할 수 있도록 하려면 두 사이트에서 공유되는 계정 데이터베이스를 구현하세요.

2단계: site-1에서 .well-known/webauthn JSON 파일 설정

먼저 site-2.com가 site-1.com를 RP ID로 사용할 수 있도록 site-1.com를 구성합니다. 이렇게 하려면 webauthn JSON 파일을 만듭니다.

{
    "origins": [
        "https://site-2.com"
    ]
}

JSON 객체에는 값이 웹 출처를 포함하는 문자열 배열인 origins라는 키가 포함되어야 합니다.

중요한 제한사항: 최대 5개의 라벨

이 목록의 각 요소는 eTLD + 1 라벨을 추출하기 위해 처리됩니다. 예를 들어 example.co.uk 및 example.de의 eTLD + 1 라벨은 모두 example입니다. 하지만 example-rewards.com의 eTLD + 1 라벨은 example-rewards입니다. Chrome에서는 라벨을 최대 5개까지 지정할 수 있습니다.

3단계: site-1에서 .well-known/webauthn JSON 제공

그런 다음 site-1.com/.well-known/webauthn 아래에 JSON 파일을 제공합니다.

예를 들어 express에서 다음과 같이 작성할 수 있습니다.

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

여기서는 이미 올바른 content-type('application/json')를 설정하는 express res.json를 사용합니다.

4단계: site-2에서 원하는 RP ID 지정

site-2 코드베이스에서 필요한 모든 위치의 site-1.com를 RP ID로 설정합니다.

사용자 인증 정보 생성 시:
- 사용자 인증 정보 생성 options에서 navigator.credentials.create 프런트엔드 호출에 전달되고 일반적으로 서버 측에서 생성되는 site-1.com를 RP ID로 설정합니다.
- site-1.com를 데이터베이스에 저장하기 전에 사용자 인증 정보 확인을 실행하므로 예상 RP ID로 설정합니다.
인증 시:
- site-1.com를 navigator.credentials.get 프런트엔드 호출에 전달되고 일반적으로 서버 측에서 생성되는 인증 options의 RP ID로 설정합니다.
- 사용자를 인증하기 전에 사용자 인증 정보를 실행할 때 서버에서 확인할 예상 RP ID로 site-1.com를 설정합니다.

문제 해결

Chrome의 오류 메시지 팝업 — 사용자 인증 정보 생성 시 Chrome에 오류 메시지가 표시됨 이 오류는 `https://{RP ID}/.well-known/webauthn` 에서 `.well-known/webauthn` 파일을 찾을 수 없는 경우에 발생합니다.

기타 고려사항

사이트 및 모바일 앱에서 패스키 공유

관련 원본 요청을 사용하면 사용자가 여러 사이트에서 패스키를 재사용할 수 있습니다. 사용자가 웹사이트 및 모바일 앱에서 패스키를 재사용할 수 있도록 하려면 다음 기법을 사용하세요.

Chrome: 디지털 애셋 링크 디지털 애셋 링크 지원 추가에서 자세히 알아보세요.
Safari: 연결된 도메인

여러 사이트에서 비밀번호 공유

관련 출처 요청을 사용하면 사용자가 여러 사이트에서 패스키를 재사용할 수 있습니다. 사이트 간에 비밀번호를 공유하는 솔루션은 비밀번호 관리자에 따라 다릅니다. Google 비밀번호 관리자의 경우 디지털 애셋 링크 를 사용합니다. Safari는 다른 시스템을 사용합니다.

인증 관리자 및 사용자 에이전트의 역할

이는 사이트 개발자의 범위를 벗어나지만 장기적으로 RP ID는 사용자 에이전트 또는 사용자가 사용 중인 사용자 인증 정보 관리자에서 사용자에게 표시되는 개념이 아니어야 합니다. 대신 사용자 에이전트와 사용자 인증 정보 관리자는 사용자 인증 정보가 사용된 위치를 사용자에게 표시해야 합니다. 이 변경사항을 구현하는 데 시간이 걸립니다. 임시 해결책은 현재 웹사이트와 원래 등록 사이트를 모두 표시하는 것입니다.