--- url: 'https://www.corbado.com/it/blog/webauthn-relying-party-id-rpid-passkey' title: 'WebAuthn Relying Party ID (rpID) e Passkey: Domini e App Native' description: 'Questo articolo spiega il WebAuthn Relying Party ID per l''autenticazione tramite passkey. Delinea la corretta configurazione, la corrispondenza dei domini e le configurazioni per le app native.' lang: 'it' author: 'Vincent Delitz' date: '2026-06-15T13:55:53.634Z' lastModified: '2026-06-16T06:05:45.694Z' keywords: 'relying party id, passkey, webauthn, app native, domini' category: 'WebAuthn Know-How' --- # WebAuthn Relying Party ID (rpID) e Passkey: Domini e App Native ## Key Facts - Il **Relying Party ID** è un dominio incorporato in ogni passkey. L'autenticazione fallisce se l'origine del browser non corrisponde, rendendo le passkey fortemente resistenti al phishing. - Il **RP ID** non deve essere presente nella **Public Suffix List** e la sua modifica invalida tutte le passkey esistenti. Usa il dominio principale come impostazione predefinita per evitare problemi futuri. - Le app iOS richiedono un file **apple-app-site-association** su `/.well-known/` sotto l'RP ID. Android richiede **assetlinks.json** nello stesso percorso. I nuovi file potrebbero richiedere fino a 24 ore per essere memorizzati nella cache. - Domini principali multipli necessitano delle **Related Origin Requests** tramite `.well-known/webauthn` per la condivisione delle passkey. Utilizza un singolo server WebAuthn con un RP ID per tutte le app, web e native. ## 1. Introduzione L'[autenticazione](https://www.corbado.com/it/blog/passkey-device-bound-vs-sincronizzate) tramite passkey sta rapidamente diventando la norma man mano che giganti della tecnologia come [TikTok](https://www.corbado.com/blog/tiktok-passkeys), GitHub, [WhatsApp](https://www.corbado.com/blog/whatsapp-passkeys), X (Twitter), [LinkedIn](https://www.corbado.com/blog/linkedin-passkeys) e Amazon le introducono o lo hanno già fatto. È evidente che il mondo della tecnologia stia riconoscendo l'importanza di un'[autenticazione](https://www.corbado.com/it/blog/passkey-device-bound-vs-sincronizzate) semplice e sicura. Oltre all'esperienza utente fluida dell'[autenticazione](https://www.corbado.com/it/blog/passkey-device-bound-vs-sincronizzate) con [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Touch ID o [Windows Hello](https://www.corbado.com/glossary/windows-hello), le passkey offrono una sicurezza senza pari rispetto ai metodi di autenticazione tradizionali come le password. Una delle caratteristiche distintive è la loro forte resistenza al [phishing](https://www.corbado.com/glossary/phishing). Un attacco di [phishing](https://www.corbado.com/glossary/phishing) è un attacco in cui la vittima viene ingannata per fornire credenziali a un sito falso che simula di essere il sito originale. Per esempio, immagina di ricevere un'e-mail da quella che sembra essere la tua banca, in cui ti viene chiesto di accedere. Clicchi sul link e il sito web sembra legittimo, quindi inserisci le tue credenziali e l'aggressore può utilizzarle per accedere al sito originale. Questo sta diventando un problema sempre più crescente nell'era digitale e persino grandi aziende come [Okta](https://www.darkreading.com/application-security/okta-flaw-involved-mgm-resorts-breach-attackers-claim) (un provider di autenticazione!) o [Retool](https://retool.com/blog/mfa-isnt-mfa/) sono state vittime di attacchi di spear-[phishing](https://www.corbado.com/glossary/phishing) (una forma speciale di phishing in cui le singole vittime vengono particolarmente prese di mira con trucchi di phishing molto personali), sottolineando la necessità di robuste misure di sicurezza. Al contrario, se usi una passkey e il sito è falso, la tua autenticazione fallirà. Questo perché le passkey sono legate ai domini per cui sono state create tramite il **Relying Party ID**. > Non puoi accedere con una passkey su nessun altro sito, rendendo le passkey fortemente > resistenti al phishing (sebbene nessun sistema sia assolutamente immune a tutti i > vettori di attacco). Questo meccanismo è integrato in WebAuthn, lo standard web alla base delle passkey per l'[autenticazione senza password](https://www.corbado.com/it/glossary/ctap). WebAuthn è basato su due cerimonie principali: la cerimonia di registrazione e quella di autenticazione. Durante la cerimonia di registrazione (iscrizione) viene creata una nuova passkey per un servizio online (la [Relying Party](https://www.corbado.com/glossary/relying-party)) tramite un'app web o nativa. In questo processo, il dominio (Relying Party ID) per il quale viene creata la passkey viene memorizzato nella passkey. Ciò consente alla cerimonia di autenticazione (login) di verificare se il servizio online (la [Relying Party](https://www.corbado.com/glossary/relying-party)), a cui appartiene l'app web o nativa, corrisponde al [Relying Party](https://www.corbado.com/glossary/relying-party) ID memorizzato nella passkey. Di seguito, vedremo in dettaglio come funziona questo processo di [corrispondenza del dominio](#what-relying-party-id) e come, in particolare, le app native vengono protette. ## 2. Cos'è il Relying Party ID? Il [**Relying Party ID**](https://www.w3.org/TR/webauthn-2/#relying-party-identifier) è essenzialmente un dominio memorizzato all'interno della passkey, garantendo che la passkey funzioni solo se l'URL del browser corrente (l'origine dell'utente che viene inviata automaticamente in ogni richiesta) vi corrisponde (vedi l'approccio per le app native [sotto](#integration-options-native-apps)). È un componente cruciale della specifica WebAuthn, che puoi approfondire [qui](https://www.w3.org/TR/webauthn-2/). Il Relying Party ID può essere il dominio principale (es. `corbado.com`) o un sottodominio (`auth.corbado.com`). Non puoi memorizzare il dominio principale come Relying Party ID se è presente nella public suffix list (trovi l'elenco e le librerie per il rilevamento dei suffissi pubblici [qui](https://publicsuffix.org/learn/)). Cambiare il Relying Party ID per un servizio online interromperà le passkey esistenti (eccezioni: il nuovo Relying Party ID è un sottodominio del vecchio Relying Party ID, o le Related Origin Requests sono configurate tramite `.well-known/webauthn` per consentire il riutilizzo della passkey tra domini correlati). Durante il processo di autenticazione, il Relying Party ID viene confrontato con l'URL del browser (origine dell'utente) per assicurarsi che corrispondano. Corrispondenza in questo senso significa che: - L'URL del browser (origine dell'utente) corrisponde esattamente al Relying Party ID OPPURE - L'URL del browser (origine dell'utente) è un sottodominio che corrisponde al Relying Party ID e il dominio genitore è registrabile (es. `com` o qualsiasi dominio sulla Public Suffix List non funzionano) Ecco uno schema dettagliato su quale _originalHost_ (seconda colonna) è autorizzato ad accedere al suo dominio genitore: ![relying party id table](https://www.corbado.com/website-assets/relying_party_id_table_4c98cc04f4.jpg) Di seguito, vedi la struttura analizzata di [**PublicKeyCredentialCreationOptions**](https://www.w3.org/TR/webauthn-2/#iface-pkcredential): ```json { "publicKey": { "attestation": "direct", "authenticatorSelection": { "authenticatorAttachment": "platform", "requireResidentKey": false, "userVerification": "preferred" }, "challenge": "qNqrdXUrk5S7dCM1MAYH3qSVDXznb-6prQoGqiACR10=", "excludeCredentials": [], "pubKeyCredParams": [ { "alg": -7, "type": "public-key" } ], "rp": { "id": "corbado.com", "name": "Corbado" }, "timeout": 30000, "user": { "displayName": "Corbado user", "id": "bz9ZDfHzOBLycqISTAdWwWIZt8VO-6mT3hBNXS5jwmY=" } } } ``` `rp` sta per Relying Party. Uno dei maggiori vantaggi del Relying Party ID è la prevenzione degli attacchi di phishing. Immagina il seguente scenario: 1. Un aggressore sviluppa un clone di [PayPal](https://www.corbado.com/blog/paypal-passkeys), un sito web falso che cerca di rubare le tue credenziali [PayPal](https://www.corbado.com/blog/paypal-passkeys) per accedere a tuo nome e inviare denaro al conto dell'aggressore. Questo sito web [PayPal](https://www.corbado.com/blog/paypal-passkeys) falso è ospitato sul dominio paybal.com (quindi spesso non è visibile a prima vista che si tratti di un dominio diverso). 2. Hai già creato una passkey in passato per il sito PayPal legittimo. Questa passkey ha memorizzato il Relying Party ID paypal.com. 3. Visiti il sito PayPal falso su paybal.com (poiché visiti questo sito, l'origine della tua richiesta è paybal.com\*) e il sito invia al tuo dispositivo (l'autenticatore) una sfida per il Relying Party ID `paypal.com` (qui cerca di ingannarti) e ti chiede di firmarla con la tua passkey per il Relying Party ID paypal.com. 4. Il tuo dispositivo (l'autenticatore) verifica se l'origine della richiesta (`paypal.com`) e il Relying Party ID che ha memorizzato nella passkey (`paypal.com`) corrispondono. 5. Poiché ovviamente non corrispondono, l'autenticazione fallisce e ti salva dal dare a un aggressore l'accesso al tuo conto PayPal. Il diagramma seguente illustra questo meccanismo di prevenzione del phishing. _Nel caso di un'app nativa, la gestione dell'origine differisce in base alla piattaforma: Su Android, l'origine è formattata come `android:apk-key-hash:`. Su iOS, l'origine web WebAuthn è l'origine web dell'RP (es. `https://paypal.com`). In entrambi i casi, la fiducia tra la tua app nativa e il server è verificata tramite il file di associazione corrispondente (vedi [sotto](#configuring-relying-party-native-apps)). Per informazioni dettagliate su come funziona la convalida dell'origine per le app native, consulta la nostra guida dedicata sulla convalida dell'origine WebAuthn per app native._ ## 3. Le Due Diverse Opzioni di Integrazione per le App Native Per implementare le passkey in un'[app nativa](https://www.corbado.com/it/blog/app-native-passkey), uno sviluppatore può decidere se aggiungerle tramite [WebView](https://www.corbado.com/blog/native-app-passkeys) o in modo nativo. Esaminiamo i vantaggi e gli svantaggi di entrambi gli approcci di seguito. ### 3.1 Integrazione Passkey tramite WebView ![Passkey Integration WebView (GitHub)](https://www.corbado.com/website-assets/650c601b1eb462e25702a870_android_webview_passkey_github_8bc81d9852.jpg) L'utilizzo di una **WebView**\* per integrare le passkey significa incorporare un browser web all'interno dell'[app nativa](https://www.corbado.com/it/blog/app-native-passkey) per gestire il processo di autenticazione. Questo approccio visualizza essenzialmente una pagina web all'interno dell'app, rendendo più facile riutilizzare i flussi di autenticazione basati sul web senza doverli riscrivere per la piattaforma nativa. Tuttavia, ci sono alcuni svantaggi. Le [WebView](https://www.corbado.com/blog/native-app-passkeys) potrebbero non supportare tutte le funzionalità delle passkey, e c'è un potenziale rischio di attacchi "man-in-the-middle" se non implementate in modo sicuro. Inoltre, l'esperienza utente potrebbe non essere fluida come con le integrazioni native e ci possono essere sfide nel mantenere un comportamento coerente tra diversi dispositivi e versioni del sistema operativo. _\*Ci sono diversi tipi di WebView: Su iOS (WKWebView, SFSafariViewController o SFAuthenticationSession / ASWebAuthenticationSession per flussi di autenticazione basati su OAuth/OpenID Connect) e Android (WebView, CCT-Chrome Custom Tabs). Consulta questo articolo del blog per i dettagli. Consigliamo di utilizzare SFSafariViewController/ ASWebAuthenticationSession e Chrome Custom Tabs nel contesto delle passkey se non desideri un'integrazione nativa._ ### 3.2 Integrazione Nativa Passkey ![Native Passkey Integration (Kayak)](https://www.corbado.com/website-assets/650c625cac723f594137a029_android_native_passkey_kayak_0f689e761e.jpg) L'**integrazione nativa** comporta la costruzione della funzionalità passkey direttamente nell'app [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) o [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) utilizzando API e librerie specifiche per la piattaforma. Questo metodo offre un'esperienza utente più fluida, in quanto non è necessario passare tra l'[app nativa](https://www.corbado.com/it/blog/app-native-passkey) e una [WebView](https://www.corbado.com/blog/native-app-passkeys). Consente inoltre prestazioni migliori e un aspetto più coerente. Dal punto di vista della sicurezza, l'integrazione nativa può offrire una maggiore protezione contro alcuni tipi di attacchi, specialmente se combinata con le funzionalità di sicurezza specifiche della piattaforma. Tuttavia, l'impegno di implementazione può essere maggiore, poiché gli sviluppatori devono scrivere e mantenere codice separato per ciascuna piattaforma (Android e [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)). Inoltre, rimanere aggiornati con le ultime specifiche delle passkey / WebAuthn potrebbe richiedere aggiornamenti dell'app più frequenti. Di seguito, ci concentreremo sull'integrazione nativa delle passkey. ## 4. Configurazione del Relying Party per App Native Le app native (es. app iOS o [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) presentano una sfida rispetto alle app web. A differenza delle app web, non c'è alcun URL del browser da confrontare con il Relying Party ID. Tuttavia, per garantire lo stesso livello di sicurezza, i domini sono collegati alle app native tramite **file di associazione**, in modo che venga stabilita la fiducia tra un dominio e un'app nativa. Questo è particolarmente importante se una passkey è stata creata su un'app web e dovrebbe essere utilizzata per lo stesso Relying Party ID su un'app nativa (e viceversa). ### 4.1 File di Associazione su iOS: apple-app-site-association iOS utilizza il file apple-app-site-association. Questo file contiene vari entitlement, ma per WebAuthn e le passkey, l'entitlement webcredentials è importante. ```json { "webcredentials": { "apps": ["9RF9KY88B2.com.corbado.passkeys"] } } ``` In webcredentials.apps, devi memorizzare il tuo Application Identifier Prefix (es. `9RF9KY77B2`) e il tuo Bundle Identifier (es. `com.corbado.passkeys`). Affinché le app native iOS funzionino, il file apple-app-site-association deve essere memorizzato nella directory `/.well-known` del Relying Party ID (`https:///.well-known/apple-app-site-association`). Vedi un esempio dal vivo [qui](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/apple-app-site-association). ### 4.2 File di Associazione su Android: assetlinks.json [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) utilizza il file `assetlinks.json`, che, come la sua controparte iOS, richiede configurazioni particolari per WebAuthn e le passkey. ```json [ { "relation": [ "delegate_permission/common.handle_all_urls", "delegate_permission/common.get_login_creds" ], "target": { "namespace": "android_app", "package_name": "com.corbado.passkeys.pub", "sha256_cert_fingerprints": [ "F8:90:4E:9A:99:01:71:75:25:38:D5:36:16:2D:B3:65:EB:41:51:D4:53:9A:72:BC:4B:56:C5:16:43:62:E2:C0" ] } } ] ``` Devi impostare i valori di relazione `delegate_permission/common.handle_all_urls` e `delegate_permission/common.get_login_creds`. Inoltre, devi aggiungere il nome del tuo pacchetto e l'impronta digitale SHA-256 del tuo certificato di firma. Per consentire la condivisione di una passkey tra un'app nativa e un'app web, devi aggiungere due voci. Una per il namespace web e una per il namespace android_app. Vedi un esempio dal vivo [qui](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/assetlinks.json). Affinché le app Android funzionino, il file assetlinks.json deve essere memorizzato nella directory `/.well-known` del Relying Party ID `https:///.well-known/assetlinks.json` - in modo molto simile a iOS). Consulta questo articolo del blog per vedere un'implementazione di esempio che condivide le passkey tra un'[app nativa Android](https://www.corbado.com/it/blog/app-native-passkey) / iOS e un'app web. ## 5. Stabilire la Fiducia tra un'App Nativa e un'App Web ### 5.1 iOS Il processo per stabilire la fiducia tra un'app iOS e un'app web è il seguente: 1. Lo sviluppatore dell'app iOS deve specificare un elenco di domini che desidera associare all'app nativa. Questi domini sono codificati negli entitlement dell'app iOS, es.: - webcredentials:auth.Corbado.com - webcredentials:\*.Corbado.com 2. Ogni volta che l'app iOS viene installata o aggiornata, iOS scaricherà il file apple-app-site-association per ciascuna voce dell'elenco degli entitlement dell'app iOS. 3. Quando viene creata una credenziale (es. passkey) all'interno di un'app iOS, l'app iOS convalida se il dominio del server della relying party è associato all'app iOS verificando i seguenti due aspetti: - Esiste un file `apple-app-site-association` per questo dominio del server della relying party sul dispositivo? - L'app iOS è elencata in quel file `apple-app-site-association`? Se, e solo se, entrambe le domande hanno esito positivo, una passkey può essere creata all'interno dell'app iOS. ### 5.2 Android Il processo per stabilire la fiducia tra un'app Android e un'app web è il seguente: 1. Lo sviluppatore dell'app Android deve specificare un elenco di domini che desidera associare all'app Android. Questi domini sono memorizzati come target con il namespace web nel file assetlinks.json. Per dichiarare che le app Android e le app web condividono le credenziali, è necessario specificare `delegate_permission/common.get_login_creds`. Trova i dettagli [qui](https://developer.android.com/training/sign-in/passkeys#add-support-dal). 2. Se una passkey viene creata all'interno dell'app Android, l'app Android convalida se il Relying Party ID è associato all'app Android verificando il file `assetlinks.json`: - Esiste un file `assetlinks.json` per questo Relying Party ID su `https://./well-known/assetlinks.json` - L'app Android è definita correttamente come target. 3. Se, e solo se, entrambe le domande hanno esito positivo, una passkey può essere creata all'interno dell'app Android. Il diagramma sottostante confronta questi processi di definizione della fiducia fianco a fianco. ## 6. Panoramica delle Impostazioni per Android, iOS e Flutter Di seguito, forniamo una panoramica dettagliata delle diverse impostazioni necessarie per configurare correttamente l'autenticazione tramite passkey per le app native. | Funzionalità | iOS | Android | | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Guida ufficiale all'implementazione dell'autenticazione nativa passkey | Apple Developer | Google Developer | | Consente di condividere le passkey con le app web | Sì, tramite il file apple-app-site-association | Sì, tramite assetlinks.json | | Posizione del file di associazione | [https://acme.com/.well-known/apple-app-site-association](https://acme.com/.well-known/apple-app-site-association) | [https://acme.com/.well-known/assetlinks.json](https://acme.com/.well-known/assetlinks.json) | | File memorizzato nella cache | Sì (da iOS 14), la sincronizzazione iniziale può richiedere fino a 24h | Sì (tramite Play Services) | | Bypass possibile | Sì, con sezione alternate mode | No | | Testabile con | test apple-app-site-association | test assetlinks.json | | Identificatore dell'app con esempio | `.`, es. `T84QZS65DQ.com.facebook.Messenger` | Impronta SHA256, es. `E3:F9:E1:E0:CF:99:D0:E5:6A:05:5B:A6: 5E:24:1B:33:99: 7F:CE:A5:24:32: 6B:0C:DD:6E:C1:32: 7E:D0:FD:C1` | | Dove trovare l'identificatore dell'app | Il Team Application Identifier Prefix si trova nell'account sviluppatore su developer.apple.com e il Bundle Identifier è il nome esatto all'interno del progetto XCode | Se già caricato: Google Play Console > Gestione delle versioni > Firma dell'app Locale: `keytool -list -v -keystore -alias -storepass -keypass ` | | Nome della sezione che collega l'app al web | applinks (non richiesto per le passkey) | `delegate_permission/common.handle_all_urls` (richiesto per le passkey) | | Nome della sezione che consente la condivisione delle credenziali | webcredentials | `delegate_permission/common.get_login_creds` | | Registro di tutti i file di associazione | Abilitare e aggiungere il dominio associato nell'ambiente di sviluppo XCode (impostazione della proprietà per generare il file degli entitlement) | Quando si utilizza l'API Credential Manager, il registro di assetlinks.json nel manifest non è richiesto per le passkey (mentre lo è per le password). Se non si usa l'API Credential Manager, è necessario elencare gli hostname con la voce `` in AndroidManifest.xml nell'attività specifica (parte del codice sorgente dell'app Android). L'`` deve essere autoVerify=true. | Per [Flutter](https://www.corbado.com/blog/flutter-passkeys-package), si applica la rispettiva regola di Android o iOS. L'unica impostazione specifica per [Flutter](https://www.corbado.com/blog/flutter-passkeys-package) è il registro dei file di associazione, in cui dovresti aggiungere: - Per Android: [flutter_deeplinking_enabled su AndroidManifest.xml](https://docs.flutter.dev/cookbook/navigation/set-up-app-links) - Per iOS: [FlutterDeepLinkingEnabled true su Info.plist](https://docs.flutter.dev/cookbook/navigation/set-up-universal-links) ## 7. Esempi di Relying Party ID e File di Associazione Validi e Non Validi Poiché abbiamo sperimentato in prima persona che lavorare con Relying Party ID, diversi livelli di (sotto)domini e CNAME può essere un compito piuttosto impegnativo, presentiamo quattro esempi distinti e spieghiamo perché e come funzionano. Nota che la riga della tabella CNAME non è richiesta per l'autenticazione tramite passkey ed è solo un risultato della nostra ricerca che volevamo aggiungere. ### 7.1 Esempio 1: La Relying Party è il Dominio Principale | **Relying Party ID** | corbado.com | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Entitlements (solo iOS)** | webcredentials:corbado.com | | **Posizione del file apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Posizione del file assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | n/a | In questo esempio, il file `apple-app-site-association` / `assetlinks.json` per Corbado.com può essere scaricato senza problemi quando l'app nativa viene installata / aggiornata, perché il file si trova nella stessa posizione del Relying Party ID. **È possibile creare una passkey per il Relying Party ID.** ### 7.2 Esempio 2: La Relying Party è un Sottodominio e CNAME è impostato | Relying Party ID | auth.corbado.com | | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlements (solo iOS)** | webcredentials:auth.corbado.com | | **Posizione del file apple-app-site-association** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **Posizione del file assetlinks.json** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | In questo esempio, il file `apple-app-site-association` / `assetlinks.json` per auth.corbado.com può essere scaricato senza problemi quando l'app nativa viene installata / aggiornata, perché il file si trova nella posizione come il Relying Party ID, in quanto il CNAME punta dal Relying Party ID alla posizione memorizzata. **È possibile creare una passkey per il Relying Party ID.** ### 7.3 Esempio 3: La Relying Party è il Dominio Principale e CNAME è impostato | Relying Party ID | corbado.com | | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlements (solo iOS)** | webcredentials:corbado.com; webcredentials:auth.corbado.com | | **Posizione del file apple-app-site-association** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **Posizione del file assetlinks.json** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | In questo esempio, il file `apple-app-site-association` / `assetlinks.json` per auth.corbado.com può essere scaricato senza problemi quando l'app nativa viene installata / aggiornata, perché il file si trova, grazie al CNAME, nella posizione in cui `auth.corbado.com` se lo aspetta. MA: Il file `apple-site-association-file` / `assetlinks.json` per corbado.com non può essere scaricato quando l'app nativa viene installata / aggiornata, perché il file non si trova in `https://corbado.com/.well-known/apple-app-site-association` / `https://corbado.com/.well-known/assetlinks.json`, dove è previsto e nessun CNAME punta ad esso. **Non è possibile creare una passkey per il Relying Party ID.** ### 7.4 Esempio 4: La Relying Party è un Sottodominio e Wildcard Entitlement è impostato | Relying Party ID | auth.corbado.com | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Entitlements (solo iOS)** | webcredentials:\*.corbado.com | | **Posizione del file apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Posizione del file assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | n/a | In questo esempio, il file `apple-app-site-association` per corbado.com può essere scaricato senza problemi quando l'app nativa viene installata / aggiornata, perché il file si trova dove previsto e l'entitlement webcredentials (`*.corbado.com`) corrisponde al Relying Party ID (`auth.corbado.com`). Nota che questo esempio non funziona per Android, in quanto Android non lavora con [cose](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey) come (wildcard) entitlement. In generale, questo modo di definire i Relying Party ID non è consigliato. **È possibile creare una passkey per il Relying Party ID.** ## 8. Errori Comuni del Relying Party ID e Come Evitarli ### 8.1 Cambiare il Relying Party ID da Sottodominio a Dominio Principale **Errore:** Hai iniziato a sviluppare e hai definito un sottodominio (es. `login.acme.com`) come Relying Party ID. I primi utenti hanno creato una passkey per questo Relying Party ID. Poi, noti che hai bisogno di queste passkey anche per l'autenticazione su un altro sottodominio (es. `app.acme.com`). Poiché l'origine di un utente e il Relying Party ID per il nuovo sottodominio non corrispondono, l'utente non può accedere con la passkey. Cambiare il Relying Party ID nelle impostazioni WebAuthn in `acme.com` invaliderebbe tutte le passkey esistenti, poiché la nuova origine e il Relying Party ID memorizzato nelle passkey esistenti non corrispondono. **Soluzione:** Controlla attentamente in fase di definizione il tuo Relying Party ID, poiché questo è più o meno definitivo. Se sei insicuro e vuoi essere pronto per il futuro, cioè se altri sottodomini in futuro potrebbero aver bisogno della passkey per l'autenticazione, ti consigliamo di utilizzare il dominio principale (es. acme.com) come Relying Party ID a meno che non sia presente nella [Public Suffix List](https://publicsuffix.org/learn/). ### 8.2 Relying Party ID Diversi per App Nativa e App Web **Errore:** Stai sviluppando contemporaneamente un'app nativa e una web. Per velocizzare le [cose](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey), usi due server WebAuthn diversi (con Relying Party ID diversi per l'app nativa e quella web). Quando i tuoi utenti creano le prime passkey, il rispettivo Relying Party ID viene memorizzato nella passkey. Consentire l'accesso multi-dispositivo / multi-piattaforma con la stessa passkey, es. con una passkey creata in un'app web provando ad accedere in un'app nativa, non è più possibile. Unire i due server WebAuthn abbandonerà le passkey registrate con il vecchio server WebAuthn (vecchio Relying Party ID) e i tuoi utenti non potranno accedere con queste passkey. **Soluzione:** Se possiedi più applicazioni (es. un'app web e un'app nativa), mantieni sempre e solo un server WebAuthn e definisci un solo Relying Party ID per tutte le tue app. Il collegamento tra queste app può essere effettuato tramite i passaggi descritti in precedenza. ### 8.3 File di Associazione Non Validi e Irraggiungibili **Errore:** Inizi a sviluppare la tua applicazione, configuri i file di associazione e li distribuisci sul tuo server. Per qualche motivo, continui a ricevere messaggi di errore e non riesci a trovarne la causa. **Soluzione:** Una potenziale causa per il messaggio di errore potrebbe essere un file di associazione malformato o irraggiungibile. Prima di distribuire qualsiasi file di associazione su un server, raccomandiamo caldamente di verificarne la validità e la raggiungibilità (spesso questi file potrebbero trovarsi dietro [una robusta VPN](https://cybernews.com/best-vpn/most-secure-vpns/) o un firewall che impedisce l'accesso corretto ai crawler di Apple e Google) del file di associazione tramite gli strumenti forniti per [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) e Android. ### 8.4 File apple-app-site-association Non Ancora Memorizzato nella Cache dalla CDN Apple **Errore:** Hai distribuito il tuo file apple-app-site-association sul tuo server e vuoi iniziare immediatamente a [creare una passkey](https://www.corbado.com/it/blog/migliori-pratiche-creazione-passkey) sul tuo dispositivo di test. Per qualche motivo, non riesci a creare la passkey e ricevi messaggi di errore. **Soluzione:** La ragione di questi messaggi di errore è che i dispositivi iOS scaricano il file `apple-app-site-association` per convalidare la Relying Party. Per farlo, i dispositivi iOS non inviano una richiesta diretta al tuo server ma utilizzano una CDN. Sia il dispositivo che la CDN memorizzano nella cache il file `apple-app-site-association` dopo averlo recuperato con successo. A causa di questa funzionalità di caching, le nuove modifiche al file `apple-app-site-association` non si riflettono direttamente nella tua app. Possono trascorrere fino a 24 ore prima che la CDN memorizzi nella cache il file `apple-app-site-association`. Per aggirare questa restrizione durante lo sviluppo, puoi aggiungere `?mode=developer` al Relying Party ID e disabilitare completamente il caching (es. il Relying Party ID diventerebbe `acme.com?mode=developer`). ### 8.5 Incompatibilità tra Emulatore Android e Versione API **Errore:** Inizi a sviluppare un'app Android e vuoi testarla su un emulatore Android. Per qualche motivo, ricevi messaggi di errore, sebbene tu abbia configurato correttamente l'emulatore Android e le altre app sembrino funzionare senza problemi. **Soluzione:** Le versioni di Android, il supporto del Play Store e le versioni API giocano un ruolo fondamentale durante i test di un'applicazione passkey. Inoltre, è necessario aver effettuato l'accesso a un account Google. Fai riferimento alla nostra sezione sulla risoluzione dei problemi per i dettagli. ## 9. Raccomandazioni ### 9.1 Raccomandazione Generale La nostra raccomandazione generale è di scegliere attentamente il tuo Relying Party ID in base al tuo panorama applicativo e ai tuoi requisiti. Di seguito, abbiamo raccolto i casi d'uso più comuni, ma la nostra indicazione generale è che dovresti **puntare a scegliere il tuo dominio principale come Relying Party ID** e configurare la tua autenticazione in questo modo. Con Corbado, lo abbiamo già pre-configurato in questo modo per te (poiché fa parte del nostro approccio per offrire un'autenticazione passkey fluida per tutte le configurazioni tecniche. I nostri componenti UI e SDK sono predisposti per essere utilizzati con il tuo dominio principale come Relying Party ID). | Caso | Raccomandazione | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A) Hai un solo dominio principale:**

