Autorizzazione delle app: guida per sviluppatori nel 2026

Probabilmente ci stai già facendo i conti. Il login dell'app funziona, gli utenti possono accedere con Google, Microsoft o email e API accetta un token. A quel punto iniziano i dubbi: questo utente può vedere le fatture di un altro account? L'app desktop deve salvare l'access token localmente? Come si gestisce il consenso in un build Capacitor senza far trapelare lo stato tra webview e layer nativo?

È qui che l'app authorization smette di essere una semplice checklist e inizia a influenzare la fiducia nel prodotto, la gestione degli incidenti e l'esito delle review sugli app store. Nelle app cross-platform, specialmente con Capacitor ed Electron, la parte difficile non è capire il concetto di authorization. È implementarlo in contesti dove le assunzioni del browser non valgono più, lo storage sicuro si comporta diversamente per piattaforma e le scorciatoie sul client creano rischi lato server.

Indice dei contenuti

• Cosa significa davvero l'autorizzazione delle app
• I componenti fondamentali dell'autorizzazione
  • La tessera dell'hotel è un buon modello mentale
  • I termini che contano nei sistemi reali
• Modelli e protocolli di autorizzazione comuni
  • I protocolli gestiscono la conversazione
  • I modelli gestiscono la logica decisionale
  • RBAC vs. ABAC a confronto
• Anatomia di un flusso OAuth 2.0
  • Cosa succede quando l'utente tocca login
  • Dove solitamente si rompono le app cross-platform
• Minacce alla sicurezza e best practice essenziali
  • Gli errori che continuano a presentarsi
  • Una checklist pratica ed efficace
• Pattern di implementazione per Capacitor ed Electron
  • Pattern Capacitor che funzionano
  • Pattern Electron che richiedono particolare attenzione
• La tua guida all'autorizzazione sicura delle app

Cosa significa davvero l'autorizzazione delle app

Un utente installa la tua app, clicca su “Continua con Google”, effettua l'accesso e visualizza una schermata di consenso che chiede se l'app può leggere i contatti o il calendario. Quel momento racchiude le due facce dell'accesso: il sign-in conferma l'identità, mentre la schermata di consenso definisce cosa l'app può fare una volta identificata l'identità.

Questa distinzione manda ancora in confusione molti team. Autenticazione dimostra chi è l'utente. Autorizzazione decide cosa può accedere quell'utente, sessione o app. Un ID ti permette di entrare nell'edificio; una chiave determina quali porte si aprono.

Nello sviluppo di app, questa differenza è cruciale perché spesso i team mettono in sicurezza il flusso di login, ma trascurano tutto ciò che segue. Si fidano troppo di un token, saltano i controlli dei permessi lato server o lasciano che sia il client a gestire regole di accesso che dovrebbero essere definite nelle policy. È così che il concetto di “utente loggato” si trasforma sottilmente in “utente con troppi permessi”.

L'autorizzazione è il momento in cui la fiducia diventa concreta. Agli utenti non interessa solo che l'app sappia chi sono, ma che acceda solo a ciò che hanno approvato.

Ci sono tre attori da distinguere:

• L'utente che effettua l'accesso e può fornire il consenso.
• L'applicazione che richiede l'accesso per conto dell'utente.
• Il proprietario della risorsa o API che protegge i dati e applica la decisione.

In pratica, l'autorizzazione delle app si sovrappone anche a controlli di accesso più stringenti come l'MFA. A gennaio 2023, circa il 66% degli utenti a livello globale usava l'MFA, e l'83% di oltre 1.000 professionisti IT di PMI intervistati richiedeva l'MFA per l'accesso a tutte le risorse aziendali in un sondaggio JumpCloud del 2024 according to Riepilogo delle statistiche MFA di JumpCloud. Questo non sostituisce l'autorizzazione, ma alza l'asticella per chi può richiedere l'accesso.

Se il tuo team sta definendo ruoli, scope e accessi delegati, questa guida su come l'RBAC protegge gli aggiornamenti OTA nelle app Capacitor è un ottimo supporto alle scelte di implementazione discusse qui.

I componenti fondamentali dell'autorizzazione

L'autorizzazione diventa molto più semplice se smetti di considerarla come una 'magia' dentro un token. Un modello mentale migliore è quello di un hotel.

