Che cos'è OAuth e come funziona

Ogni volta che clicchi 'Accedi con Google' or "Connettiti con Microsoft", Stai usando OAuth. Ma cos'è OAuth? OAuth è un framework di autorizzazione open standard che ti consente di concedere a un'applicazione l'autorizzazione ad accedere alle tue informazioni su un altro servizio, senza mai condividere la tua password. È così che funziona OAuth. Verifica la tua identità senza condividere la password, trasmettendo all'app solo informazioni limitate, appena sufficienti a confermare la tua legittimità. È la stretta di mano silenziosa che alimenta accessi sicuri e moderni.

Oggi, dove quasi tutti i dipendenti accedono alle app cloud da dispositivi personali o esterni, gli accessi tradizionali non sono più validi. L'autenticazione OAuth risolve questo problema consentendo agli utenti di concedere alle app un accesso limitato senza condividere le password. Invece delle credenziali, le app ricevono token con ambito limitato. Ciò significa un maggiore controllo, meno rischi e meno punti di errore.

Quindi, in cosa si differenzia l'autenticazione OAuth? Separa l'identità dall'accesso e offre ai team IT visibilità e controllo senza creare difficoltà per gli utenti. 

Questa guida spiega nel dettaglio il significato di OAuth, come funziona e come utilizzarlo per proteggere l'accesso all'intera organizzazione, oltre a fornire uno o due esempi pratici di OAuth per metterlo in pratica.

Cos'è OAuth?

In sostanza, OAuth è un protocollo. Consente alle app di richiedere un accesso limitato ai dati utente ospitati da un altro servizio (come Google, Microsoft o GitHub). L'utente può approvare o rifiutare la richiesta.

In parole povere, l'autenticazione OAuth è un modo sicuro per consentire agli utenti di consentire alle app di accedere ai propri dati senza dover rivelare la propria password. Invece di fornire credenziali di accesso complete, gli utenti approvano l'accesso tramite un token. Il token agisce come un permesso, limitato ad azioni e dati specifici.

Ecco la semplice idea alla base: Sei tu a concedere l'accesso, non le tue credenziali.

Come funziona OAuth?

OAuth in pratica? Un utente può consentire a un'app di fitness di leggere i suoi passi dal proprio account Apple Salute, senza consentire all'app di modificare nulla o accedere a dati non correlati.

L'idea sembra semplice: consentire alle app di accedere ai dati senza dover fornire password. Ma come funziona l'autenticazione OAuth?

Ecco un esempio passo passo di OAuth basato su un caso comune: l'accesso a un'app di terze parti con Google:

1. L'app richiede l'accesso: Un utente apre l'app e clicca su "Accedi con Google". L'app reindirizza l'utente a Google con una richiesta di accesso a dati specifici (come email o contatti).

2. L'utente concede l'autorizzazione: Google mostra all'utente ciò che l'app richiede. L'utente accetta. Nessuna password viene condivisa con l'app.

3. L'app riceve un token: Una volta approvata, Google invia all'app un token sicuro. Questo token serve come prova che l'app ha l'autorizzazione ad accedere ai dati.

4. Il token viene utilizzato per l'accesso: L'app utilizza il token per recuperare i dati dell'utente da Google. Il token è limitato nel tempo, revocabile e con un ambito definito.

Ecco l'autenticazione OAuth in azione: semplice per l'utente, potente per la sicurezza.

Perché OAuth è importante per la sicurezza e il controllo degli accessi

Pensateci, le password non cambiano. Una volta scoperte, gli aggressori entrano subito.

Ma OAuth? Non è solo un altro metodo di accesso.

È un modo più intelligente per gestire fiducia, accesso e controllo in tempo reale, in tempo reale. Non si tratta solo di semplificarti la vita: è un vero e proprio upgrade della tua sicurezza.

Ecco perché l'autenticazione OAuth è importante:

1. Applicazione in tempo reale

I sistemi di accesso tradizionali non riescono a tenere il passo con le minacce in rapida evoluzione. OAuth consente di revocare l'accesso all'istante. Se un token sembra sospetto o il ruolo di un utente cambia, si blocca la porta in tempo reale, senza reimpostare la password o ritardi.

2. Configurazione remota

Con OAuth, le autorizzazioni non sono codificate in modo rigido. Sono configurate e fornite dai server di autorizzazione, il che significa che è possibile modificare gli ambiti, impostare la scadenza e aggiornare le policy centralmente. Il reparto IT non deve intervenire sugli endpoint per modificare l'accesso.

3. Filtraggio basato sulla posizione