Esempio: acme.com

Tutte le applicazioni e le autenticazioni avvengono su questo dominio principale o sui suoi sottodomini | ✔️ Scegli il dominio principale come Relying Party ID poiché ciò non causerà alcun problema per app web o native. | | **B) Hai più domini principali:**

Esempio: kayak.com, kayak.co.uk, kayak.de

Servi i tuoi utenti da diversi domini di primo livello internazionali. Kayak.com per gli USA e kayak.co.uk per il Regno Unito, o hai domini principali completamente diversi che dovrebbero consentire agli stessi utenti di accedere con le stesse passkey. | ⚠️ Nelle tue app web, condividere le passkey richiede la configurazione delle Related Origin Requests tramite `.well-known/webauthn` per consentire a determinate origini di utilizzare un RP ID comune (il supporto dei browser varia; verifica la compatibilità). In alternativa, scegli un dominio principale di autenticazione comune.

✔️ Puoi collegare le tue app native a qualsiasi numero di domini principali a condizione di avere il controllo sui file di associazione principali.

❌ Nel caso tu voglia in seguito migrare verso un altro dominio principale per ospitare il tuo sito web, non potrai utilizzare le passkey già create, perché dovrai effettuare un rebranding e cambiare il dominio (Relying Party ID). | | **C) Non hai ancora un dominio principale, stai lavorando solo su backend o su un sottodominio pubblico. Ci sono alcuni casi in cui ciò può accadere:**

