Panoramica dei token e delle attestazioni

  • Articolo

Un provider di identità centralizzato è 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 rilasciato da un server di autorizzazione come parte di un flusso 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'applicazione 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 talvolta rilasciano 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 rilascia i token ID, vedere Token ID in Microsoft Identity Platform.

Molte applicazioni aziendali usano SAML per autenticare gli utenti. Per informazioni sulle asserzioni SAML, vedere Informazioni di riferimento sui token SAML.

Convalidare i token

Spetta all'applicazione per cui è stato generato il token, all'app Web che ha eseguito 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 altre informazioni, vedere l'articolo Proteggere applicazioni e API convalidando le attestazioni .

È consigliabile usare le librerie di autenticazione Microsoft (MSAL) supportate quando possibile. Ciò implementa automaticamente l'acquisizione, l'aggiornamento e la convalida dei token. 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 è vicino alla scadenza.

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 Web JSON 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à, ad esempio un'applicazione client o un proprietario di risorse, a un'altra entità, ad esempio un server di risorse. Un'attestazione può anche essere definita attestazione JWT o attestazione di token Web JSON.

Le attestazioni sono coppie nome o valore che inoltrino 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 token specifico dipendono da molti aspetti, ad esempio il tipo di token, il tipo di credenziale usato per autenticare l'oggetto e la configurazione dell'applicazione.

Le applicazioni possono usare attestazioni per le varie attività seguenti:

  • 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 token di sicurezza che ha generato il token
  • Data di generazione del token
  • Oggetto (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 e autorità emittenti di token

Microsoft Entra ID supporta due configurazioni 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 esterna 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 i flussi di lavoro di lavoro e ID esterni, se necessario.

I tenant di Microsoft Entra workforce eseguono l'autenticazione in login.microsoftonline.com con token rilasciati da sts.windows.net. I token tenant della forza lavoro sono in genere intercambiabili tra tenant e applicazioni 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 della modalità di compilazione del 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. Nella tabella seguente viene fornita 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)

I token emessi usando il flusso implicito presentano una limitazione di lunghezza perché vengono passati di nuovo al browser usando l'URL, dove response_mode è query o fragment. Alcuni browser hanno un limite per le dimensioni dell'URL che possono essere inserite nella barra del browser e hanno esito negativo quando è troppo lungo. Di conseguenza, questi token non hanno groups attestazioni o wids .

Vedi anche

Passaggi successivi