---
term: 'Gestione delle identità e degli accessi (IAM)'
seoTitle: 'IAM: gestione delle identità, pilastri, standard, ciclo di vita'
headline: 'Che cos''è l''IAM (gestione delle identità e degli accessi)?'
slug: iam
category: auth-security
shortDefinition: 'L''IAM è un framework di policy e tecnologie che garantisce agli utenti giusti il giusto accesso alle risorse giuste al momento giusto.'
relatedTerms:
  - role-based-access-control-rbac
  - oauth-2-social-login
  - multi-factor-authentication-mfa
  - json-web-token-jwt
contrastsWith:
  - role-based-access-control-rbac
aboutTerms:
  - 'Identity Provider (IdP)'
  - 'Single Sign-On (SSO)'
  - 'Identity Lifecycle'
  - 'CIAM'
faq:
  - question: 'Che cos''è l''IAM in parole semplici?'
    answer: 'La disciplina che gestisce chi può accedere a che cosa: dimostrare che gli utenti sono chi dichiarano di essere (autenticazione), decidere che cosa è loro permesso fare (autorizzazione), gestire gli account dalla creazione alla rimozione (ciclo di vita) e tenere traccia di tutto (audit). Risponde a "chi è?" e "che cosa gli è permesso fare?" per ogni richiesta.'
  - question: 'Qual è la differenza tra autenticazione e autorizzazione?'
    answer: 'L''autenticazione verifica l''identità di chi accede – credenziali, codici, biometria. L''autorizzazione decide che cosa gli è permesso fare – ruoli, permessi, policy. Versione aeroportuale: il controllo passaporti contro la carta d''imbarco. L''autenticazione viene sempre per prima; l''autorizzazione gira su ogni azione successiva.'
  - question: 'Quali sono i componenti di un sistema IAM?'
    answer: 'Un identity store (la directory degli utenti), i servizi di autenticazione (password, MFA, single sign-on), la meccanica di autorizzazione (ruoli, permessi, ACL), gli strumenti per il ciclo di vita (provisioning e deprovisioning) e il log di audit. Ogni sistema reale li ha tutti e cinque, assemblati a mano o ereditati da una piattaforma.'
  - question: 'Che cos''è un identity provider (IdP)?'
    answer: 'Il sistema che possiede le identità e ne fa garanzia: autentica l''utente ed emette token o assertion firmati – tramite OpenID Connect o SAML – di cui le altre applicazioni si fidano. Ogni pulsante "Accedi con…" è un IdP all''opera; le aziende ne gestiscono uno proprio per il single sign-on dei dipendenti.'
  - question: 'Che cos''è il single sign-on (SSO)?'
    answer: 'Autenticarsi una volta sola presso l''identity provider e poi accedere a molte applicazioni senza nuovi login – ogni app si fida dell''assertion dell''IdP invece di detenere credenziali proprie. Meno password, un unico posto in cui imporre l''MFA, un unico interruttore per tagliare l''accesso in ogni punto.'
  - question: 'Che cosa sono il provisioning e il deprovisioning?'
    answer: 'I verbi del ciclo di vita: il provisioning crea l''account e concede i diritti quando qualcuno entra o cambia ruolo; il deprovisioning li revoca all''uscita. Sono automatizzati tramite standard come SCIM. Un deprovisioning mancato lascia account orfani – da sempre uno dei primi rilievi di audit e un appiglio preferito dagli attaccanti.'
  - question: 'Qual è la differenza tra IAM workforce e CIAM?'
    answer: 'Pubblico e priorità. L''IAM workforce gestisce i dipendenti – migliaia di utenti, controlli imposti dall''IT, privilegio minimo e conformità al primo posto. Il Customer IAM (CIAM) gestisce gli utenti di un''applicazione – potenzialmente milioni, registrazione self-service, login social, dove guidano UX, conversione e consenso privacy. La maggior parte di chi sviluppa app sta costruendo CIAM, che la parola venga usata o no.'
  - question: 'Che rapporto c''è tra IAM e zero trust?'
    answer: 'Lo zero trust – mai fidarsi, verificare sempre – sostituisce il perimetro di rete con l''identità: ogni richiesta viene autenticata e autorizzata indipendentemente da dove arriva. L''IAM è la macchina che rende tutto questo possibile, ed è per questo che "l''identità è il nuovo perimetro" è diventato lo slogan della disciplina.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'NIST SP 800-63-4 — Digital Identity Guidelines'
    url: 'https://pages.nist.gov/800-63-4/'
  - name: 'NIST Identity & Access Management program'
    url: 'https://www.nist.gov/identity-access-management'
  - name: 'OpenID Connect Core 1.0'
    url: 'https://openid.net/specs/openid-connect-core-1_0.html'
  - name: 'RFC 7644 — SCIM Protocol'
    url: 'https://datatracker.ietf.org/doc/html/rfc7644'
  - name: 'Identity and access management — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Identity_and_access_management'