OAuth si integra perfettamente con gli strumenti di sicurezza basati sulla posizione. Se le richieste di accesso provengono da regioni ad alto rischio o IP sconosciuti, è possibile negare o limitare l'emissione di token. Si tratta di un ulteriore livello di controllo contestuale integrato nel flusso.

4. Scalabilità

Con la crescita del tuo ambiente, i modelli di accesso statici non funzionano più. OAuth si adatta facilmente ad app, dispositivi e utenti. Un'unica identità può autorizzare molti servizi e le policy si applicano in modo coerente a tutti i livelli, senza creare problemi per l'IT o gli utenti finali.

Principali vantaggi di OAuth

OAuth è più di un semplice metodo di accesso. È un modo flessibile e sicuro per gestire l'accesso tra utenti, app e sistemi. Ecco perché è diventato lo standard per un'autorizzazione sicura e flessibile negli ambienti IT ibridi odierni.

• Controllo degli accessi granulare: Definisci esattamente a cosa possono accedere gli utenti o le app. In questo modo, un'app può leggere il tuo calendario, ma non le tue email.
• Meno password, migliore esperienza utente: Gli utenti concedono l'autorizzazione una sola volta. OAuth gestisce l'accesso sicuro, quindi non sono necessari accessi ripetuti o credenziali condivise.
• Costruito per la fiducia zero: Ssupporta controlli dei token in tempo reale, accesso contestuale e revoca.
• Sbarco facile: Revoca l'accesso all'istante senza toccare i dati di identità. Ideale per la gestione di fornitori, appaltatori e app temporanee.
• Funziona con i provider di identità: Si integra perfettamente con Entra ID, Google, Okta e altri, semplificando l'integrazione nel tuo stack esistente.

Casi d'uso comuni di OAuth

1. Accesso BYOD per team remoti:Un dipendente remoto accede a un'app aziendale da un dispositivo personale.

Flusso OAuth:

• Accedi utilizzando un provider di identità aziendale (ad esempio, Google Workspace o Entra ID)
• Approva l'accesso specifico dell'app a e-mail e calendario
• Token emesso con ambiti definiti (nessuna password memorizzata)

Usato per: Accesso sicuro e mirato agli strumenti di lavoro sui dispositivi BYOD.

2. Integrazioni SaaS di terze parti:Un team di marketing collega uno strumento di progetto al proprio CRM.

Flusso OAuth:

• Richiesta OAuth inviata al CRM (ad esempio, Salesforce)
• L'utente concede l'accesso in sola lettura ai dati dei lead
• Token emesso; l'app non vede mai le credenziali

Usato per: Concedere un accesso limitato alle app di terze parti senza il rischio di condivisione della password.

3. Controllo degli accessi contestuale: Un utente accede da una rete con restrizioni su un dispositivo non gestito.

Comportamento OAuth:

• Richiesta di accesso valutata in tempo reale
• Il dispositivo non è conforme; l'accesso è bloccato
• Azione registrata per audit

Usato per: Applicazione di policy Zero Trust e controlli di conformità.

4. Accesso del fornitore o dell'appaltatore: Un fornitore esterno ha bisogno temporaneamente di accedere agli strumenti interni.

Processo OAuth:

• Token con ambito emesso con accesso a tempo limitato
• Nessuna modifica apportata alla directory principale
• Accesso revocabile all'istante

Usato per: Accesso temporaneo e sicuro senza necessità di onboarding nei sistemi interni.

OAuth 1.0 vs OAuth 2.0: cosa è cambiato e perché è importante

Quando oggi si parla di autenticazione OAuth, ci si riferisce quasi sempre a OAuth 2.0. Ma il protocollo non è nato lì, e capire cosa è cambiato rispetto a OAuth 1.0 aiuta a spiegare perché OAuth 2.0 è diventato il punto di riferimento per un accesso sicuro e scalabile nelle app moderne.

Analizziamolo.

OAuth 1.0: sicuro ma rigido

OAuth 1.0, introdotto nel 2007, è stato progettato per consentire alle applicazioni di accedere ai dati utente su un altro servizio senza dover memorizzare nomi utente o password. L'idea di base, delegare l'accesso tramite un token, definisce ancora oggi il significato di OAuth.

Ma le specifiche originali presentavano alcune caratteristiche chiave:

• Ogni richiesta doveva essere firmata crittograficamente. Ciò ha aggiunto sovraccarico e complessità, soprattutto per le app basate su browser o dispositivi mobili.
• Il flusso era rigidamente strutturato. L'implementazione di OAuth 1.0 ha richiesto il rispetto di un rigido handshake articolato in più fasi, difficile da adattare alle diverse piattaforme.
• Nessun supporto integrato per le esigenze dell'esperienza utente moderna. Non esisteva un modo pulito per supportare elementi come token mobili, accesso di breve durata o terze parti fornitori di identità.

