Quali sono le differenze tra client pubblici e riservati?

Quando utilizzi Logto per creare un'applicazione, noterai che ci sono diversi tipi di applicazioni tra cui scegliere, tra cui Single Page Application (SPA), Native App e Traditional Web App. Intuitivamente, dal nome, è chiaro che una Native App gira sui sistemi operativi comunemente presenti su dispositivi come i telefoni. Tuttavia, cosa sono esattamente SPA e Traditional Web App? Perché dobbiamo distinguere tra questi diversi tipi di app? Questo articolo rivelerà le risposte a queste domande.

Prima di iniziare, dobbiamo fornire una breve introduzione a qualche concetto.

Che cos'è OAuth?#

OAuth è uno standard aperto per la delega degli accessi, che viene tipicamente utilizzato come un modo per consentire agli utenti di Internet di concedere a siti web o applicazioni l'accesso alle loro informazioni su altri siti senza fornire le loro password.

Nell'ultimo decennio, è gradualmente diventato il processo di autorizzazione standard ed è stato ampiamente accettato da molte aziende come Google, Meta, Microsoft e così via. La versione attualmente utilizzata è OAuth 2.0.

Nel contesto di OAuth, l'applicazione di cui abbiamo parlato in precedenza si riferisce come Client. Possono fare richieste per risorse protette, a condizione che abbiano ottenuto l'autorizzazione del proprietario della risorsa (di solito utenti finali).

Client pubblici e riservati#

OAuth definisce due tipi di client, basati sulla loro capacità di mantenere la riservatezza delle credenziali del client.

Client riservato#

Un client che è in grado di mantenere la riservatezza delle proprie credenziali (ad esempio, un client implementato su un server sicuro con accesso limitato alle credenziali del client) o uno che è in grado di autenticazione sicura del client tramite altri mezzi.

Client pubblico#

Un client che non è in grado di mantenere la riservatezza delle proprie credenziali (ad esempio, un client in esecuzione sul dispositivo del proprietario della risorsa, come un'app nativa o un'app basata sul web) e non è inoltre in grado di autenticarsi in modo sicuro come client tramite altri mezzi.

SPA, applicazione nativa e applicazione web tradizionale#

Con le conoscenze di base sopra menzionate, diamo un'occhiata a cosa significano SPA, Native App e traditional web app nel contesto di Logto, nonché se sono considerate client pubblici o riservati.

SPA#

Il codice lato client di un SPA viene scaricato da un server web ed eseguito nell'user agent (come un browser web) del proprietario della risorsa sul loro dispositivo. I dati di protocollo e le credenziali sono facilmente accessibili (e spesso visibili) al proprietario della risorsa.

App nativa#

Un'app nativa è installata ed eseguita sul dispositivo del proprietario della risorsa. I dati di protocollo e le credenziali sono accessibili al proprietario della risorsa. Si presume generalmente che qualsiasi credenziale di autenticazione del client contenuta all'interno dell'applicazione possa essere estratta.

Applicazione web tradizionale#

Un'applicazione web tradizionale è un client che gira su un server web. Il proprietario della risorsa accede al client tramite un'interfaccia utente HTML presentata nell'user agent sul loro dispositivo. Le credenziali del client così come qualsiasi token di accesso emesso al client sono archiviati sul server web e non sono esposti o accessibili al proprietario della risorsa.

Quindi, possiamo chiaramente vedere che SPA e app nativa sono client pubblici, mentre l'applicazione web tradizionale è un client riservato.

Potresti notare che quando crei un SPA o un'app nativa in Logto, non c'è un segreto dell'app, mentre un'applicazione web tradizionale ha sia un ID dell'app che un segreto dell'app. Questo perché il segreto di un client pubblico non può essere garantito come sicuro.

Come funziona un client nel flusso di autorizzazione OAuth?#

Quando si sviluppano applicazioni OAuth, il primo passo è registrare il client con il provider di servizi OAuth. La registrazione del client comporta la fornitura di dettagli sull'applicazione, come il suo nome e l'URI di reindirizzamento. Poi, il provider di servizi OAuth genera un ID client e un segreto del client, che sono considerati le credenziali dell'applicazione.

L'ID client è considerato informazione pubblica ed è condiviso con l'utente durante il processo OAuth. È tipicamente incluso nell'URL di autorizzazione e visibile agli utenti finali.

D'altra parte, il segreto del client funziona come una password per l'applicazione e deve essere mantenuto segreto. Viene utilizzato nel processo OAuth per scambiare il codice di autorizzazione (assumendo che sia il flusso del codice di autorizzazione) per ottenere il token di accesso. L'esistenza dei segreti del client assicura che solo le applicazioni registrate possono completare lo scambio dei token di accesso.

Introduzione a Proof Key for Code Exchange (PKCE)#

Come menzionato in precedenza, i segreti dei client pubblici non possono essere garantiti come sicuri, e gli aggressori possono ottenere credenziali del client e impersonare i client per accedere a risorse protette, il che è inaccettabile in qualsiasi situazione.

PKCE (Proof Key for Code Exchange) risolve questo problema generando temporaneamente un codice verificatore all'inizio di ogni flusso di autorizzazione, che viene archiviato localmente e sottoposto a hash per generare una sfida di codice che viene inviata al server di autorizzazione. Il codice verificatore viene inviato di nuovo al server di autorizzazione quando si scambia il token di accesso. Il server di autorizzazione verifica che il codice verificatore e la sfida di codice corrispondano, il che garantisce che il client pubblico non sia stato impersonato.

Il codice verificatore in PKCE effettivamente funziona come un segreto dinamico del client. La sua sicurezza è garantita dall'irreversibilità dell'algoritmo di hash.

Ricapitolazione#

In questo articolo, abbiamo discusso i concetti di client riservati e client pubblici in OAuth. Abbiamo appreso che i client riservati hanno la capacità di mantenere segreti e archiviare in modo sicuro informazioni sensibili, mentre i client pubblici non hanno questa capacità. Abbiamo esaminato esempi dei due tipi di client, incluse le applicazioni web tradizionali, SPA e app native, nel contesto delle pratiche di prodotto di Logto.

Abbiamo anche discusso il processo di registrazione del client in OAuth e i ruoli dell'ID del client e del segreto del client.

Inoltre, abbiamo scoperto che i client pubblici affrontano limitazioni nella memorizzazione sicura dei segreti del client. Per superare questa limitazione, abbiamo introdotto PKCE (Proof Key for Code Exchange), un'estensione OAuth che consente ai client pubblici di scambiare in modo sicuro i codici di autorizzazione senza la necessità di un segreto del client.

Il nostro prodotto, Logto, è una soluzione CIAM completa che segue le migliori pratiche dei protocolli OAuth e OIDC per garantire la sicurezza in ogni fase, incluso l'adozione dell'uso di PKCE per proteggere la sicurezza dei client pubblici.