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

Maud Nalpas
Maud Nalpas

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

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

RP ID는 패스키가 모든 위치에서 인증하면 다음에 대한 문제가 발생합니다.

  • 여러 도메인이 있는 사이트: 사용자가 동일한 패스키를 사용하여 여러 국가별 도메인 (예: example.com, example.co.uk)은 동일한 회사에서 관리합니다.
  • 브랜드 도메인: 사용자는 여러 영역에서 동일한 사용자 인증 정보를 한 브랜드에서 사용하는 여러 도메인 (예: acme.comacmerewards.com).
  • 모바일 앱: 모바일 앱에는 자체 도메인이 없는 경우가 많으므로 가장 까다롭습니다

ID 제휴를 기반으로 하는 해결 방법과 iframe을 기반으로 하는 해결 방법이 있지만 경우에 따라 불편할 수 있습니다. 관련 오리진 요청 혜택 해결책이 될 수 있습니다

솔루션

다음으로 바꿉니다. 관련 오리진 요청, 웹사이트에서 RP ID를 사용할 수 있는 출처를 지정할 수 있습니다.

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

관련 출처 요청을 사용하려면 특정 URL https://{RP ID}/.well-known/webauthn example.com님이 다음을 원하는 경우 추가 출처에서 RP ID로 사용하도록 허용하는 경우 파일 위치: https://example.com/.well-known/webauthn:

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

다음번에 이러한 사이트에서 패스키 생성을 요청할 때 (navigator.credentials.create) 또는 인증 (navigator.credentials.get) example.com를 RP ID로 사용하는 경우 브라우저에 RP ID가 요청한 출처가 일치하지 않습니다 브라우저에서 관련 출처를 지원하는 경우 먼저 webauthn 파일이 https://{RP ID}/.well-known/webauthn에 있습니다. 파일이 있는 경우 브라우저에서는 요청을 보낸 출처가 파일에서 참조됩니다. 이 경우 패스키 생성 또는 인증 단계로 진행됩니다. 브라우저에서 관련 출처 요청을 지원하지 않으면 SecurityError이 발생합니다.

브라우저 지원

다음 데모에서는 https://ror-1.glitch.mehttps://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-1ror-2 모두 패스키를 생성하거나 패스키로 인증할 때 ror-1.glitch.me를 RP ID로 사용합니다.
또한 이러한 사이트 전반에 공유 패스키 데이터베이스를 구현했습니다.

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

  • RP ID가 ror-2가 아닌 ror-1이더라도 ror-2에서 패스키를 생성하고 패스키로 인증할 수 있습니다.
  • ror-1 또는 ror-2에서 패스키를 만들면 ror-1ror-2 모두에서 패스키로 인증할 수 있습니다. ror-2ror-1를 RP ID로 지정하므로 이러한 사이트에서 패스키 생성 또는 인증 요청을 하면 ror-1에서 요청하는 것과 같습니다. RP ID는 요청을 출처에 연결하는 유일한 요소입니다.
  • ror-1 또는 ror-2에서 패스키를 만들면 Chrome이 ror-1ror-2 모두에서 자동 입력할 수 있습니다.
  • 이러한 사이트에서 생성된 사용자 인증 정보의 RP ID는 ror-1입니다.
<ph type="x-smartling-placeholder">Chrome에서 두 사이트 모두 자동 완성됩니다.</ph> <ph type="x-smartling-placeholder">
</ph> 관련 출처 요청 덕분에 사용자는 ror-1 및 ror-2에서 동일한 패스키 사용자 인증 정보를 사용할 수 있습니다. Chrome에서 사용자 인증 정보를 자동으로 완성합니다.

코드 보기:

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

사용자가 모든 기기에서 동일한 패스키로 로그인할 수 있도록 하려면 site-1site-2는 이러한 사용자 간에 공유되는 계정 데이터베이스를 구현합니다. 알 수 있습니다.

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

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

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

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

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

이 목록의 각 요소는 eTLD + 1 라벨을 추출하도록 처리됩니다. 예를 들어 example.co.ukexample.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 파일을 제공합니다.

예를 들어 익스프레스는 다음과 같습니다.

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

여기에서는 익스프레스 res.json를 사용하며, 이는 이미 올바른 content-type ('application/json');

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

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

  • 사용자 인증 정보 생성 시:
    • 사용자 인증 정보 생성 시 site-1.com를 RP ID로 설정합니다. navigator.credentials.create에 전달되는 options 프런트엔드 호출이며 일반적으로 서버 측에서 생성됩니다.
    • 사용자 인증 정보를 실행할 때 site-1.com를 예상 RP ID로 설정합니다. 확인 과정을 거쳐야 합니다.
  • 인증 시:
    • 인증 options에서 site-1.com를 RP ID로 설정합니다. navigator.credentials.get 프런트엔드 호출에 전달되는 서버 측에서 생성됩니다
    • site-1.com를 사용자 인증 정보 확인을 실행할 때 사용자 인증 정보를 제공합니다.

문제 해결

Chrome의 오류 메시지 팝업
사용자 인증 정보 생성 시 Chrome에 오류 메시지 표시 이 오류는 `.well-known/webauthn` 파일을 `https://{RP ID}/.well-known/webauthn`에서 찾을 수 없는 경우에 발생합니다.
Chrome의 오류 메시지 팝업 <ph type="x-smartling-placeholder">
</ph> 사용자 인증 정보 생성 시 Chrome에 오류 메시지 표시 이 오류는 `.well-known/webauthn` 파일을 찾을 수 있지만 사용자 인증 정보를 만들려는 출처가 나열되지 않은 경우에 발생합니다.

기타 고려사항

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

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

사이트 간 비밀번호 공유

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

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

이는 사이트 개발자의 범위를 벗어나는 것이지만, RP ID는 사용자 에이전트 또는 사용자 인증 정보 관리자입니다. 대신 사용자 에이전트와 사용자 인증 정보는 관리자는 사용자에게 사용자 인증 정보가 사용된 위치를 표시해야 합니다. 이 변경사항 시간이 걸릴 수 있습니다 임시 해결 방법은 현재 웹사이트와 원래 등록 사이트를 모두 표시하는 것입니다.