cta:
  title: 'IAM a livello di app, già assemblato'
  text: 'Back4app ti consegna dal primo giorno i mattoni IAM che servono alla tua app – user store, sessioni, ruoli, ACL, verifica dell''e-mail, login social, MFA – applicati dalla piattaforma a ogni richiesta.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-14'
translationKey: identity-access-management-iam
---

**L'IAM è un framework di policy e tecnologie che garantisce agli utenti giusti il giusto accesso alle risorse giuste al momento giusto.** L'Identity & Access Management è la disciplina che sta dietro a ogni casella di login e a ogni controllo dei permessi – con una disambiguazione da fare subito: i grandi provider cloud distribuiscono anche *prodotti* chiamati "IAM" per controllare l'accesso alla propria infrastruttura; quelli sono implementazioni di questa disciplina, non la sua definizione. Questo articolo copre la disciplina – compresa la versione che chi sviluppa app costruisce o eredita, di solito senza chiamarla IAM.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| I quattro pilastri | Autenticazione · autorizzazione · ciclo di vita · audit |
| Lo slogan | Le persone giuste, l'accesso giusto, le risorse giuste, al momento giusto |
| I due mondi | IAM workforce (dipendenti, conformità) · CIAM (gli utenti dell'app, UX) |
| Gli standard | OIDC e OAuth per i token · SAML per l'SSO aziendale · SCIM per il ciclo di vita · WebAuthn per le credenziali |
| La versione di chi sviluppa | User store + sessioni + ruoli + ACL + recupero – da costruire o da ereditare |

## Il ciclo di vita dell'identità: ingresso, mobilità, uscita

Il lavoro quotidiano dell'IAM è un giro che ogni account compie, e si traduce in operazioni concrete:

```text
INGRESSO creare l'identità → verificare l'e-mail → emettere credenziali/sessione
         (provisioning – automatizzato via SCIM nei sistemi workforce)
MOBILITÀ cambi di ruolo · cambi di team · concessioni e revoche di permessi
         (l'autorizzazione segue i ruoli: una mobilità è un aggiornamento di dati)
USCITA   revocare le sessioni SUBITO → disabilitare l'account → cancellare o anonimizzare
         (deprovisioning – i passaggi saltati diventano "account orfani",
          il rilievo di audit che continua a comparire nei report sulle violazioni)
```

Lo stesso giro sotto forma di chiamate API:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret, email: 'ada@example.com' });

// Move: authorization follows roles, not people
editors.getUsers().add(user);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
final user = ParseUser('ada', secret, 'ada@example.com');
await user.signUp();

// Move: authorization follows roles, not people
editors.addRelation('users', [user]);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
var user = User()
user.username = "ada"
user.password = secret
user.email = "ada@example.com"
let signedUp = try await user.signup()

// Move: authorization follows roles, not people
try await editors.users.add([signedUp]).save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.email = "ada@example.com"
user.signUp()