Chi usa ancora OAuth 1.0? Per lo più i sistemi legacy che non hanno ancora completato la transizione. Se si sta creando qualcosa di nuovo, raramente è rilevante.

OAuth 2.0 rende l'accesso sicuro più semplice, più intelligente e più scalabile

OAuth 2.0 è stato rilasciato nel 2012 come una riscrittura completa, non una revisione, delle specifiche originali. Ha affrontato molte delle sfide introdotte da OAuth 1.0, concentrandosi su:

• Implementazione semplificata: Niente più firme crittografiche. OAuth 2.0 si basa su HTTPS per la sicurezza del trasporto e utilizza token di connessione per l'accesso.
• Flussi di autorizzazione flessibili:OAuth 2.0 ha introdotto molteplici “tipi di concessione” per supportare una gamma più ampia di casi d’uso:
  • Codice di autorizzazione (per le app lato server)
  • Implicito (per le app basate su browser)
  • Credenziali del cliente (per la comunicazione macchina-macchina)
  • Password del proprietario della risorsa (ora obsoleta)
• Architettura basata su token: OAuth 2.0 utilizza token di accesso di breve durata e token di aggiornamento per migliorare la sicurezza e supportare sessioni a lungo termine senza accessi ripetuti.
• Estensibilità: OAuth 2.0 si integra facilmente con provider di identità, app mobili e servizi cloud. Ha anche gettato le basi per OpenID Connect (OIDC), che aggiunge l'autenticazione all'autorizzazione.

OAuth contro SAML contro OIDC contro FIDO2

Moderno identità e gestione degli accessi Non si tratta di scegliere un protocollo, ma di utilizzare lo strumento giusto per il lavoro giusto. Ecco come l'autenticazione OAuth si confronta con SAML, OIDC e FIDO2, e cosa offre (o non offre) ciascun protocollo negli ambienti IT reali.

OAuth vs. SAML: accesso delegato vs. identità centralizzata

SAML (Security Assertion Markup Language) è un protocollo basato su XML che consente agli utenti di effettuare l'accesso una sola volta (SSO) e di accedere a più applicazioni web. SAML è stato ampiamente adottato nei primi anni 2000 dalle aziende che utilizzavano sistemi IT tradizionali.

OAuth, d'altro canto, è un framework basato su token che consente alle app di accedere a dati utente limitati da altri servizi, senza esporre le password.

Intuizione: SAML si adatta ai portali legacy. OAuth supporta le app moderne. Offre un accesso sicuro, basato su token, progettato per dispositivi mobili, API e servizi come Google Workspace o Microsoft Graph.

OAuth vs. OpenID Connect (OIDC): accesso vs. identità

OAuth 2.0 è un protocollo di autorizzazione in senso stretto. Non verifica l'identità dell'utente, ma consente semplicemente alle app di accedere ai dati per conto dell'utente. OIDC (OpenID Connect) è un livello basato su OAuth 2.0 che aggiunge l'autenticazione, in modo che l'app non solo ottenga l'autorizzazione ad agire, ma sappia anche chi è l'utente.

Intuizione: Si pensi a OIDC come a OAuth 2.0 + identità. Si usa OAuth quando si desidera che un'app acceda alle risorse utente. Si usa OIDC quando l'app ha anche bisogno di sapere chi è l'utente; un'esigenza comune nei flussi di lavoro SSO.

OAuth vs. FIDO2: accesso tramite token vs. accesso senza password

FIDO2 è una categoria completamente diversa. Si concentra sull'autenticazione senza password, utilizzando la crittografia a chiave pubblica-privata e la sicurezza basata su hardware (come la biometria o le chiavi di sicurezza). Non è un sostituto di OAuth, ma un complemento.

Intuizione: FIDO2 ti aiuta ad accedere in modo sicuro. OAuth ti aiuta a controllare cosa puoi fare una volta entrato. Combina i due per un flusso end-to-end più solido: FIDO2 per l'autenticazione, OAuth per l'accesso limitato e revocabile.

Quando utilizzare ciascun protocollo

• OAuth consente un controllo degli accessi sicuro e basato su token per app e API, ma non verifica l'identità.
• OIDC aggiunge l'identità a OAuth: utilizzalo quando la tua app necessita sia di login che di accesso.
• SAML è efficace per gli ambienti SSO più vecchi, ma è meno adatto per i flussi di lavoro API-first e per dispositivi mobili.
• FIDO2 sostituisce le password, non le autorizzazioni. Abbinalo a OAuth o OIDC per una sicurezza end-to-end avanzata.