La tessera dell'hotel è un buon modello mentale

Un ospite va alla reception e mostra un documento. L'hotel verifica l'identità, crea una prenotazione e rilascia una tessera magnetica. Quella tessera non prova chi sia l'ospite ogni volta che si apre una porta; contiene semplicemente il permesso di accedere a determinati luoghi per un periodo limitato.

La tua app funziona esattamente allo stesso modo.

Il punto fondamentale è che la tessera non è la policy, ma la riflette. Le porte hanno comunque bisogno di un sistema che verifichi se la tessera debba aprire quella specifica serratura. Nel software, questo corrisponde al tuo gateway API, al middleware del backend, al policy engine o allo strato di autorizzazione a livello di servizio.

I termini che contano nei sistemi reali

Principale
L'attore che richiede l'accesso. Di solito un utente, ma può essere anche un dispositivo, un job in background o un service account.

Risorsa
L'elemento da proteggere. Un progetto, una fattura, una route admin, un file, un endpoint API o un singolo record in un database.

Ambito
L'insieme delle azioni richieste. Leggere il profilo. Fare upload di file. Gestire il billing. Gli scope dovrebbero essere ristretti e chiari.

Consenso
L'approvazione dell'utente per un livello di accesso richiesto. Le buone schermate di consenso rendono la richiesta leggibile. Quelle pessime chiedono tutto.

Token di accesso
Le credenziali che il client presenta a un resource server dopo il completamento dell'autorizzazione. Devono essere trattate come dati sensibili.

Molti errori di implementazione nascono dal ridurre tutto a un'unica assunzione: "l'utente ha un token, quindi facciamolo entrare". In produzione non regge. Un token può essere valido ma comunque sbagliato per l'azione, il tenant, l'ambiente o la risorsa correnti.

Per i team mobile e desktop, la gestione dei token merita particolare attenzione perché lo storage fa parte del sistema di autorizzazione, che tu voglia o no. Se il client archivia gli artefatti di accesso con leggerezza, il design della policy non ti salverà in seguito. Questa guida su lo storage sicuro dei token per sviluppatori mobile merita una revisione prima del rilascio.

Una regola duratura è semplice: tieni separati autenticazione, consenso, emissione dei token e enforcement lato server, nella testa e nel tuo code. I team che li uniscono di solito finiscono per debuggare bug di permessi nel layer sbagliato.

Modelli e protocolli di autorizzazione comuni

Quando i team dicono “usiamo OAuth”, spesso intendono più cose diverse insieme. È parte della confusione. Protocolli e modelli di autorizzazione risolvono problemi diversi.

I protocolli gestiscono la conversazione

OAuth 2.0 riguarda principalmente l'autorizzazione delegata. Definisce come un'app può richiedere e ottenere il permesso di agire per conto di un utente senza gestire direttamente la sua password.

OpenID Connect, o OIDC, si appoggia su OAuth 2.0 e aggiunge informazioni sull'identità. In termini pratici, OAuth risponde a “cosa può fare questa app”, mentre OIDC aiuta a rispondere a “chi ha effettuato l'accesso”.

Questa differenza conta nelle app Capacitor e Electron, perché molti bug nascono dall'usare un ID token dove ci si aspetta un access token, o dal dare per scontato che un login riuscito significhi che il API debba concedere ogni azione a valle. Non dovrebbe.

Se stai integrando tutto questo in un'app ibrida, una guida passo dopo passo all'implementazione di OAuth2 per app Capacitor è la risorsa ideale per evitare errori di flusso evitabili.

I modelli gestiscono la logica decisionale

All'interno del tuo sistema, servono comunque delle regole per decidere se concedere l'accesso. È qui che entrano in gioco RBAC e ABAC e.

Controllo accessi basato su ruoli (RBAC) mappa i permessi su ruoli come admin, editor, supporto o viewer. È molto usato perché è intuitivo, verificabile e stabile. Secondo l'analisi di BrightSec su autenticazione e autorizzazione sicura, L'RBAC è lo standard di settore per gestire permessi granulari, e le evidenze dimostrano che implementare l'RBAC con strutture gerarchiche e audit regolari riduce gli incidenti di sicurezza fino al 40% in ambito enterprise.

