WebAuthn 및 패스키에서 신뢰 당사자 ID (RP ID)는 도메인 이름으로 사용자 인증 정보의 범위를 지정합니다. 패스키를 만들면 브라우저가 특정 RP ID에 연결합니다. 그러면 브라우저에서 해당 ID의 범위와 일치하지 않거나 범위에 속하지 않는 도메인에서 해당 패스키를 사용하지 못하도록 합니다. RP ID를 올바르게 정의하면 하위 도메인, 교차 사이트 출처, 퍼스트 파티 모바일 앱 전반에서 원활한 패스키 환경을 보장할 수 있습니다.
RP ID 기본사항
신뢰 당사자 ID (RP ID)는 서비스 또는 웹사이트를 식별하는 고유한 문자열입니다. RP ID는 도메인 문자열이어야 합니다. eTLD+1 이상인 경우 정확한 현재 호스트 이름 또는 더 광범위한 상위 도메인일 수 있습니다. IP 주소와 공개 서픽스 (eTLD)는 RP ID로 사용할 수 없습니다.
예를 들어 https://www.example.com에서 서버를 호스팅하는 경우 특정 요구사항에 따라 example.com 또는 www.example.com를 RP ID로 사용할 수 있습니다.
다음 표에서는 출처 호스트에 따라 허용되는 RP ID의 예를 보여줍니다.
| 원본 호스트 | 허용되는 RP ID (eTLD+1) |
|---|---|
https://login.example.com |
example.com 또는 login.example.com |
https://example.com:8080 |
example.com (포트 번호는 제외됨) |
https://mobile.example.co.jp |
example.co.jp 또는 mobile.example.co.jp |
https://sub.project.org.uk |
project.org.uk 또는 sub.project.org.uk |
https://user.github.io |
user.github.io (github.io이 eTLD임) |
https://myapp.pages.dev |
myapp.pages.dev (pages.dev이 eTLD임) |
http://localhost |
localhost (HTTPS 요구사항의 예외) |
브라우저는 패스키를 만들 때 암호화 방식으로 패스키를 RP ID에 연결합니다. 사용자 인증 정보를 사용하려면 인증 요청의 출처가 해당 RP ID와 일치해야 합니다.
eTLD+1을 RP ID로 사용하면 관련 하위 도메인에서 패스키가 작동합니다. 예를 들어 https://login.example.com 및 https://shop.example.com에 example.com RP ID가 작동합니다. login.example.com와 같은 더 구체적인 RP ID는 정확한 출처에서는 작동하지만 https://shop.example.com에서는 작동하지 않습니다.
교차 사이트 컨텍스트의 RP ID
서비스가 여러 eTLD+1 (예: example.com 및 example.co.jp)에 걸쳐 있는 경우 교차 사이트 구성입니다. 표준 RP ID는 교차 사이트 설정을 지원하지 않습니다.
서로 다른 사이트 간에 패스키를 공유하려면 관련 출처 요청(ROR)을 사용하세요. ROR을 사용하면 클라이언트 (브라우저)가 서로 다른 출처를 동일한 논리적 서비스의 일부로 인식하므로 서로 다른 사이트 간에 패스키를 공유할 수 있습니다.
ROR 요구사항:
- RP ID 하나 선택: RP ID를 하나 선택하여 모든 사이트에서 사용해야 합니다.
- 구성 파일 호스팅: 기본 RP ID 도메인은 승인된 출처를 나열하는 구성 파일을
/.well-known/webauthn에 호스팅해야 합니다. - 일관성 유지: 사용자가
https://www.example.co.jp에 있더라도 WebAuthn 호출의rpId는 생성 및 인증 시 모두 기본값 (예:example.com)이어야 합니다.
RP ID example.com의 ROR 예: https://example.com/.well-known/webauthn
{
"origins": [
"https://www.example.co.jp",
"https://shop.example"
]
}
관련 출처 요청 구현 세부정보에 관한 자세한 내용은 관련 출처 요청으로 여러 사이트에서 패스키 재사용 허용을 참고하세요.
모바일 앱의 RP ID
모바일 애플리케이션은 웹 도메인과 연결하여 패스키를 사용할 수 있습니다. 이 관계를 설정하려면 서버에서 확인 파일을 호스팅해야 합니다.
Android: 디지털 애셋 링크
Android 인증 관리자는 앱과 연결하기 위해 RP ID 도메인에 디지털 애셋 링크(DAL) 파일이 필요합니다.
- 호스팅:
https://<RP ID>/.well-known/assetlinks.json에 파일을 호스팅합니다. - 확인:
clientDataJSON에서origin를 확인합니다. Android의 경우 이는android:apk-key-hash:<hash>와 같은 문자열입니다.
RP ID example.com (https://example.com/.well-known/assetlinks.json에 호스팅됨)의 예시 DAL
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.google.credentialmanager.sample",
"sha256_cert_fingerprints": [
"4F:20:47:1F:D9:9A:BA:96:47:8D:59:27:C2:C8:A6:EA:8E:D2:8D:14:C0:B6:A2:39:99:9F:A3:4D:47:3D:FA:11"
]
}
}
]
자세한 내용은 앱과 웹사이트 간 디지털 애셋 링크 구성을 참고하세요.
iOS: 연결된 도메인
Apple 플랫폼에서는 앱과 연결하기 위해 RP ID 도메인에 apple-app-site-association (AASA) 파일이 필요합니다.
- AASA 파일: 호스트
https://<RP_ID>/.well-known/apple-app-site-association. - 권한: 앱 권한에
webcredentials:<app info>를 추가합니다.
RP ID example.com의 AASA 예:
https://example.com/.well-known/apple-app-site-association:
{
"webcredentials":
{
"apps": ["EXAMPLE123.com.example.passkey"]
}
}
자세한 내용은 Apple 개발자 문서의 패스키로 서비스에 연결하기를 참고하세요.
요약
RP ID는 사용자가 패스키에 액세스하는 위치를 결정합니다. 구현 시 다음 사항에 유의하세요.
- 계층 구조 및 하위 도메인: RP ID는 도메인 문자열 (eTLD+1 이상)이어야 합니다.
example.com과 같은 더 광범위한 도메인을 사용하면 모든 하위 도메인 (예:login.example.com및shop.example.com)에서 패스키가 작동합니다. - 크로스 사이트 솔루션: 여러 eTLD+1에 걸쳐 있는 서비스에는 관련 출처 요청 (ROR)을 사용합니다. 이를 위해서는 RP ID 하나와
/.well-known/webauthn의 구성 파일이 필요합니다. - 모바일 통합: Android의 경우
/.well-known/assetlinks.json에 있는 디지털 애셋 링크 (DAL) 파일을 사용하고 iOS의 경우/.well-known/apple-app-site-association에 있는 apple-app-site-association (AASA) 파일을 사용하여 웹사이트와 모바일 앱 간에 확인된 관계를 설정합니다.