관련 출처 요청으로 해결되는 문제
패스키는 특정 웹사이트에 연결되며 패스키가 생성된 웹사이트에서 로그인하는 데만 사용할 수 있습니다.
이는 신뢰 당사자에서 지정됩니다.
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
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
이 발생합니다.
브라우저 지원
- 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 자동 완성](https://web.dev/static/articles/webauthn-related-origin-requests/image/chrome-autofill.jpg?hl=ko)
코드 보기:
- 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입니다. 이렇게 하려면 webauthn JSON 파일을 만듭니다.
{
"origins": [
"https://site-2.com"
]
}
JSON 객체에는 값이 1의 배열인 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 파일을 제공합니다.
예를 들어 익스프레스는 다음과 같습니다.
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로 설정합니다.
- 사용자 인증 정보 생성 시:
<ph type="x-smartling-placeholder">
- </ph>
- 사용자 인증 정보 생성 시
site-1.com
를 RP ID로 설정합니다.navigator.credentials.create
에 전달되는options
프런트엔드 호출이며 일반적으로 서버 측에서 생성됩니다. - 사용자 인증 정보를 실행할 때
site-1.com
를 예상 RP ID로 설정합니다. 확인 과정을 거쳐야 합니다.
- 사용자 인증 정보 생성 시
- 인증 시:
<ph type="x-smartling-placeholder">
- </ph>
- 인증
options
에서site-1.com
를 RP ID로 설정합니다.navigator.credentials.get
프런트엔드 호출에 전달되는 서버 측에서 생성됩니다 site-1.com
를 사용자 인증 정보 확인을 실행할 때 사용자 인증 정보를 제공합니다.
- 인증
문제 해결
<ph type="x-smartling-placeholder">![Chrome의 오류 메시지 팝업](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-not-found.jpg?hl=ko)
![Chrome의 오류 메시지 팝업](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-incorrect.jpg?hl=ko)
기타 고려사항
사이트 및 모바일 앱에서 패스키 공유하기
관련 오리진 요청을 통해 사용자는 여러 기기 간에 패스키를 재사용할 수 있음 사이트를 참조하세요. 사용자가 웹사이트 및 모바일 앱에서 패스키를 재사용할 수 있도록 하려면 다음 안내를 따르세요. 다음 기법을 사용하세요.
- Chrome: 디지털 애셋 링크를 클릭합니다. 자세히 알아보기: 디지털 애셋 링크 지원을 추가합니다.
- Safari의 경우: 연결된 도메인.
사이트 간 비밀번호 공유
관련 출처 요청을 사용하면 사용자가 사이트 전체에서 패스키를 재사용할 수 있습니다. 비밀번호 관리자에 따라 사이트 간에 비밀번호를 공유하기 위한 솔루션이 다릅니다. Google 비밀번호 관리자의 경우 디지털 애셋 링크 를 사용합니다. Safari는 다른 시스템을 사용합니다.
인증 관리자 및 사용자 에이전트의 역할
이는 사이트 개발자의 범위를 벗어나는 것이지만, RP ID는 사용자 에이전트 또는 사용자 인증 정보 관리자입니다. 대신 사용자 에이전트와 사용자 인증 정보는 관리자는 사용자에게 사용자 인증 정보가 사용된 위치를 표시해야 합니다. 이 변경사항 시간이 걸릴 수 있습니다 임시 해결책은 기존 웹사이트와 원래 등록 사이트가 모두 포함됩니다.