Panoramica dei token e delle attestazioni
Un provider di identità centrale è particolarmente utile per le app con utenti in tutto il mondo che non accedono necessariamente dalla rete aziendale. Microsoft Identity Platform autentica gli utenti e fornisce token di sicurezza, ad esempio token di accesso, token di aggiornamento e token ID. I token di sicurezza consentono a un'applicazione client di accedere alle risorse protette in un server di risorse.
- Token di accesso: un token di accesso è un token di sicurezza emesso da un server di autorizzazione durante un flusso di OAuth 2.0. Contiene informazioni sull'utente e sulla risorsa a cui è destinato il token. Le informazioni possono essere usate per accedere alle API Web e ad altre risorse protette. Le risorse convalidano i token di accesso per concedere l'accesso a un'app client. Per altre informazioni, vedere Token di accesso in Microsoft Identity Platform.
- Token di aggiornamento: poiché i token di accesso sono validi solo per un breve periodo di tempo, i server di autorizzazione a volte emettono un token di aggiornamento contemporaneamente al token di accesso. L'applicazione client può quindi scambiare questo token di aggiornamento con un nuovo token di accesso, se necessario. Per altre informazioni, vedere Aggiornare i token in Microsoft Identity Platform.
- Token ID: i token ID vengono inviati all'applicazione client nell'ambito di un flusso di OpenID Connect. Possono essere inviati insieme o al posto di un token di accesso. I token ID vengono usati dal client per autenticare l'utente. Per altre informazioni su come Microsoft Identity Platform emette i token ID, vedere Token ID in Microsoft Identity Platform.
Molte applicazioni aziendali usano SAML per autenticare gli utenti. Per informazioni sulle asserzioni SAML, vedi Riferimento ai token SAML.
Convalidare i token
Spetta all'applicazione per cui è stato generato il token, all'app Web che ha concesso l'accesso all'utente o all'API Web chiamata per convalidare il token. Il server di autorizzazione firma il token con una chiave privata. Il server di autorizzazione pubblica la chiave pubblica corrispondente. Per convalidare un token, l'app verifica la firma usando la chiave pubblica del server di autorizzazione per verificare che la firma sia stata creata usando la chiave privata. Per ulteriori informazioni, consultare l'articolo Proteggere applicazioni e API mediante la convalida delle attestazioni.
È consigliabile usare le librerie di autenticazione Microsoft (MSAL) supportate, quando possibile. Ciò implementa l'acquisizione, l'aggiornamento e la convalida dei token. Ciò implementa anche l'individuazione conforme agli standard delle impostazioni e delle chiavi del tenant usando il documento di individuazione noto openID del tenant. MSAL supporta molte architetture e piattaforme per applicazioni diverse, tra cui .NET, JavaScript, Java, Python, Android e iOS.
I token sono validi solo per un periodo di tempo limitato, quindi il server di autorizzazione fornisce spesso una coppia di token. Viene fornito un token di accesso che accede all'applicazione o alla risorsa protetta. Viene fornito un token di aggiornamento, che viene usato per aggiornare il token di accesso quando il token di accesso sta per scadere.
I token di accesso vengono passati a un'API Web come token di connessione nell'intestazione Authorization. Un'app può fornire un token di aggiornamento al server di autorizzazione. Se l'accesso utente all'app non è stato revocato, riceve un nuovo token di accesso e un nuovo token di aggiornamento. Quando il server di autorizzazione riceve il token di aggiornamento, rilascia un altro token di accesso solo se l'utente è ancora autorizzato.
Token JSON Web e attestazioni
Microsoft Identity Platform implementa token di sicurezza come token JSON Web (JWT) che contengono attestazioni. Poiché i token JWT vengono usati come token di sicurezza, questa forma di autenticazione è talvolta denominata autenticazione JWT.
Un'attestazione fornisce asserzioni su un'entità, come un'applicazione client o un proprietario delle risorse, a un'altra entità, ad esempio il server di risorse. Un'attestazione può anche essere definita attestazione JWT o attestazione del token JSON Web.
Le attestazioni sono coppie nome o valore che inoltrano i fatti relativi all'oggetto del token. Ad esempio, un'attestazione potrebbe contenere fatti sull'entità di sicurezza autenticata dal server di autorizzazione. Le attestazioni presenti in un determinato token dipendono da molte cose, dal tipo di token, dal tipo di credenziali usate per autenticare l'utente e dalla configurazione dell'applicazione.
Le applicazioni possono usare le attestazioni per varie attività, tra cui:
- Convalidare il token
- Identificare il tenant dell'oggetto del token
- Visualizzare le informazioni utente
- Determinare l'autorizzazione dell'oggetto
Un'attestazione è costituita da coppie chiave-valore che forniscono i tipi di informazioni seguenti:
- Server di token di sicurezza che ha generato il token
- Data di generazione del token
- Soggetto (ad esempio l'utente, ma non i daemon)
- Destinatari, ovvero l'app per cui è stato generato il token
- App (il client) che ha richiesto il token
Endpoint di token e autorità emittenti di token
Microsoft Entra ID supporta due configurazioni del tenant: una configurazione della forza lavoro destinata all'uso interno e gestisce dipendenti e utenti guest aziendali e una configurazione dei clienti ottimizzata per isolare consumer e partner in una directory rivolta all'esterno limitata. Anche se il servizio di identità sottostante è identico per entrambe le configurazioni del tenant, i domini di accesso e l'autorità di emissione dei token per i tenant esterni sono diversi. Ciò consente alle applicazioni di mantenere separati la forza lavoro e i flussi di lavoro di ID esterni, se necessario.
I tenant delle risorse di Microsoft Entra eseguono l'autenticazione tramite login.microsoftonline.com con token rilasciati da sts.windows.net. I token dei tenant delle risorse sono in genere intercambiabili tra applicazioni tenant e multi-tenant, purché le relazioni di trust sottostanti consentano questa interoperabilità. I tenant esterni di Microsoft Entra usano endpoint tenant nel formato {tenantname}.ciamlogin.com. Le applicazioni registrate nei tenant esterni devono essere consapevoli di questa separazione per ricevere e convalidare correttamente i token.
Ogni tenant di Microsoft Entra pubblica metadati noti conformi agli standard. Questo documento contiene informazioni sul nome dell'autorità emittente, sugli endpoint di autenticazione e autorizzazione, sugli ambiti e sulle attestazioni supportati. Per i tenant esterni, il documento è disponibile pubblicamente all'indirizzo: https://{nome tenant}.ciamlogin.com/{tenantid}/v2.0/.well-known/openid-configuration. Questo endpoint restituisce un valore dell'autorità di certificazione https://{tenantid}.ciamlogin.com/{tenantid}/v2.0.
Flussi di autorizzazione e codici di autenticazione
A seconda del modo in cui viene compilato il client, può usare uno o più flussi di autenticazione supportati da Microsoft identity Platform. I flussi supportati possono produrre diversi token e codici di autorizzazione e richiedere token diversi per renderli operativi. La tabella seguente fornisce una panoramica.
| Flow | Richiede | Token ID | Token di accesso | token di aggiornamento | Codice di autorizzazione |
|---|---|---|---|---|---|
| Flusso del codice di autorizzazione | x | x | x | x | |
| Flusso implicito | x | x | |||
| Flusso OIDC ibrido | x | x | |||
| Riscatto del token di aggiornamento | token di aggiornamento | x | x | x | |
| Flusso on-behalf-of | Token di accesso | x | x | x | |
| Credenziali del client | x (solo app) |
Vedi anche
Passaggi successivi
- Per informazioni sui concetti di base dell'autenticazione e dell'autorizzazione, consultare Autenticazione e autorizzazione.