Controllo degli accessi basato sugli attributi (ABAC) prende decisioni basandosi sugli attributi anziché solo sui ruoli. Questi possono includere dipartimento, stato del dispositivo, proprietà del record, tier dell'account, area geografica, orario della richiesta o l'esito dell'MFA. L'ABAC è più espressivo, ma rischia di diventare opaco se la policy non è ben documentata.

Regola pratica: Inizia con l'RBAC quando i permessi del prodotto sono stabili e leggibili. Aggiungi l'ABAC dove il contesto influisce realmente sulla decisione.

RBAC vs. ABAC a confronto

Non c'è un premio per aver scelto il modello più avanzato. La scelta migliore è quella che il tuo team può applicare con coerenza. Nella maggior parte dei codebase, questo significa usare l'RBAC per i confini di accesso generali e attributi mirati per eccezioni come ownership, tenant o stato del dispositivo.

Anatomia di un flusso OAuth 2.0

Molte spiegazioni su OAuth rimangono troppo astratte. In un'app reale, la sequenza è fondamentale, specialmente per client pubblici come Capacitor e app Electron che non possono gestire in sicurezza un client secret.

Cosa succede quando l'utente tocca login

Un utente apre la tua app Capacitor e tocca “Login con GitHub”. L'app crea un PKCE code verifier e un code challenge derivato, quindi reindirizza l'utente al server di autorizzazione tramite browser di sistema o una scheda sicura. L'app include anche lo stato per verificare che la risposta appartenga alla richiesta avviata.

Al server di autorizzazione, l'utente effettua il login se necessario e approva l'accesso richiesto. Il server reindirizza quindi con un code di autorizzazione, non con una credenziale a lunga durata da usare direttamente. La tua app riceve quel code tramite la redirect URI configurata.

L'app scambia quindi il code con i token. Il PKCE è fondamentale in questo processo. L'app invia il code verifier originale insieme al code di autorizzazione. Il server lo confronta con la code challenge precedente. Se corrispondono, lo scambio di token ha successo. Se qualcuno intercetta il code ma non ha il verifier, lo scambio fallisce.

Ecco perché il PKCE è essenziale per i client nativi e ibridi. Queste app sono client pubblici. Bisogna dare per scontato che gli attaccanti possano ispezionare i bundle, fare reverse engineering dei percorsi code o manomettere lo stato locale. Il PKCE riduce uno dei rischi più comuni nei flussi basati su redirect.

Ecco una breve guida se vuoi un ripasso visivo prima di implementare la sequenza in code:

Dove solitamente si rompono le app cross-platform

Il protocollo è semplice. L'implementazione spesso non lo è.

Le app Capacitor di solito falliscono in uno di questi punti:

1. Usare una webview incorporata per il sign-in invece del browser di sistema. Questo può compromettere il perimetro di sicurezza previsto e creare un comportamento incoerente dei cookie.
2. Perdere lo stato del redirect quando l'app riprende dal browser e torna nella native shell.
3. Salvare i token nel browser storage in chiaro perché il progetto è nato come web app e il team non ha mai rivisto la gestione dello storage per il mobile.

Le app Electron presentano problemi diversi. Spesso i team lasciano troppa logica di auth al renderer process, espongono token tramite IPC senza confini netti o trattano l'app desktop come un ambiente attendibile. Non lo è. Un'app desktop pacchettizzata richiede comunque un approccio da client ostile.

Anche il comportamento del refresh merita una progettazione attenta. Gli access token dovrebbero scadere, le sessioni dovrebbero ripristinarsi correttamente e la logica di refresh non dovrebbe creare race condition tra più richieste concorrenti. Questa guida al flusso sicuro di refresh dei token è un riferimento solido per implementare quella parte senza finire in un loop di retry o in un pasticcio di sessioni obsolete.

C'è un'abitudine di implementazione che aiuta più di molte altre: isola l'handshake OAuth in un piccolo modulo di auth con input e output espliciti. Non sparpagliare la gestione dei redirect, il parsing dei token e la logica di refresh tra componenti, hook e utility di rete a caso.

Minacce alla sicurezza e best practice essenziali

