Hai bisogno di costruire la tua autenticazione per le app?

Contesto#

Ho visto molti sviluppatori fare domande come “Devo costruire la mia autenticazione per la mia app?”. Mentre la risposta non può essere un semplice "Sì" o "No", vorrei scrivere un articolo per analizzare l'implementazione e dimostrare i pro e i contro per aiutarti a decidere.

In sintesi È necessario trovare una soluzione esistente che soddisfi le tue esigenze, a meno che tu non voglia realmente il pieno controllo o stia ancora imparando lo sviluppo del software.

Introduzione#

Come sviluppatore, ho costruito molte applicazioni durante la mia carriera. Indipendentemente dal linguaggio di programmazione, c'è sempre una base comune che devo costruire: l'autenticazione dell'utente.

Era una parte trascurabile dato che tutto era semplice tornando indietro di 20 anni fa:

• Implementa un sistema di registrazione e accesso con nome utente e password.
• Crea un meccanismo per mantenere la sessione di un utente.
• Riguardo alla sicurezza? La risposta è MD5.

Ecco fatto. Poi potevo concentrarmi sul "vero business". Non hai sentito parlare di MD5? Ti sei perso i "bei tempi" dello sviluppo del software. Oggi, gli sviluppatori affrontano più sfide quando costruiscono l'accesso/la registrazione.

Può sembrare allarmista, ma lascia che te lo spieghi con un esempio.

Esempio: Una libreria online#

Immagina di voler costruire una libreria online con un servizio API e un'app frontend web.

Innanzitutto, lo scopo dell'"autenticazione" dovrebbe essere definito. L'autenticazione può essere spiegata come autenticazione e autorizzazione, e hanno definizioni e casi d'uso completamente diversi:

Ho scritto un articolo CIAM 101: Autenticazione, Identità, SSO per discutere in dettaglio questi concetti.

Scegliere i metodi di autenticazione#

Cominciamo con l'"autenticazione", che nel nostro esempio è l'accesso dell'utente. Oltre al metodo nome utente e password, ecco alcuni metodi di tendenza che le persone stanno adottando per una migliore conversione dell'utente e sicurezza:

• Senza password, ovvero il codice di verifica dinamico (via email o sms)
• Accesso tramite social (Google, Facebook, ecc.)

La scelta del metodo dipende dalla decisione imprenditoriale, mentre possiamo dare un'occhiata allo sforzo tecnologico:

• Per il metodo senza password, devi trovare un fornitore per inviare codici di verifica via email o sms; poi integrare con il tuo servizio API (potrebbero essere necessarie nuove API).
• Per l'accesso tramite social, devi aderire alle linee guida di integrazione del/dei provider di identità social che desideri utilizzare. Inoltre, devi creare una corrispondenza tra gli ID utente della tua libreria e quelli del provider di identità.
  • Ad esempio, quando un utente accede con un account Gmail [email protected], puoi collegare questo indirizzo email all'utente foo nella libreria. Questo processo ti aiuta a costruire un sistema di identità unificato e permette all'utente di modificare o scollegare la loro identità sociale in futuro.

Progetta e implementa l'esperienza di accesso#

Dopo aver deciso i metodi di autenticazione, un'esperienza di accesso fluida e gradevole per i tuoi utenti finali è il prossimo obiettivo. La conversione qui è fondamentale ma cruciale per il business, poiché è un modo naturale per lasciare i dati dei clienti persistenti.

Quando lavoravo per Airbnb, c'era un intero team dedicato ad ottimizzare l'esperienza di accesso per molteplici piattaforme. Hanno condotto numerosi test A/B per determinare quale combinazione aveva il tasso di conversione più alto.

Non è pratico farlo quando un'azienda sta iniziando. Ma dobbiamo ancora fare del nostro meglio per rendere ogni pezzo corretto. Su quali piattaforme vorresti eseguire la libreria? Potresti iniziare con il mobile, il web, o entrambi. Il design esatto dipenderà dai metodi di autenticazione che scegli:

• Nome utente e password: Il più facile, solo alcune caselle di input e pulsanti.
• Senza password: Inserisci il telefono / email, poi invia e verifica un codice dinamico.
• Accesso tramite social: Leggi la documentazione dal provider di identità social scelto, segui la guida visuale, gestisci la logica di reindirizzamento, e infine collega l'identità social con l'identità della libreria.

Altre cose da considerare per migliorare:

• Hai bisogno di combinare il processo di accesso e registrazione per un metodo specifico?
• Hai bisogno di un flusso "password dimenticata" per permettere ai clienti di reimpostare autonomamente le loro password?

Se opti per lo sviluppo nativo, il carico di lavoro raddoppierà quasi per ogni piattaforma aggiuntiva.

Sicurezza e scambio di token#

La sicurezza può essere un iceberg nascosto. Sarà fantastico se sei familiare con OpenID Connect o OAuth 2.0, dato che sono ampiamente utilizzati e collaudati. OpenID Connect è relativamente nuovo ma è progettato per l'"autenticazione dell'utente", che è perfetta per una libreria online.

Senza addentrarsi nei dettagli degli standard, ci sono comunque alcune cose da considerare:

• Quale metodo di crittografia dovrebbe essere utilizzato per le password?
• Qual è il processo per l'autenticazione e l'autorizzazione standard?
• Come funziona lo scambio di token (Token di Accesso, Token di Aggiornamento, Token ID, ecc.)?
• Come possono essere utilizzate le chiavi di firma nei token e come può essere validata la firma per proteggere le risorse?
• Come possono essere prevenuti gli attacchi al client e al server?

Infine, puoi realizzare una buona esperienza di accesso e fornirla ai tuoi clienti.

Modello di autorizzazione#

Come libreria, devi separare le risorse per i clienti e i venditori. Ad esempio, i clienti possono sfogliare tutti i libri, mentre i venditori possono gestire i loro libri in vendita. Va bene iniziare con semplici controlli if-else; tuttavia, con la crescita del business, potresti dover sfruttare un modello più flessibile come il Controllo degli Accessi Basato sui Ruoli (RBAC) o il Controllo degli Accessi Basato sugli Attributi (ABAC).

Ho anche scritto un articolo CIAM 102: Autorizzazione & Controllo degli Accessi Basato sui Ruoli per dimostrare i concetti di autorizzazione di base e il modello RBAC.

Prendere la decisione#

Come puoi vedere, l'autentica non è un problema di "tutto o niente", dato che coinvolge molteplici componenti tecnici e tu o il tuo team potreste avere diverse competenze tecniche in queste aree. È importante scomporlo in parti più piccole per avere una migliore comprensione dello status quo.

Per prendere la decisione, mi chiederò le seguenti domande:

• Quanto è urgente il progetto?
• Quanto sforzo mi aspetto di mettere nell'autenticazione rispetto al business?
• Qual è la priorità dell'esperienza utente, della sicurezza e della manutenibilità?
• Di quale/i parte/i ho bisogno di pieno controllo? Quanto devo conoscerli?
• Se vado con alcuni framework / soluzioni, sono abbastanza buoni per la personalizzazione o l'estensione?
• Se il business cresce, avrò bisogno di introdurre un nuovo modello di autenticazione?
• Se trovo un venditore adatto, è abbastanza sicuro da usare? Ho bisogno di un piano di ritirata se accade qualcosa al venditore?

Con queste domande in mente, ho scoperto due fatti:

• Creare un sistema di autenticazione affidabile è altamente complesso.
• I fornitori esistenti non riescono a soddisfare tutti i criteri necessari.

Quindi ho deciso di avviare un progetto dedicato (Logto) per l'autenticazione, e abbracciare la community open-source dal primo giorno.

Spero che questo articolo ti sia di aiuto.