Account bidirezionale verificato che si collega su una piattaforma di identità a nove marchi

Quella flessibilità creò un problema di identità. Quando un cliente accedeva con una nuova identità Apple o Google la cui email apparteneva già a un account esistente, la piattaforma doveva decidere cosa fare. Collegare automaticamente i due tramite una sola corrispondenza email sarebbe pericoloso: un indirizzo email corrispondente suggerisce una relazione, ma non dimostra che la persona che accede controlli effettivamente quella casella di posta. La piattaforma aveva bisogno di un modo per collegare identità compatibili di Apple e Google a un unico account condiviso senza mai concedere accesso a una corrispondenza email da solo, e di farlo in modo coerente su tutti e nove i marchi, inclusi i casi più complicati: indirizzi privati di Apple Relay, account abilitati da password, accessi rischiosi e interruzioni dei fornitori.

I vincoli erano concreti. Il collegamento doveva essere bidirezionale e indipendente dall'ordine: prima Google poi Apple, o prima Apple e poi Google, doveva raggiungere lo stesso account condiviso. Nascondi la mia email di Apple doveva essere gestito separatamente, perché un indirizzo di relay privato che non corrispondeva all'email reale dell'account del cliente non doveva collegarsi silenziosamente a quell'account. La verifica ha dovuto riutilizzare lo stesso meccanismo di sfida del codice già fidato per l'autenticazione a rischio elevato, quindi il collegamento ha ereditato controlli comprovati invece di inventarne di nuovi. Il rischio doveva modulare l'attrito: i registri a basso rischio dovevano rimanere senza attrito mentre il rischio medio, alto e indeterminato richiedeva un OTP. I fallimenti ripetuti dovevano essere contenuti attraverso una politica di blocco che si applicava a livello account, su ogni brand, non per ogni brand. E i fallimenti dei fornitori dovevano essere sicurissimi, senza mai lasciare un cliente con un account parziale o duplicato.

Lo stesso percorso verificato copriva entrambe le direzioni di collegamento. Se un cliente ha creato un account con Google e successivamente ha scelto Continua con Apple usando la stessa email condivisa, il sistema ha rilevato l'account esistente, inviato un codice alla propria email e collegato Apple dopo una verifica riuscita a pagamento. Il contrario, prima Condividi la mia email di Apple e poi Google si è risolto sullo stesso account condiviso con la stessa sfida. Dopo il collegamento, il cliente poteva accedere con Apple, Google o con email e password ovunque fosse stata configurata, e atterrare sullo stesso account.

Il programma Nascondi la mia email di Apple è rimasto un percorso deliberatamente separato. Quando l'indirizzo di relay privato non corrispondeva all'email personale non divulgata del cliente, le identità non erano idonee per il collegamento alla stessa email. Invece di collegare il relay a un account non correlato, la piattaforma ha mostrato una spiegazione di accesso limitato e ha creato un account relay email separato. Oltre al primo collegamento, lo stesso account aveva un proprio ciclo di vita: un cliente poteva impostare una password su un account social, cambiare l'email principale (che collegava il precedente provider social e richiedeva una nuova verifica) e ogni login di ritorno passava comunque attraverso una valutazione del rischio prima che venisse rilasciata una sessione.

Da lì il flusso si è diramato in risultati chiaramente limitati. Una corrispondenza email idonea emetteva un codice di collegamento all'email dell'account esistente; Al termine della verifica riuscita il provider veniva collegato; in caso di fallimento il tentativo veniva respinto e registrato. Un'email di relay Apple che non corrispondeva è stata indirizzata a una spiegazione ad accesso limitato e a un account relay email separato. Una volta risolto su un account cross-brand condiviso, lo stato dell'account veniva controllato: un account bloccato veniva mostrato come bloccato, un account attivo veniva classificato in una categoria di rischio. Low Risk emise direttamente una sessione autenticata; rischio medio, alto e indeterminato inviava un OTP di autenticazione, e ripetute sfide fallite, fino a una soglia fissa, bloccava l'account condiviso su tutti e nove i marchi. L'account stesso esponeva la configurazione della password e i cambiamenti nell'email, dove cambiare l'email principale ha scollegato il precedente provider social e ha richiesto una nuova verifica del fornitore. I guasti del servizio provider non hanno creato uno stato parziale: restituivano un errore sicuro e un nuovo tentativo che tornava nello stesso orchestratore, quindi una chiamata Apple o Google fallita non produceva mai un account semi-collegato o duplicato. Il confine di collegamento combinava tre controlli: una risposta del fornitore validata, una corrispondenza compatibile con la stessa email e una sfida di codice email riuscita, e i falliti invii di codice seguivano la stessa politica di controllo delle sfide e blocco degli OTP del rischio.