// Move: authorization follows roles, not people
editors.users.add(user)
editors.save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)
```

## Autenticazione vs. autorizzazione

La distinzione su cui poggia tutta la disciplina:

| | Autenticazione (AuthN) | Autorizzazione (AuthZ) |
| --- | --- | --- |
| Domanda | Chi è l'utente? | Che cosa gli è permesso fare? |
| Prove | Credenziali, codici [MFA](/glossary/it/autenticazione-multifattore-mfa/), biometria, passkey | Ruoli, permessi, [ACL](/glossary/it/liste-di-controllo-degli-accessi-acl/), policy |
| Quando avviene | Una volta per sessione | A ogni azione |
| Produce | Una sessione o un [token](/glossary/it/json-web-token-jwt/) | Un consenti/nega per richiesta |
| Fallisce come | Furto dell'account | Escalation dei privilegi, esposizione di dati |

Versione aeroportuale, una volta sola: il controllo passaporti contro la carta d'imbarco. Poi la versione ingegneristica, che conta di più: l'autenticazione *produce l'identità* che una sessione porta con sé; l'autorizzazione la *consuma* a ogni richiesta successiva – ed è per questo che le due falliscono in modo diverso e si irrigidiscono separatamente.

```mermaid
flowchart LR
  accTitle: Flusso di una richiesta IAM attraverso i quattro pilastri
  accDescr: Un utente si autentica presso l'identity store e riceve una sessione. Ogni richiesta viene poi autorizzata contro ruoli e permessi prima di raggiungere le risorse, mentre la gestione del ciclo di vita governa l'esistenza dell'account e il log di audit registra gli eventi di autenticazione e autorizzazione.
  U["Utente"] -->|"credenziali + MFA"| AN["Autenticazione<br/>identity store · IdP"]
  AN -->|"sessione / token"| AZ["Autorizzazione<br/>ruoli · permessi · ACL"]
  AZ --> R[("Risorse")]
  L["Ciclo di vita<br/>ingresso · mobilità · uscita"] -.->|"governa gli account"| AN
  AN -.-> AU["Audit<br/>chi ha fatto cosa, e quando"]
  AZ -.-> AU