1. Lavori su un sottodominio liberamente disponibile, in cui il dominio principale non è sotto il tuo controllo (il dominio principale è elencato in [https://publicsuffix.org/](https://publicsuffix.org/)) ad esempio per gli URL CDN

2. Lavori su un'app nativa. | ❌ Sui sottodomini pubblici, non puoi controllare i file di associazione al livello radice del dominio principale. Pertanto, le passkey non funzioneranno nativamente.

⚠️ L'unico modo per risolvere il problema per alcuni servizi è passare a un piano a pagamento, in cui puoi definire un CNAME o ottenere un dominio principale personalizzato per te. | ### 9.2 Raccomandazioni Quando Si Usa Corbado Di seguito, forniamo un albero decisionale molto specifico che dovrebbe aiutarti a determinare il corretto Relying Party ID e come dovresti gestire / ospitare i file di associazione quando usi Corbado come tua soluzione passkey. La prima decisione è se ti trovi in un ambiente di sviluppo o di produzione. Il livello decisionale successivo che devi affrontare si basa sul tuo panorama applicativo: hai solo un'app nativa o un'app nativa e una web. #### A) Sviluppo Per l'ambiente di sviluppo, supponiamo che tu voglia iniziare rapidamente a sviluppare e testare. Il Relying Party ID può essere modificato in seguito se desideri andare in produzione. ##### A1) Solo App Nativa - Imposta Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io` (valore predefinito) - Corbado ospita il file di associazione per te - Nessuna operazione DNS necessaria da parte tua ##### A2) App Nativa & App Web Non è facile testare contemporaneamente l'app web e l'app nativa. **Opzione 1:** Puoi impostare Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io` (funziona l'app nativa) OPPURE impostare Relying Party ID = `localhost` (funziona l'app web) **Opzione 2:** L'unica soluzione affinché l'app nativa e quella web funzionino contemporaneamente è utilizzare un reverse proxy locale (è una soluzione piuttosto raffazzonata): - Imposta Relying Party ID = `acme-dev.com` - Imposta CNAME da `acme-dev.com` => `pro-XXX.frontendapi.cloud.corbado.io` - Aggiungi la voce locale in `/etc/hosts`: `localhost acme-dev.com` - Aggiungi il reverse proxy (nginx) con la regola per `acme-dev.com` => `localhost:3000` (come esempio) #### B) Produzione Nell'ambiente di produzione, devi decidere se sei soddisfatto di un sottodominio come Relying Party ID (es. `auth.acme.com`) o se vuoi un dominio principale come Relying Party ID (es. `acme.com`). ##### B1) Sottodominio come Relying Party ID ###### B1.1) Solo App Nativa - Imposta Relying Party ID = `auth.acme.com` - Corbado ospita il file di associazione per te - Imposta CNAME da `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` ###### B1.2) App Nativa & App Web - Imposta Relying Party ID = `auth.acme.com` - Corbado ospita il file di associazione per te - Imposta CNAME da `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` (necessario anche per il funzionamento dei cookie se utilizzi la gestione delle sessioni di Corbado) ##### B2) Dominio Principale come Relying Party ID ###### B2.1) Solo App Nativa - Imposta Relying Party ID = `acme.com` - Ospita il file di associazione tu stesso sul tuo server all'indirizzo `acme.com/.well-known/` - Nessuna operazione DNS necessaria da parte tua ###### B2.2) App Nativa & App Web - Imposta Relying Party ID = `acme.com` - Ospita il file di associazione tu stesso sul tuo server all'indirizzo `acme.com/.well-known/` - Se utilizzi la gestione delle sessioni di Corbado, devi impostare il CNAME da `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` per far funzionare i cookie (questo CNAME non è necessario per il Relying Party ID ma solo per la gestione delle sessioni) Il seguente albero decisionale riassume tutti i percorsi di configurazione. ## 10. Conclusione Il Relying Party ID è una pietra miliare di WebAuthn e dell'autenticazione basata su passkey e garantisce una forte resistenza al phishing. Configurarne correttamente l'impostazione, comprendere la complessità della corrispondenza del dominio e garantire la corretta distribuzione per le app native è fondamentale. Questo articolo ha mostrato come impostarli correttamente e come gestire i vari errori. Una volta che la configurazione del tuo rpID è solida, concentrati sull'ottimizzazione dei flussi di creazione delle passkey e dei flussi di login passkey per incentivare la vera adozione. Per ulteriori approfondimenti sulla configurazione delle passkey per le app native, raccomandiamo di leggere le informazioni sulle passkey in [Flutter](https://www.corbado.com/blog/flutter-passkeys-package). Se hai altre domande o necessiti di assistenza, non esitare a [contattarci](https://bit.ly/passkeys-community). ## Frequently Asked Questions ### In che modo il Relying Party ID previene il phishing nell'autenticazione tramite passkey? L'autenticatore confronta l'origine effettiva del browser con il Relying Party ID memorizzato nella passkey. Se un aggressore ospita un sito falso su un dominio diverso, la mancata corrispondenza dell'origine causa il fallimento automatico dell'autenticazione, anche se la sfida contraffatta rivendica un RP ID legittimo. Questo legame significa che una passkey registrata su paypal.com non può essere utilizzata su un dominio sosia come paybal.com. ### Cosa succede se modifico il mio WebAuthn Relying Party ID dopo che gli utenti hanno già registrato delle passkey? La modifica del RP ID invalida tutte le passkey esistenti perché il RP ID memorizzato in ciascuna credenziale non corrisponderà più al nuovo valore. Le uniche eccezioni si verificano quando il nuovo RP ID è un sottodominio di quello vecchio o quando le Related Origin Requests sono configurate tramite `.well-known/webauthn`. Scegli il dominio principale come RP ID fin dall'inizio per evitare questo problema irreversibile. ### Perché la mia passkey su iOS non funziona immediatamente dopo aver distribuito il file apple-app-site-association? iOS non recupera il file apple-app-site-association direttamente dal tuo server. Utilizza la CDN di Apple, che può impiegare fino a 24 ore per memorizzare nella cache un file appena distribuito o aggiornato. Durante lo sviluppo, aggiungi `?mode=developer` al Relying Party ID per bypassare completamente la memorizzazione nella cache. ### Dovrei usare un sottodominio o un dominio principale come Relying Party ID per le passkey? Si raccomanda l'uso del dominio principale (es. acme.com) perché le passkey create su qualsiasi sottodominio possono autenticarsi in tutti i sottodomini di quella radice. Un RP ID di sottodominio limita l'uso della passkey a quel sottodominio e ai suoi figli, il che può interrompere i flussi tra sottodomini in un secondo momento. Se possiedi più domini principali come acme.com e acme.co.uk, configura le Related Origin Requests tramite `.well-known/webauthn` per consentire il riutilizzo della passkey tra di essi.