Condividi tramite

Proteggere applicazioni e API convalidando le attestazioni

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 ulteriori informazioni sull'URI dell'ID applicazione, vedere URI ID applicazione.

Convalidare il locatario

Verificare sempre che un token in tid 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 di un tenant da parte di un altro tenant.

La convalida del locatario è il primo passaggio, ma i controlli sul soggetto 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 a un gruppo e autorizzarlo in base al gruppo. Ad esempio, controllando solo l'ID del tenant e la presenza di un'attestazione oid, l'API potrebbe inavvertitamente autorizzare tutti i principali del servizio in quel 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.

Puoi controllare o le rivendicazioni specifiche sub o oid.

Oppure

È possibile verificare che il soggetto appartenga a un ruolo o a un gruppo appropriato con le attestazioni roles, scp, groups e 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 attestazioni roles, 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_usernameunique_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, che li rendono inadatti alle decisioni di autorizzazione. Sono utilizzabili solo a scopo di visualizzazione. Non usare l'attestazione upn nemmeno per l'autorizzazione. Anche se l'UPN è univoco, spesso cambia nel corso della vita di un utente principale, rendendolo inaffidabile 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 per app daemon
  • Token di identificazione

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

Nota

Un'applicazione può gestire token di sola applicazione (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, la dichiarazione appid (per i token v1.0) o la dichiarazione azp (per i token v2.0) può essere usata per l'autorizzazione del soggetto. 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