Aumentare la resilienza dell'autenticazione e dell'autorizzazione nelle applicazioni daemon sviluppate

Informazioni su come usare Microsoft Identity Platform e Microsoft Entra ID per aumentare la resilienza delle applicazioni daemon. Trovare informazioni sui processi, 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.

A daemon application making a call to 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 gestiscono segreti e credenziali. La funzionalità migliora la resilienza gestendo la scadenza, la rotazione o l'attendibilità del certificato.

Vedere Che cosa sono le identità gestite per le risorse di Azure?

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

Le identità gestite usano endpoint a livello di area, che consentono di evitare errori fuori area consolidando le dipendenze del servizio. Gli endpoint regionali consentono di mantenere il traffico in un'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, l'applicazione non deve creare e firmare 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 le app distribuite eseguite in più aree.

Altre informazioni:

Memorizzare nella cache e archiviare i 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. Verificare che le applicazioni usino la proprietà per determinare la expires\_in durata del token. Verificare 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 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. Assicurarsi che le app non tentino di acquisire un token fino alla scadenza del campo Risposta Retry-After . L'errore 429 indica spesso che l'applicazione non memorizza nella cache e 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 fornisce alcuna intestazione Retry-After, usare un nuovo tentativo di back-off esponenziale con il primo tentativo, almeno 5 secondi dopo la risposta.

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

Passaggi successivi