WebAuthn Relying Party ID (rpID) e Passkey: Domini e App Native

L'autenticazione tramite passkey sta rapidamente diventando la norma man mano che giganti della tecnologia come TikTok, GitHub, WhatsApp, X (Twitter), LinkedIn e Amazon le introducono o lo hanno già fatto. È evidente che il mondo della tecnologia stia riconoscendo l'importanza di un'autenticazione semplice e sicura.

Oltre all'esperienza utente fluida dell'autenticazione con Face ID, Touch ID o 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.

Cheatsheet Passkeys. Guide pratiche, pattern di distribuzione e KPI per programmi passkey.

Ottieni la cheatsheet

Prova le passkey in una demo live.

Prova le passkey

Un attacco di 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 (un provider di autenticazione!) o Retool sono state vittime di attacchi di spear-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.

Questo meccanismo è integrato in WebAuthn, lo standard web alla base delle passkey per l'autenticazione senza password. 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) 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), a cui appartiene l'app web o nativa, corrisponde al Relying Party ID memorizzato nella passkey.

Di seguito, vedremo in dettaglio come funziona questo processo di corrispondenza del dominio e come, in particolare, le app native vengono protette.

Il Relying Party ID è 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). È un componente cruciale della specifica WebAuthn, che puoi approfondire qui. 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). 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:

Di seguito, vedi la struttura analizzata di PublicKeyCredentialCreationOptions:

{
    "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, un sito web falso che cerca di rubare le tue credenziali PayPal per accedere a tuo nome e inviare denaro al conto dell'aggressore. Questo sito web PayPal 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:<SHA256_fingerprint>. 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). 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.

Entra nella nostra community passkeys per aggiornamenti e supporto.

Unisciti

Per implementare le passkey in un'app nativa, uno sviluppatore può decidere se aggiungerle tramite WebView o in modo nativo. Esaminiamo i vantaggi e gli svantaggi di entrambi gli approcci di seguito.

L'utilizzo di una WebView* per integrare le passkey significa incorporare un browser web all'interno dell'app nativa 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 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.

Scopri quante persone usano davvero le passkey.

Vedi dati di adozione

L'integrazione nativa comporta la costruzione della funzionalità passkey direttamente nell'app iOS o 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 e una WebView. 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). 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.

Scopri quante persone usano davvero le passkey.

Vedi dati di adozione

Le app native (es. app iOS o 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).

iOS utilizza il file apple-app-site-association. Questo file contiene vari entitlement, ma per WebAuthn e le passkey, l'entitlement webcredentials è importante.

{
    "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://<Relying Party ID>/.well-known/apple-app-site-association).

Vedi un esempio dal vivo qui.

Android utilizza il file assetlinks.json, che, come la sua controparte iOS, richiede configurazioni particolari per WebAuthn e le passkey.

[
    {
        "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.

Affinché le app Android funzionino, il file assetlinks.json deve essere memorizzato nella directory /.well-known del Relying Party ID https://<Relying Party ID>/.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 / iOS e un'app web.

Sperimenta i flussi passkey nel Passkeys Debugger.

Prova gratis

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.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

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.

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://<Relying Party ID>./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.

Iscriviti al nostro Substack sulle passkey per le ultime novità.

Iscriviti

Di seguito, forniamo una panoramica dettagliata delle diverse impostazioni necessarie per configurare correttamente l'autenticazione tramite passkey per le app native.

Per Flutter, si applica la rispettiva regola di Android o iOS. L'unica impostazione specifica per Flutter è il registro dei file di associazione, in cui dovresti aggiungere:

• Per Android: flutter_deeplinking_enabled su AndroidManifest.xml
• Per iOS: FlutterDeepLinkingEnabled true su Info.plist

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.

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.

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.

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.

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 come (wildcard) entitlement. In generale, questo modo di definire i Relying Party ID non è consigliato.

È possibile creare una passkey per il Relying Party ID.

Entra nella nostra community passkeys per aggiornamenti e supporto.

Unisciti

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.

Errore:

Stai sviluppando contemporaneamente un'app nativa e una web. Per velocizzare le cose, 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.

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 o un firewall che impedisce l'accesso corretto ai crawler di Apple e Google) del file di associazione tramite gli strumenti forniti per iOS e Android.

Errore:

Hai distribuito il tuo file apple-app-site-association sul tuo server e vuoi iniziare immediatamente a creare una 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).

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.

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).

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.

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.

• 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

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)

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).

• 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

• 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)

• Imposta Relying Party ID = acme.com
• Ospita il file di associazione tu stesso sul tuo server all'indirizzo acme.com/.well-known/<file di associazione>
• Nessuna operazione DNS necessaria da parte tua

• Imposta Relying Party ID = acme.com
• Ospita il file di associazione tu stesso sul tuo server all'indirizzo acme.com/.well-known/<file di associazione>
• 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.

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.

Se hai altre domande o necessiti di assistenza, non esitare a contattarci.

Chi siamo

Corbado è la Passkey Intelligence Platform per i team CIAM che gestiscono l'autenticazione consumer su larga scala. Ti aiutiamo a vedere ciò che i log IDP e gli strumenti di analytics generici non mostrano: quali dispositivi, versioni di OS, browser e gestori di credenziali supportano i passkey, perché gli enrollment non si trasformano in login, dove il flusso WebAuthn fallisce e quando un aggiornamento di OS o browser interrompe silenziosamente il login — tutto senza sostituire Okta, Auth0, Ping, Cognito o il tuo IDP interno. Due prodotti: Corbado Observe aggiunge osservabilità per i passkey e qualsiasi altro metodo di login. Corbado Connect introduce passkey gestiti con analytics integrato (insieme al tuo IDP). VicRoads gestisce i passkey per oltre 5M di utenti con Corbado (+80 % di attivazione passkey). Parla con un esperto di 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.

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.

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.

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.