Scegliere il protocollo giusto per lo scopo giusto spesso significa utilizzare OAuth insieme ad altri per creare sistemi di accesso sicuri, scalabili e intuitivi.

Idee sbagliate comuni sull'autenticazione OAuth

1. OAuth serve per effettuare l'accesso.
   Realtà: OAuth gestisce l'autorizzazione, non l'autenticazione. Consente alle app di accedere ai dati, ma non di confermare l'identità di un utente.
2. OAuth e SSO sono la stessa cosa.
   La realtà: SSO verifica l'identità; OAuth concede l'accesso. Spesso lavorano insieme, ma perseguono scopi diversi.
3. OAuth sostituisce MFA.
   Realtà: OAuth non verifica gli utenti né aggiunge ulteriori livelli di sicurezza. Può supportare l'MFA, ma non la fornisce.
4. OAuth si comporta allo stesso modo su tutte le piattaforme.
   Realtà: ogni fornitore lo implementa in modo leggermente diverso. Gli ambiti, i flussi e la gestione dei token variano a seconda del sistema.
5. OAuth è sicuro per impostazione predefinita.
   Realtà: le configurazioni errate lo rendono rischioso. Token deboli o ambiti ampi possono esporre i dati se non configurati correttamente.

Mettere tutto insieme: OAuth, contesto e controllo con Scalefusion OneIdP

OAuth getta le basi per un'autenticazione moderna basata su standard. Ma non determina se il dispositivo è sicuro, la rete è affidabile o il comportamento dell'utente è in linea con le policy. Scalefusion OneIdP aggiunge questo contesto per integrare il tuo livello di sicurezza. 

L'accesso è gestito da OAuth. Le policy Zero Trust determinano se l'accesso può essere effettuato. 

Valutando ogni richiesta di token in base a segnali di contesto live come:

• Stato del dispositivo e conformità MDM
• Reputazione IP e geolocalizzazione
• Modelli di comportamento basati sui ruoli

Questo approccio contestuale consente OneIdP per consentire, limitare o revocare l'accesso, anche dopo l'autenticazione avvenuta con successo.

Collegando i token OAuth ad ambienti verificati e conformi alle policy, OneIdP applica l'accesso condizionale senza aggiungere ostacoli. Semplifica le configurazioni complesse ed elimina la dipendenza da metodi di autenticazione obsoleti.

Se la tua attuale configurazione OAuth si ferma all'accesso, non è Zero Trust. OneIdP colma questa lacuna con precisione, scalabilità e sicurezza integrate.

Domande Frequenti

1. Quando utilizzare OAuth?

Utilizza OAuth quando hai bisogno di un accesso delegato sicuro alle risorse utente senza condividere le password. È ideale per autorizzare app di terze parti, client mobili o web e API ad accedere ai dati per conto degli utenti. L'autenticazione OAuth garantisce un controllo granulare delle autorizzazioni, riduce al minimo l'esposizione delle credenziali e supporta flussi di lavoro moderni come Single Sign-On e accesso BYOD.

2. Che cos'è OAuth nella REST API?

OAuth nelle API REST è un protocollo che garantisce un accesso sicuro e limitato alle risorse API tramite token anziché password. L'autenticazione OAuth consente alle API REST di verificare le autorizzazioni dei client prima di consentire l'accesso ai dati. Ciò significa che le app possono interagire con le API per conto degli utenti in modo sicuro, utilizzando token di accesso che ne controllano l'ambito e la scadenza.

3. Che cosa è OAuth e SAML?

OAuth e SAML sono entrambi framework di autorizzazione, ma OAuth si concentra sull'accesso delegato (autorizzazione) principalmente per API e app mobili. SAML è un protocollo basato su XML principalmente per il Single Sign-On (autenticazione) nelle applicazioni web aziendali. OAuth non fornisce asserzioni di identità, mentre SAML fornisce l'autenticazione dell'utente e le informazioni sugli attributi.

4. Qual è la differenza tra OAuth e JWT?

OAuth è un protocollo di autorizzazione che emette token per l'accesso delegato, mentre JWT (JSON Web Token) è un formato di token compatto spesso utilizzato all'interno di OAuth. JWT contiene informazioni codificate come l'identità dell'utente e gli ambiti del token. OAuth può utilizzare JWT come token di accesso o ID, ma JWT di per sé non è un protocollo di autenticazione o autorizzazione.