Configura token

In qualità di sviluppatore, l'interazione principale con Microsoft Entra ID consiste nel richiedere un token per identificare l'utente. È anche necessario richiedere un token per ottenere l'autorizzazione per chiamare un'API Web. Il token API Web determina le operazioni che l'API può eseguire quando esegue la gestione di una determinata richiesta. In questo articolo vengono fornite informazioni sulle informazioni che è possibile ricevere nei token e su come personalizzare i token. Queste procedure consigliate per gli sviluppatori Zero Trust migliorano la flessibilità e il controllo aumentando la sicurezza delle applicazioni con privilegi minimi.

I motivi per personalizzare i token dell'applicazione dipendono dal processo usato per ottenere un'autorizzazione più granulare nelle applicazioni e nelle API. Ad esempio, potresti avere ruoli utente, livelli di accesso e funzionalità diversi nell'app che si basano sulle informazioni dei token.

L'API Microsoft Graph offre un set affidabile di informazioni e dati sulla directory in Microsoft 365. È possibile sviluppare un sistema di autorizzazione con granularità fine e avanzata basandosi sui dati in Microsoft Graph. Ad esempio, è possibile accedere alle informazioni dall'appartenenza al gruppo dell'utente, dai dati dettagliati del profilo, da SharePoint e Outlook da usare nelle decisioni di autorizzazione. È possibile includere i dati di autorizzazione nel token da Microsoft Entra ID.

Autorizzazione a livello di applicazione

È possibile che i professionisti IT aggiungano l'autorizzazione a livello di app senza personalizzazione dei token o aggiunte al codice.

I professionisti IT possono impedire l'emissione di token a qualsiasi app nel tenant con il flag assegnazione utente richiesta. Questo approccio garantisce che solo un set di utenti possa accedere all'applicazione. Senza questo flag, tutti gli utenti di un tenant possono accedere all'applicazione. Con questo flag, solo gli utenti e i gruppi assegnati possono accedere all'applicazione. Quando un utente assegnato accede all'app, l'app riceve un token. Se l'utente non ha un'assegnazione, l'app non riceve un token. Ricorda di gestire sempre correttamente le richieste di token che non ottengono token.

Metodi di personalizzazione dei token

Esistono due modi per personalizzare i token: attestazioni facoltative e mappatura delle attestazioni.

Attestazioni facoltative

Le attestazioni facoltative specificano le attestazioni che si desidera che Microsoft Entra ID invii all'applicazione nei token. È possibile usare attestazioni facoltative per:

• Selezionare altre attestazioni da includere nei token dell'applicazione.
• Modificare il comportamento delle attestazioni che la piattaforma di identità Microsoft restituisce nei token.
• Aggiungere e accedere ad attestazioni personalizzate per la tua applicazione.

Le claim facoltative dipendono dall'oggetto di registrazione dell'applicazione con uno schema definito. Si applicano all'applicazione indipendentemente da dove è in esecuzione. Quando si scrive un'applicazione multi-tenant, le attestazioni facoltative funzionano correttamente perché sono coerenti in ogni tenant in Microsoft Entra ID. Ad esempio, un indirizzo IP non è specifico del tenant, mentre un'applicazione ha un indirizzo IP.

Di default, gli utenti guest di un tenant possono accedere anche alla tua app. Se si vuole bloccare gli utenti guest, acconsentire esplicitamente all'attestazione facoltativa (acct). Se è 1, l'utente ha una classificazione guest. Se si vuole bloccare gli utenti guest, bloccare i token con acct==1.

Politiche di mapping delle attestazioni

In Microsoft Entra ID gli oggetti criteri rappresentano set di regole per singole applicazioni o per tutte le applicazioni di un'organizzazione. Un criterio di mapping delle attestazioni modifica le attestazioni che Microsoft Entra ID rilascia nei token per applicazioni specifiche.

Si utilizza il mapping delle dichiarazioni per informazioni specifiche del tenant prive di uno schema, ad esempio EmployeeID, DivisionName. Il mapping delle attestazioni si applica a livello di entità servizio che l'amministratore tenant controlla. Il mapping delle attestazioni corrisponde all'app aziendale o all'entità del servizio per quell'applicazione. Ogni tenant può avere la propria mappatura delle dichiarazioni.