I bug di autorizzazione raramente sembrano drammatici durante la review di code. Sembrano semplici comodità. Uno scope troppo ampio qui, un token in cache lì, un controllo lato server mancante perché l'UI nasconde già il bottone. Poi l'app viene rilasciata e quelle scorciatoie diventano la superficie d'attacco.

Gli errori che continuano a presentarsi

L'ecosistema mobile offre un segnale d'allarme utile. Secondo le statistiche sulla sicurezza mobile di DeepStrike, il 95% delle app mobile testate ha fallito almeno un controllo OWASP MASVS relativo ad autenticazione e autorizzazione, e L'85% delle app mobile analizzate presentava falle di sicurezza. Non serve accettare ogni narrazione del marketing sulla sicurezza per prendere sul serio il problema. Gli errori di autorizzazione sono comuni.

Gli schemi sono familiari:

• Token trapelati da storage non sicuri, log, crash report o stati accessibili al renderer.
• Scope troppo ampi perché richiedere tutto subito è più facile che gestire il consenso nel tempo.
• Controllo lato client dove l'app nasconde le azioni non autorizzate, ma il API le accetta comunque.
• Attacchi di replay e redirect quando la validazione di stato, PKCE o redirect URI è approssimativa.
• Deriva delle autorizzazioni dopo che i team aggiungono ruoli ed eccezioni senza una revisione pianificata.

Se il tuo backend non verifica l'autorizzazione per ogni azione protetta, non hai un'autorizzazione dell'app. Hai solo suggerimenti nell'UI.

Una checklist pratica ed efficace

Usa il principio del minimo privilegio come default, non come attività di pulizia successiva. Nei progetti reali, significa ridurre ciò che ogni token può fare, dove ogni token risiede e quanto a lungo ogni credenziale rimane valida.

• Richiedi scope ristretti: Chiedi solo i permessi necessari per la feature che l'utente sta usando in questo momento. Se l'app può posticipare il consenso, fallo.
• Applica i controlli sul server: Considera il client come non affidabile. Bottoni, rotte e schermate nascoste non sono confini di sicurezza.
• Usa lo storage sicuro della piattaforma: Su mobile, usa l'accesso nativo a keychain o keystore tramite un plugin invece del semplice local storage. Su desktop, tieni i dati sensibili fuori dalla portata del renderer.
• Valida lo stato e la gestione dei redirect: La risposta di auth deve corrispondere alla richiesta avviata dalla tua app.
• Scadenza aggressiva e refresh accurato: Gli access token a breve durata limitano i danni in caso di leak. La logica di refresh deve ruotare correttamente e fallire in modalità sicura.
• Revoca quando necessario: La terminazione della sessione e l'incident response devono includere la possibilità di invalidare i token e forzare la re-autenticazione.
• Valida gli input e proteggi il trasporto: HTTPS, certificate pinning dove opportuno e validazione degli input sono fondamentali, poiché l'autorizzazione può essere bypassata tramite vulnerabilità adiacenti.

Per i team che pubblicano app sugli store, il design dell'auth incrocia anche l'esposizione di API e la compliance review. Questo riepilogo di standard di sicurezza API per la compliance degli app store si integra perfettamente con la tua checklist di autorizzazione.

Un ultimo punto facile da trascurare. Il principio del minor privilegio si applica anche agli strumenti interni. Admin panel, console di supporto e app di staging finiscono spesso con i controlli più permissivi, anche se espongono le azioni più sensibili.

Pattern di implementazione per Capacitor ed Electron

L'autorizzazione delle app cross-platform diventa più semplice quando smetti di fingere che la tua app sia solo un browser con un packaging extra. Sia Capacitor che Electron richiedono pattern che rispettino lo storage nativo, i confini dei processi e la gestione dei redirect.

Pattern Capacitor che funzionano

Per Capacitor, usa un plugin o una libreria di auth che supporti OAuth tramite system-browser con PKCE e un corretto callback via deep-link o app-link. Librerie come capacitor-oauth2 possono eliminare molto codice di raccordo in code, ma solo se mantieni espliciti lo storage dei token e il comportamento di refresh.

Una struttura pratica è la seguente:

• Coordinatore dell'autenticazione: Avvia il login, traccia lo stato e gestisce il callback.
• Servizio token: Memorizza i token tramite secure storage nativo, non tramite browser storage.
• Client API: Allega gli access token, effettua un retry al refresh e forza il sign-out in caso di errore irrecuperabile.
• Backend consapevole delle policy: Mappa i token claim ai controlli di autorizzazione lato server.

