Quattro superfici che sembrano indipendenti e non lo sono: chi si autentica, che cosa rappresenta un’applicazione dentro il tenant, chi le concede i permessi e come un carico di lavoro Azure ottiene un token senza avere una password.

Metodi di autenticazione: una policy consigliata, due che restano vive

Il posto giusto per abilitare i metodi è la Authentication methods policy, modificabile da un Authentication Policy Administrator, con targeting per gruppo (il targeting sul singolo utente è stato rimosso; gli utenti già presenti restano, ma vanno spostati in un gruppo).

Entra ID > Authentication methods > Policies

Il punto che manda fuori strada: le vecchie policy MFA e SSPR esistono ancora e non sono sincronizzate con la nuova. Microsoft Entra ID rispetta le impostazioni di tutte le policy, quindi un utente abilitato a un metodo in una qualsiasi di esse può registrarlo e usarlo. Per impedire davvero un metodo devi disabilitarlo ovunque. Dal 30 settembre 2025 i metodi non si gestiscono più nelle policy legacy, ma “Manage migration” resta il modo per capire dove sei: Pre-migration, Migration in Progress (le legacy contano ancora), Migration Complete (le legacy vengono ignorate). Le domande di sicurezza si abilitano tuttora solo nella SSPR legacy. Occhio anche al limite: se la policy supera i 20 KB, il salvataggio fallisce.

Sul passwordless, le passkey (FIDO2) sono disponibili in tutte le edizioni, Microsoft Entra ID Free compresa. I passkey profiles danno configurazioni per gruppo — tipo di passkey (device-bound o synced), attestation, restrizioni per AAGUID — ma l’adesione ai profili è irreversibile e i profili supportati sono al massimo tre, incluso il Default. Tre comportamenti da ricordare: “Allow self-service set up” è globale, non per profilo; l’attestation governa solo la registrazione, quindi chi ha già registrato una passkey senza attestation continua ad autenticarsi anche se in seguito la imponi; le passkey sincronizzate non supportano attestation. Le key restriction per AAGUID valgono invece per registrazione e autenticazione: togliere un AAGUID già consentito lascia a piedi chi lo usava.

Le authentication strengths collegano tutto questo all’accesso condizionale: tre predefinite — Multifactor authentication, Passwordless MFA, Phishing-resistant MFA — più quelle personalizzate. Non restringono l’autenticazione iniziale: essendo valutate dopo, obbligano l’utente a presentare un metodo ammesso prima di procedere.

App registration ed enterprise application: due oggetti, non uno

Registrare un’app crea un application object nel tenant di origine — il progetto, unico al mondo — e da esso deriva un service principal in ogni tenant dove l’app viene usata: è quello che vedi sotto Enterprise applications, e decide che cosa l’app può fare in quel tenant. Dal portale i due oggetti nascono insieme; via Microsoft Graph creare il service principal è un passaggio separato.

I service principal sono di tre tipi: Application, Managed identity e Legacy. Quello di una identità gestita non ha alcun application object dietro e non è modificabile direttamente.

Due conseguenze operative. Cancellare l’application object cancella anche il service principal del tenant di origine, e ripristinare la registrazione dal portale non ripristina il service principal: per una sospensione temporanea disattiva l’applicazione invece di eliminarla. Sulle credenziali: il certificato è il tipo raccomandato, il client secret ha un ciclo di vita massimo di 24 mesi (Microsoft consiglia sotto i 12), il valore si legge una volta sola e non va usato in produzione. Per i carichi esterni — GitHub Actions, Kubernetes — la strada è la federated identity credential.

Consenso: il default lascia consentire gli utenti

Per impostazione predefinita tutti gli utenti possono consentire alle applicazioni i permessi che non richiedono il consenso dell’amministratore. Le opzioni si trovano qui:

Entra ID > Enterprise apps > Consent and permissions > User consent settings

Le due policy predefinite hanno nomi che vale la pena riconoscere: microsoft-user-default-legacy corrisponde a “Allow user consent for apps”, microsoft-user-default-low a “Allow user consent for apps from verified publishers, for selected permissions” — e quest’ultima funziona solo se hai classificato i permessi come low impact, altrimenti non consente nulla. Per configurarle serve Privileged Role Administrator (il Microsoft Entra admin center chiede Global Administrator).

Il dettaglio che rovina i piani: cambiare l’impostazione vale solo per i consensi futuri. Le concessioni già rilasciate restano valide e vanno revocate a parte, sotto Permissions dell’applicazione. Il portale revoca solo la scheda Admin consent; per la scheda User consent servono Microsoft Graph o PowerShell (Remove-MgOauth2PermissionGrant per i permessi delegati, Remove-MgServicePrincipalAppRoleAssignment per quelli applicativi). E revocare non impedisce di riconsentire.

Se blocchi il consenso, dai una via d’uscita: l’admin consent workflow. Lo attiva un Global Administrator; i reviewer possono vedere, bloccare e negare, ma solo i Global Administrator approvano richieste per gli app role di Microsoft Graph, cioè i permessi applicativi. Nominare qualcuno reviewer non gli aumenta i privilegi, e l’attivazione può richiedere fino a un’ora.

Identità gestite: quale dei due tipi, e perché

L’identità gestita elimina la credenziale: il codice chiede il token tramite Azure.Identity o MSAL e non c’è nulla da ruotare, senza costi aggiuntivi. Quella system-assigned condivide il ciclo di vita della risorsa e non è condivisibile; quella user-assigned è una risorsa a sé, sopravvive alle ricreazioni, può essere assegnata a più risorse ed è il tipo raccomandato. Le operazioni CRUD finiscono nell’Azure Activity log, gli accessi nei sign-in log di Entra. Se ti serve una app registration vera, la via credential-free è usare l’identità gestita come federated identity credential sull’applicazione: il limite è 20 FIC per app.