Quando si sviluppa un'applicazione linea di business, è importante osservare attentamente le operazioni del tenant e le attestazioni specifiche disponibili per il tenant che è possibile usare nel token. Ad esempio, se un'organizzazione ha la proprietà nome di divisione di un utente (non un campo standard in MICROSOFT Entra ID) in Active Directory locale, usare Microsoft Entra Connect per sincronizzarlo con Microsoft Entra ID.

Per contenere tali informazioni, usare uno degli attributi di estensione standard. Definisci il tuo token con un claim del nome della divisione che puoi compilare dall'estensione corrispondente (anche se non si applica a ogni tenant). Ad esempio, un'organizzazione inserisce il nome della divisione nell'attributo di estensione 13.

Con il mapping delle attestazioni, è possibile farlo funzionare per un altro tenant che inserisce il nome della divisione nell'attributo sette.

Pianificare la personalizzazione dei token

Il token personalizzato dipende dal tipo di applicazione: applicazione client o API. Non esiste alcuna differenza nelle operazioni che è possibile eseguire per personalizzare il token. Ciò che è possibile inserire nel token è lo stesso per ognuno di essi. Il token che si sceglie di personalizzare dipende dal token usato dall'app.

Personalizzare i token ID

Se si sviluppa un'applicazione client, si personalizza il token ID perché è il token richiesto per identificare l'utente. Un token appartiene all'app quando l'attestazione del gruppo di destinatari (aud) nel token corrisponde all'ID client dell'applicazione. Per un'applicazione client che chiama le API ma non le implementa, assicurarsi di personalizzare solo il token ID dell'app.

Il portale di Azure e l'API Microsoft Graph consentono di personalizzare anche il token di accesso per l'app, ma tali personalizzazioni non hanno alcun effetto. Non è possibile personalizzare un token di accesso per un'API di cui non si è proprietari. Tenere presente che l'app non deve tentare di decodificare o controllare un token di accesso ricevuto dall'app client come autorizzazione per chiamare un'API.

Personalizzare i token di accesso

Quando si sviluppa un'API, si personalizza il token di accesso perché l'API riceve i token di accesso come parte della chiamata del client all'API.

Le applicazioni client personalizzano sempre il token ID ricevuto per l'identità dell'utente. Le API personalizzano i token di accesso ricevuti dall'API come parte della chiamata all'API.

Gruppi e ruoli dell'app

Una delle tecniche di autorizzazione più comuni consiste nell'eseguire l'accesso in base all'appartenenza a un gruppo o ai ruoli assegnati di un utente. Configurare le attestazioni di gruppo e i ruoli dell'app nei token illustra come configurare le app con definizioni di ruoli applicativi e assegnare gruppi di sicurezza ai ruoli applicativi. Questi metodi consentono di migliorare la flessibilità e il controllo aumentando la sicurezza zero trust dell'applicazione con privilegi minimi.

Passaggi successivi

• Il mapping delle attestazioni utente di Collaborazione B2B descrive il supporto di Microsoft Entra ID per personalizzare le attestazioni rilasciate nel token SAML (Security Assertion Markup Language) per gli utenti di Collaborazione B2B.
• Personalizzare le attestazioni del token SAML dell'app quando un utente esegue l'autenticazione a un'applicazione tramite Microsoft Identity Platform usando il protocollo SAML 2.0.
• Protezione dell'API descrive le migliori pratiche per proteggere la tua API attraverso la registrazione, la definizione di autorizzazioni e consenso, e l'applicazione dell'accesso per raggiungere gli obiettivi di Zero Trust.
• Le procedure consigliate per l'autorizzazione consentono di implementare i modelli di autorizzazione, autorizzazione e consenso ottimali per le applicazioni.
• Utilizzare le migliori pratiche di sviluppo per la gestione delle identità e degli accessi Zero Trust nel ciclo di sviluppo delle applicazioni per creare applicazioni sicure.