```

## I quattro pilastri – e le tre lettere del mercato

L'anatomia funzionale: **autenticazione** (dimostrare l'identità – password, MFA, SSO, autenticazione senza password), **autorizzazione** (decidere le azioni – [ruoli](/glossary/it/controllo-degli-accessi-rbac/), permessi, regole sugli oggetti), **ciclo di vita** (il giro ingresso/mobilità/uscita) e **audit** (il quarto, cronicamente sottovalutato: log, revisioni degli accessi e la capacità di rispondere a "chi poteva leggere questo, e chi l'ha letto?"). Il mercato dei vendor taglia lo stesso territorio in segmenti che si incontrano in fase di acquisto: **AM** (access management – accesso, SSO, MFA), **IGA** (governance – certificazioni, separazione dei compiti, il livello del "dovrebbero averlo?" sopra l'operativo "possono averlo?") e **PAM** (accessi privilegiati – vaulting ed elevazione just-in-time per gli account la cui compromissione significa fine della partita). Stessa disciplina, due mappe.

## Lo stack degli standard

La zuppa di acronimi, risolta in mansioni – la tabella che le pagine in classifica non forniscono mai:

| Standard | Che cosa fa | Dove si incontra |
| --- | --- | --- |
| [OAuth 2.0](/glossary/it/oauth-2-login-social/) | Autorizzazione delegata – token con ambito invece di password condivise | Accesso alle API, l'impianto sotto il login social |
| OpenID Connect | Autenticazione sopra OAuth – ID token firmati che asseriscono chi ha fatto l'accesso | Ogni pulsante "Accedi con…", l'SSO moderno |
| SAML 2.0 | Assertion di federazione in XML – il fratello maggiore aziendale di OIDC | Integrazioni SSO aziendali |
| SCIM | API standard per il provisioning e il deprovisioning degli account | Automazione del ciclo di vita workforce |
| WebAuthn / FIDO2 | Credenziali a chiave pubblica resistenti al phishing | Passkey, chiavi di sicurezza hardware |
| [JWT](/glossary/it/json-web-token-jwt/) | Il formato di token in cui viaggiano le assertion | ID token, access token |
| LDAP | Protocollo di interrogazione delle directory | Identity store legacy |

## IAM workforce vs. CIAM

| | IAM workforce | Customer IAM (CIAM) |
| --- | --- | --- |
| Utenti | Dipendenti, collaboratori esterni – migliaia | Gli utenti dell'app – fino a milioni |
| Onboarding | Il provisioning lo fa l'IT | Registrazione self-service – l'attrito uccide la conversione |
| Autenticazione | SSO aziendale, MFA obbligatoria | Login social, autenticazione senza password, MFA opzionale |
| Priorità | Privilegio minimo, conformità | UX, conversione, consenso privacy |
| Ciclo di vita | Ingresso/mobilità/uscita guidati dall'HR | Registrazione/attività/abbandono/cancellazione guidati dall'utente |
| Chi compra | IT e sicurezza | Il team di prodotto – spesso lo si *costruisce*, non lo si compra |

La distinzione si guadagna la tabella perché i contenuti in classifica sono scritti quasi tutti sulla colonna di sinistra, mentre la maggior parte di chi sviluppa e legge un glossario sta costruendo quella di destra: flussi di registrazione, gestione delle sessioni e recupero dell'account per gli utenti di un'app *sono* CIAM – la disciplina si applica anche quando nessuno nella stanza usa l'acronimo.

## Casi d'uso tipici

- **Gestione degli utenti di un'app** – registrazione, verifica, sessioni, ruoli, cancellazione: CIAM come lavoro quotidiano di backend.
- **SSO aziendale** – un solo IdP, molte app; MFA e offboarding imposti in un unico punto.
- **Identità di API e servizi** – credenziali macchina, token con ambito e rotazione per i chiamanti non umani.
- **Programmi di conformità** – revisioni degli accessi, tracce di audit e prove del privilegio minimo per GDPR, HIPAA, SOC 2.
- **Architetture zero trust** – controlli di identità a ogni richiesta al posto della posizione di rete come segnale di fiducia.

## Costruire o comprare l'IAM? Matrice decisionale

| Situazione | Verso cui propendere |
| --- | --- |
| Autenticazione a livello di app per un prodotto | Ereditarla da una piattaforma BaaS – dallo user store all'MFA, già pronta |
| SSO workforce su più strumenti SaaS | Comprare un servizio IdP |
| Controllo totale, self-hosting, protocolli standard | IdP open source (Keycloak, Ory) |
| Una sola app, esigenze semplici, sessioni del framework | Costruire il minimo – prevedendo però recupero e audit |
| Verifica regolamentata dell'identità | Comprare – i livelli di garanzia sono lavoro da certificazione |
| Scriversi l'archiviazione delle password "per ora" | Lasciar perdere – è l'unica ruota da non reinventare |

## Limiti e trade-off

- **L'IAM è un processo travestito da software.** Gli strumenti automatizzano la policy, non possono inventarla – progettazione dei ruoli, cadenza delle revisioni e disciplina di offboarding restano lavoro umano.
- **La centralizzazione concentra il rischio.** Un solo IdP significa un solo posto da proteggere e un solo disservizio che butta fuori tutti; con la comodità arrivano la pianificazione della disponibilità e del ripristino.
- **La federazione eredita la fiducia.** Ogni app che si fida di un IdP eredita le sue compromissioni; validazione dei token e durate brevi sono il contenimento.
- **L'automazione del ciclo di vita ha bisogno della verità.** Il provisioning vale quanto la fonte di riferimento che lo alimenta; dati HR obsoleti diventano accessi obsoleti.
- **Audit senza revisione è teatro.** Log che nessuno legge e certificazioni su cui nessuno agisce soddisfano le checklist, non gli attaccanti.

## IAM su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. L'IAM visto con gli occhi di chi sviluppa è esattamente ciò che la piattaforma consegna: la classe `User` è l'identity store; registrazione, verifica dell'e-mail, reimpostazione della password e [login social](/glossary/it/oauth-2-login-social/) coprono l'autenticazione (con un adapter MFA per lo step-up); i session token revocabili portano l'identità; i [ruoli](/glossary/it/controllo-degli-accessi-rbac/) e le [ACL](/glossary/it/liste-di-controllo-degli-accessi-acl/) per singolo oggetto sono il pilastro dell'autorizzazione, applicato a ogni richiesta REST, GraphQL e Live Query; e il ciclo di vita delle schede di codice – ingresso, mobilità, uscita – è ordinario lavoro sui dati, con i trigger di Cloud Code come luogo in cui imporre la policy (bloccare le e-mail usa e getta, registrare eventi di audit, propagare il deprovisioning). È CIAM come livello di piattaforma: i pilastri arrivano assemblati, e il lavoro si sposta dal costruire macchinari per l'identità al decidere la policy.