Condividi tramite

Proteggere applicazioni e API convalidando le attestazioni

  • Articolo

L'interazione con i token è una parte fondamentale della creazione di applicazioni per autorizzare gli utenti. In conformità al principio Zero Trust per l'accesso con privilegi minimi, è essenziale che le applicazioni convalidano i valori di determinate attestazioni presenti nel token di accesso durante l'esecuzione dell'autorizzazione.

L'autorizzazione basata sulle attestazioni consente alle applicazioni di assicurarsi che il token contenga i valori corretti per elementi quali il tenant, l'oggetto e l'attore presenti nel token. Detto questo, l'autorizzazione basata sulle attestazioni può sembrare complessa in base ai vari metodi di utilizzo e scenari di cui tenere traccia. Questo articolo intende semplificare il processo di autorizzazione basato sulle attestazioni in modo da garantire che le applicazioni rispettino le procedure più sicure.

Per assicurarsi che la logica di autorizzazione sia sicura, è necessario convalidare le informazioni seguenti nelle attestazioni:

  • Il gruppo di destinatari appropriato viene specificato per il token.
  • L'ID tenant del token corrisponde all'ID del tenant in cui vengono archiviati i dati.
  • L'oggetto del token è appropriato.
  • L'attore (app client) è autorizzato.

Nota

I token di accesso vengono convalidati solo nelle API Web per cui sono stati acquisiti da parte di un client. Il client non deve convalidare i token di accesso.

Per altre informazioni sulle attestazioni indicate in questo articolo, vedere Token di accesso di Microsoft Identity Platform.

Convalidare il gruppo di destinatari

L'attestazione aud identifica il gruppo di destinatari previsto del token. Prima di convalidare le attestazioni, è necessario verificare sempre che il valore dell'attestazione aud contenuto nel token di accesso corrisponda all'API Web. Il valore può dipendere dal modo in cui il client ha richiesto il token. Il gruppo di destinatari nel token di accesso dipende dall'endpoint:

  • Per i token v2.0, il gruppo di destinatari è l'ID client dell'API Web. Si tratta di un GUID.
  • Per i token v1.0, il gruppo di destinatari è uno degli URI appID dichiarati nell'API Web che convalida il token. Ad esempio, api://{ApplicationID}o un nome univoco che inizia con un nome di dominio (se il nome di dominio è associato a un tenant).

Per altre informazioni sull'URI appID di un'applicazione, vedere URI ID applicazione.

Convalidare il tenant

Verificare sempre che in tid un token corrisponda all'ID tenant usato per archiviare i dati con l'applicazione. Quando le informazioni vengono archiviate per un'applicazione nel contesto di un tenant, è necessario accedervi solo più avanti nello stesso tenant. Non consentire mai l'accesso ai dati in un tenant da un altro tenant.

La convalida del tenant è solo il primo passaggio e i controlli sull'oggetto e sull'attore descritti in questo articolo sono ancora necessari. Se si intende autorizzare tutti gli utenti in un tenant, è consigliabile aggiungere esplicitamente questi utenti in un gruppo e autorizzarlo in base al gruppo. Ad esempio, controllando solo l'ID tenant e la presenza di un'attestazione oid , l'API potrebbe autorizzare inavvertitamente tutte le entità servizio in tale tenant oltre agli utenti.

Convalidare l'oggetto

Determinare se l'oggetto del token, ad esempio l'utente (o l'applicazione stessa per un token solo app), è autorizzato.

È possibile verificare la presenza di attestazioni o oid specifichesub.

Oppure

È possibile verificare che l'oggetto appartenga a un ruolo o a un gruppo appropriato con le rolesattestazioni , scpgroups, , wids . Ad esempio, usare i valori tid di attestazione non modificabili e oid come chiave combinata per i dati dell'applicazione e determinare se è necessario concedere l'accesso a un utente.

Le rolesattestazioni , groups o wids possono essere usate anche per determinare se l'oggetto dispone dell'autorizzazione per eseguire un'operazione, anche se non sono un elenco completo di tutti i modi in cui un soggetto può concedere le autorizzazioni. Ad esempio, un amministratore può avere l'autorizzazione per scrivere in un'API, ma non un utente normale o l'utente può trovarsi in un gruppo autorizzato a eseguire alcune azioni. L'attestazione wid rappresenta i ruoli a livello di tenant assegnati all'utente dai ruoli presenti nei ruoli predefiniti di Microsoft Entra. Per altre informazioni, vedere Ruoli predefiniti di Microsoft Entra.

Avviso

Non usare mai attestazioni come emailo preferred_username unique_name per archiviare o determinare se l'utente in un token di accesso deve avere accesso ai dati. Queste attestazioni non sono univoche e possono essere controllabili dagli amministratori tenant o talvolta dagli utenti, rendendole non adatte alle decisioni di autorizzazione. Sono utilizzabili solo a scopo di visualizzazione. Non usare anche l'attestazione per l'autorizzazione upn . Anche se l'UPN è univoco, spesso cambia per tutta la durata di un'entità utente, che lo rende non affidabile per l'autorizzazione.

Convalidare l'attore

Un'applicazione client che agisce per conto di un utente (detto attore), deve anche essere autorizzata. Usare l'attestazione scp (ambito) per verificare che l'applicazione disponga dell'autorizzazione per eseguire un'operazione. Le autorizzazioni in scp devono essere limitate a ciò che l'utente ha effettivamente bisogno e segue i principi dei privilegi minimi.

Tuttavia, esistono occorrenze in cui scp non è presente nel token. È necessario verificare l'assenza dell'attestazione scp per gli scenari seguenti:

  • Autorizzazione solo app daemon/app
  • Token ID

Per altre informazioni su ambiti e autorizzazioni, vedere Ambiti e autorizzazioni in Microsoft Identity Platform.

Nota

Un'applicazione può gestire token solo app (richieste da applicazioni senza utenti, ad esempio app daemon) e vuole autorizzare un'applicazione specifica in più tenant, anziché singoli ID entità servizio. In tal caso, l'attestazione appid (per i token v1.0) o l'attestazione (per i token v2.0) può essere usata per l'autorizzazione azp dell'oggetto. Tuttavia, quando si usano queste attestazioni, l'applicazione deve assicurarsi che il token sia stato rilasciato direttamente per l'applicazione convalidando l'attestazione idtyp facoltativa. In questo modo è possibile autorizzare solo i token di tipo app , perché i token utente delegati possono essere ottenuti da entità diverse dall'applicazione.

Passaggi successivi