Ti serve anche un sistema di gestione sessioni adatto al ciclo di vita di un'app ibrida. Se stai valutando delle opzioni per questo layer, i plugin Capacitor per la gestione sicura delle sessioni è un ottimo punto di confronto tra i vari approcci.

Ecco un esempio di pseudocodice per un refresh token minimale:

async function authorizedFetch(request) {
  let token = await tokenStore.getAccessToken()
  let response = await api(request, token)

  if (response.status !== 401) return response

  const refreshed = await auth.refresh()
  if (!refreshed) {
    await auth.signOut()
    throw new Error('Session expired')
  }

  token = await tokenStore.getAccessToken()
  return api(request, token)
}

La parte importante non è la sintassi. È mantenere il refresh centralizzato, evitando che ogni schermata inventi il proprio comportamento della sessione.

Pattern Electron che richiedono particolare attenzione

Electron richiede confini più rigidi. Quando possibile, tieni lo scambio dei token e lo storage sicuro nel main process. Esponi metodi IPC limitati al renderer, invece di passargli i token in chiaro sperando che si comporti bene.

Le app desktop sembrano più controllabili rispetto a quelle mobile. Considera questa sensazione come un rischio, non come una garanzia.

Evita queste scorciatoie:

• Non salvare i token nel local storage accessibile dal renderer se riesci a evitarlo.
• Don’t let every window share broad auth context senza verificare lo scopo della window e la durata della sessione.
• Non fidarti eccessivamente degli preload script come sostituto dell'isolamento dei processi e dei confini espliciti di API.

Anche la visibilità operativa è fondamentale. Secondo la panoramica di Splunk sui requisiti di sicurezza applicativa, l'autorizzazione delle app dovrebbe essere integrata con il monitoraggio continuo delle attività e il logging; i dati di riferimento citati indicano che le organizzazioni che loggano e monitorano proattivamente gli eventi di autorizzazione rilevano il 95% dei tentativi di accesso non autorizzati entro 15 minuti. In pratica, significa loggare azioni negate, fallimenti nel refresh dei token, cambi di ruolo, revoche del consenso e pattern di accesso insoliti alle risorse.

Se il tuo processo di rilascio include aggiornamenti di app ibride, un'opzione in questo ecosistema è Capgo, che fornisce live update firmati per le app Capacitor ed Electron. Non implementa l'autorizzazione al posto tuo, ma influisce sulla velocità con cui puoi rilasciare fix quando la logica di auth, la gestione dei redirect o la code della sessione richiedono una correzione urgente.

La tua guida all'autorizzazione sicura delle app

Una buona autorizzazione delle app non è una singola decisione. È una catena di decisioni che devono reggere insieme. Autentichi correttamente l'utente, richiedi solo l'accesso necessario, scambi i token tramite un flusso sicuro come OAuth 2.0 con PKCE, memorizzi i secret nel posto giusto e applichi i permessi sul server ogni volta.

La parte più importante per i team Capacitor ed Electron è la disciplina ai margini. Le scorciatoie dell'era browser non sopravvivono al contatto con lo storage nativo, i deep link, i confini dei processi desktop o i requisiti di app review. I team che restano fuori dai guai di solito non fanno nulla di esotico. Sono solo coerenti su scope, gestione delle sessioni, controlli lato server e auditabilità.

Se il tuo attuale setup di auth sembra intricato, è normale. Inizia stringendo un confine alla volta. Sistema il flow. Sistema lo storage. Sposta le regole di accesso fuori dalla UI. Aggiungi logging per sapere quando qualcuno richiede qualcosa che non dovrebbe avere.

Ecco come l'autorizzazione sicura delle app diventa gestibile. Non più semplice in teoria, ma più sicura in code.

Capgo aiuta i team a rilasciare fix per app Capacitor ed Electron senza attendere la revisione degli store, fondamentale quando serve correggere rapidamente auth flow, gestione dei token o bug di sessione. Se il tuo team cerca un controllo maggiore su release cross-platform, rollout mirati e supporto per il rollback, Capgo vale la pena valutarlo insieme al tuo stack di autorizzazione dell'app.