Condividi tramite

Aumentare la resilienza di autenticazione e autorizzazione nelle applicazioni daemon in corso di sviluppo

  • Articolo

Informazioni su come usare Microsoft Identity Platform e Microsoft Entra ID per aumentare la resilienza delle applicazioni daemon. Trovare informazioni sui processi in background, i servizi, i servizi, le app da server a server e le applicazioni senza utenti.

Vedere Che cos'è Microsoft Identity Platform?

Il diagramma seguente illustra un'applicazione daemon che effettua una chiamata a Microsoft Identity Platform.

Applicazione daemon che effettua una chiamata a Microsoft Identity Platform.

Identità gestite per le risorse di Azure

Se si creano app daemon in Microsoft Azure, usare le identità gestite per le risorse di Azure, che controllano segreti e credenziali. La funzionalità migliora la resilienza gestendo la scadenza, la rotazione o l'attendibilità del certificato.

Vedere Informazioni sulle identità gestite per le risorse di Azure.

Le identità gestite usano token di accesso di lunga durata e informazioni provenienti da Microsoft Identity Platform per acquisire nuovi token prima della scadenza degli stessi. L'app viene eseguita durante l'acquisizione di nuovi token.

Le identità gestite usano endpoint a livello di area geografica (o regione), che consentono di evitare errori al di fuori dell’area, consolidando le dipendenze dei servizi. Gli endpoint regionali consentono di mantenere il traffico in una determinata area geografica. Ad esempio, se la risorsa di Azure si trova in WestUS2, tutto il traffico rimane in WestUS2.

Libreria di Autenticazione Microsoft

Se si sviluppano app daemon e non si usano identità gestite, usare Microsoft Authentication Library (MSAL) per l'autenticazione e l'autorizzazione. MSAL semplifica il processo di fornitura di credenziali client. Ad esempio, non occorre che l'applicazione crei e firmi asserzioni di token Web JSON con credenziali basate su certificati.

Vedere Panoramica di Microsoft Authentication Library (MSAL)

Microsoft.Identity.Web per sviluppatori .NET

Se si sviluppano app daemon in ASP.NET Core, usare la libreria Microsoft.Identity.Web per semplificare l'autorizzazione. Include strategie di cache dei token distribuite per app distribuite ed eseguite in più aree.

Altre informazioni:

Cache e archiviazione dei token

Se non si usa MSAL per l'autenticazione e l'autorizzazione, esistono procedure consigliate per la memorizzazione nella cache e l'archiviazione dei token. MSAL implementa e segue queste procedure consigliate.

Un'applicazione acquisisce i token da un provider di identità (IdP) per autorizzare l'applicazione a chiamare le API protette. Quando l'app riceve token, la risposta con i token contiene una expires\_in proprietà che indica all'applicazione per quanto tempo memorizzare nella cache e riutilizzare il token. Accertarsi che le applicazioni utilizzino la expires\_in proprietà per determinare la durata del token. Confermare che l'applicazione non tenti di decodificare un token di accesso all'API. L'uso del token memorizzato nella cache impedisce il traffico non necessario tra un'app e Microsoft Identity Platform. Gli utenti hanno eseguito l'accesso all'applicazione per tutta la durata del token.

Codici di errore HTTP 429 e 5xx

Usare le sezioni seguenti per informazioni sui codici di errore HTTP 429 e 5xx

HTTP 429

Sono presenti errori HTTP che influiscono sulla resilienza. Se l'applicazione riceve un codice di errore HTTP 429, Troppe richieste, Microsoft Identity Platform limita le richieste, impedendo all'app di ricevere token. Accertarsi che le app non tentino di acquisire token fino alla scadenza del campo di risposta Retry-After. L'errore 429 indica spesso che l'applicazione non memorizza nella cache e non riutilizza correttamente i token.

HTTP 5xx

Se un'applicazione riceve un codice di errore HTTP 5x, l'app non deve immettere un ciclo di ripetizione rapido. Verificare che le applicazioni attendino la scadenza del campo Retry-After. Se la risposta non contiene l’intestazione Retry-After, effettuare un nuovo tentativo di back-off esponenziale con il primo tentativo, almeno 5 secondi dopo la risposta.

Quando una richiesta va in timeout, verificare che le applicazioni non ritentino immediatamente. Usare il nuovo tentativo di back-off esponenziale citato in precedenza.

Passaggi successivi