Novità per l'autenticazione

Microsoft aggiunge e modifica periodicamente le caratteristiche e le funzionalità di Microsoft Identity Platform per migliorare la sicurezza, l'usabilità e la conformità agli standard.

Se non diversamente specificato, le modifiche descritte qui si applicano solo alle applicazioni registrate dopo la data di validità specificata della modifica.

Per altre informazioni, vedere regolarmente questo articolo:

• Problemi noti e correzioni
• Modifiche al protocollo
• Funzionalità deprecate

Agosto 2024

Le credenziali di identità federate ora usano la corrispondenza con distinzione tra maiuscole e minuscole

Data di validità: settembre 2024

Protocollo interessato: federazione dell'identità del carico di lavoro

Modifica

In precedenza, quando corrisponde ai valori FIC (Federated Identity Credential) issuer, subjecte rispetto ai valori , subjecte corrispondenti issuercontenuti nel token inviato all'ID Microsoft Entra da un IdP esterno, veniva usata la corrispondenza senza distinzione tra maiuscole e audience audience minuscole. Per fornire ai clienti un controllo più granulare, si passa all'applicazione della corrispondenza con distinzione tra maiuscole e minuscole.

Esempio non valido:

• Oggetto del token: repo:contoso/contoso-org:ref:refs/heads/main
• Oggetto FIC: repo:Contoso/Contoso-Org:ref:refs/heads/main

Questi due valori oggetto non fanno distinzione tra maiuscole e minuscole, quindi la convalida non riesce. Lo stesso meccanismo viene applicato a e audience convalidaissuer.

Questa modifica verrà applicata inizialmente alle applicazioni o alle identità gestite create dopo August 14th, 2024. Le applicazioni inattive o le identità gestite, determinate dall'assenza di richieste di federazione dell'identità del carico di lavoro effettuate dall'applicazione o dall'identità gestita tra il periodo August 1st, 2024 e August 31st, 2024, devono usare la corrispondenza con distinzione tra maiuscole e minuscole a partire da September 27th, 2024. Per le applicazioni attive, la corrispondenza senza distinzione tra maiuscole e minuscole rientra in una data successiva da comunicare.

Per evidenziare meglio gli errori dovuti alla distinzione tra maiuscole e minuscole, viene rinnovato il messaggio di errore per AADSTS700213. Ora lo stato;

`AADSTS700213: No matching federated identity record found for presented assertion subject '{subject}'. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.` 

Il segnaposto '{subject}' fornisce il valore dell'attestazione dell'oggetto contenuta nel token inviato dal provider di identità esterno all'ID Microsoft Entra ID. Questo modello di errore viene usato anche per errori senza distinzione tra maiuscole e minuscole che circondano issuer e audience convalida. Se si verifica questo errore, è necessario trovare le credenziali di identità federate che corrispondono a issuer, subjecto audience elencate nell'errore e verificare che i valori corrispondenti siano equivalenti dal punto di vista con distinzione tra maiuscole e minuscole. Se si verifica una mancata corrispondenza, è necessario sostituire il valore corrente issuer, subjecto audience nel FIC con il issuervalore , subjecto audience contenuto nel messaggio di errore.

Giugno 2024

Le applicazioni devono essere registrate in una directory

Data di entrata in vigore: giugno 2024

Endpoint interessati: v2.0 e v1.0

Protocollo interessato: tutti i flussi

Modifica

In precedenza, durante la registrazione di un'applicazione usando l'esperienza registrazioni dell'app Microsoft Entra, se l'utente ha eseguito l'accesso con il proprio account Microsoft personale , potrebbe scegliere di associare l'applicazione solo al proprio account personale. Ciò significa che l'applicazione non sarebbe associata o contenuta in alcuna directory (detta anche "tenant" o "organizzazione"). Tuttavia, a partire da giugno 2024 tutte le applicazioni devono essere registrate in una directory. Potrebbe trattarsi di una directory esistente o di una nuova creata dall'utente dell'account Microsoft personale per ospitare le applicazioni Microsoft Entra e altre risorse Microsoft. Gli utenti possono creare facilmente una nuova directory da usare a questo scopo aggiungendo il Programma per sviluppatori di Microsoft 365 o iscrivendosi ad Azure.

La registrazione di un'applicazione in una directory, anziché associarla solo a un account personale, offre diversi vantaggi. tra cui:

• Le applicazioni registrate in una directory hanno più funzionalità disponibili, ad esempio la possibilità di aggiungere più proprietari all'app e la possibilità di verificare l'app.
• L'applicazione si trova nella stessa posizione delle altre risorse Microsoft usate dallo sviluppatore, ad esempio le risorse di Azure.
• L'applicazione riceve vantaggi migliori per la resilienza.

Ciò non influirà sulle applicazioni esistenti, incluse le applicazioni esistenti associate solo a un account personale. Ciò interesserà solo la possibilità di registrare nuove applicazioni.

Ottobre 2023

Richiesta aggiornata dell'esperienza utente di RemoteConnect

Data di entrata in vigore: ottobre 2023

Endpoint interessati: v2.0 e v1.0

Protocollo interessato: RemoteConnect

RemoteConnect è un flusso tra dispositivi usato per gli scenari correlati a Microsoft Authentication Broker e Microsoft Intune che coinvolgono i token di aggiornamento primari. Per evitare attacchi di phishing, il flusso RemoteConnect riceve una lingua dell'esperienza utente aggiornata per invitare che il dispositivo remoto (il dispositivo che ha avviato il flusso) possa accedere a tutte le applicazioni usate dall'organizzazione al completamento del flusso.

Il prompt visualizzato sarà simile al seguente:

Giugno 2023

Omissione di attestazioni di posta elettronica con un proprietario di dominio non verificato

Data di entrata in vigore: giugno 2023

Endpoint interessati: v2.0 e v1.0

Modifica

Per le applicazioni multi-tenant, i messaggi di posta elettronica non verificati dal proprietario del dominio vengono omessi per impostazione predefinita quando l'attestazione facoltativa email viene richiesta in un payload del token.

Si considera che un messaggio di posta elettronica ha un proprietario di dominio verificato se:

1. Il dominio appartiene al tenant in cui risiede l'account utente e l'amministratore tenant ha completato la verifica del dominio.
2. Il messaggio di posta elettronica proviene da un account Microsoft (MSA).
3. Il messaggio di posta elettronica proviene da un account Google.
4. Il messaggio di posta elettronica è stato usato per l'autenticazione tramite il flusso di passcode monouso (OTP).

Si noti inoltre che gli account Facebook e SAML/WS-Fed non hanno domini verificati.

Maggio 2023

Il ruolo di amministratore di Power BI verrà rinominato Amministratore infrastruttura.

Data di entrata in vigore: giugno 2023

Endpoint interessati:

• Elencare roleDefinitions - Microsoft Graph v1.0
• List directoryRoles - Microsoft Graph v1.0

Modifica

Il ruolo di amministratore di Power BI viene rinominato Amministratore infrastruttura.

Il 23 maggio 2023 Microsoft ha presentato Microsoft Fabric, che offre un'esperienza di integrazione dei dati basata su Data Factory, ingegneria dei dati basata su Synapse, data warehouse, data science ed esperienze di analisi in tempo reale e business intelligence (BI) con Power BI, tutti ospitati in una soluzione SaaS basata sul lake. L'amministrazione del tenant e della capacità per queste esperienze è centralizzata nel portale di amministrazione dell'infrastruttura (noto in precedenza come portale di amministrazione di Power BI).

A partire da giugno 2023, il ruolo di amministratore di Power BI viene rinominato Amministratore infrastruttura per allinearsi all'ambito e alla responsabilità mutevoli di questo ruolo. Nel corso di diverse settimane in tutte le applicazioni, tra cui Microsoft Entra ID, API Microsoft Graph, Microsoft 365 e GDAP, si inizierà a visualizzare il nuovo nome del ruolo.

Come promemoria, il codice e gli script dell'applicazione non devono prendere decisioni in base al nome del ruolo o al nome visualizzato.

Dicembre 2021

Gli utenti di AD FS visualizzeranno altre richieste di accesso per assicurarsi che l'utente corretto sia connesso.

Data di entrata in vigore: dicembre 2021

Endpoint interessati: Autenticazione integrata di Windows

Protocollo interessato: Autenticazione integrata di Windows

Modifica

Oggi, quando un utente viene inviato ad AD FS per l'autenticazione, verrà eseguito automaticamente l'accesso a qualsiasi account che dispone già di una sessione con AD FS. L'accesso invisibile all'utente si verifica anche se l'utente intende accedere a un account utente diverso. Per ridurre la frequenza di questo accesso non corretto, a partire da dicembre Microsoft Entra ID invierà il prompt=login parametro ad AD FS se Gestione account Web in Windows fornisce a Microsoft Entra ID un login_hint durante l'accesso, che indica che un utente specifico è desiderato per l'accesso.

Quando vengono soddisfatti i requisiti precedenti (WAM viene usato per reindirizzare l'utente a Microsoft Entra ID per l'accesso, viene incluso login_hint e l'istanza di Active Directory Federation Services (AD FS) per il dominio dell'utente supporta prompt=login) l'utente non verrà connesso automaticamente e invece viene chiesto di fornire un nome utente per continuare l'accesso ad AD FS. Se l'utente intende accedere alla sessione AD FS esistente, è possibile selezionare l'opzione "Continua come utente corrente" visualizzata sotto la richiesta di accesso. In caso contrario, può continuare con il nome utente con cui intende accedere.

Questa modifica verrà implementata nel dicembre 2021 nel corso di diverse settimane. Non modifica il comportamento di accesso per:

• Applicazioni che usano direttamente IWA
• Applicazioni che usano OAuth
• Domini che non sono federati con un'istanza di AD FS

Ottobre 2021

Errore 50105 risolto per non restituire interaction_required durante l'autenticazione interattiva

Data di entrata in vigore: ottobre 2021

Endpoint interessati: v2.0 e v1.0

Protocollo interessato: tutti i flussi utente per le app che richiedono l'assegnazione dell'utente

Modifica

L'errore 50105 (designazione corrente) viene generato quando un utente non assegnato tenta di accedere a un'app contrassegnata da un amministratore come richiedente l'assegnazione dell'utente. Si tratta di un modello di controllo di accesso comune e gli utenti devono spesso trovare un amministratore per richiedere l'assegnazione per sbloccare l'accesso. L'errore presentava un bug che causava cicli infiniti in applicazioni ben codificate che gestivano correttamente la risposta all'errore interaction_required. interaction_required comunica a un'app di eseguire l'autenticazione interattiva, ma anche dopo aver eseguito questa operazione, Microsoft Entra ID restituirà comunque una risposta di errore interaction_required.

Lo scenario di errore è stato aggiornato in modo che durante l'autenticazione non interattiva (in cui prompt=none viene usato per nascondere l'esperienza utente), l'app verrà indicata per eseguire l'autenticazione interattiva usando una risposta di errore interaction_required. Nell'autenticazione interattiva successiva Microsoft Entra ID tratterrà l'utente e visualizzerà direttamente un messaggio di errore, impedendo che si verifichi un ciclo.

Come promemoria, il codice dell'applicazione non deve prendere decisioni basate su stringhe di codice di errore come AADSTS50105. Seguire invece le linee guida per la gestione degli errori e usare le risposte di autenticazione standardizzate come interaction_required e login_required disponibili nel campo error standard nella risposta. Gli altri campi di risposta sono destinati all'utilizzo solo da parte degli esseri umani per la risoluzione dei problemi.

È possibile esaminare il testo corrente dell'errore 50105 e altre informazioni nel servizio di ricerca degli errori: https://login.microsoftonline.com/error?code=50105.

Per l'URI AppId nelle applicazioni a tenant singolo sarà necessario l'uso di uno schema predefinito o di domini verificati

Data di entrata in vigore: ottobre 2021

Endpoint interessati: v2.0 e v1.0

Protocollo interessato: tutti i flussi

Modifica

Per le applicazioni a tenant singolo, l'aggiunta o l'aggiornamento dell'URI AppId convalida che il dominio nell'URI dello schema HTTPS sia elencato nell'elenco di domini verificati nel tenant del cliente o che il valore usi lo schema predefinito (api://{appId}) fornito da Microsoft Entra ID. Ciò può impedire alle applicazioni di aggiungere un URI AppID se il dominio non fa parte dell'elenco di domini verificati o se il valore non usa lo schema predefinito. Per altre informazioni sui domini verificati, fare riferimento alla documentazione relativa ai domini personalizzati.

La modifica non influisce sulle applicazioni esistenti che usano domini non verificati nel relativo URI AppID. Convalida solo le nuove applicazioni o quando un'applicazione esistente aggiorna l'URI di un identificatore o ne aggiunge uno nuovo alla raccolta identifierUri. Le nuove restrizioni si applicano solo agli URI aggiunti alla raccolta di identifierUri di un'app dopo il 15 ottobre 2021. Gli URI AppId già presenti nella raccolta identifierUris di un'applicazione quando la restrizione viene applicata il 15 ottobre 2021 continueranno a funzionare anche se si aggiungono nuovi URI a tale raccolta.

Se una richiesta non supera il controllo di convalida, l'API dell'applicazione per la creazione o l'aggiornamento restituirà 400 badrequest al client che indica HostNameNotOnVerifiedDomain.

Sono supportati i seguenti formati URI ID delle API e delle applicazioni basati sullo schema HTTP. Sostituire i valori segnaposto come descritto nell'elenco che segue la tabella.

ID applicazione supportato Formati di URI	URI ID app di esempio
api://<appId>	api://00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<appId>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<string>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
api://<string>/<appId>	api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
https://<tenantInitialDomain>.onmicrosoft.com/<string>	https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string>	https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain>	https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId> - proprietà dell'identificatore dell'applicazione (appId) dell'oggetto applicazione.
• <string> - valore stringa per l'host o il segmento di percorso API.
• <tenantId> - GUID generato da Azure per rappresentare il tenant in Azure.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, dove <tenantInitialDomain> è il nome di dominio iniziale specificato dall'autore del tenant durante la creazione del tenant.
• <verifiedCustomDomain> - un dominio personalizzato verificato configurato per il tenant di Microsoft Entra.

Agosto 2021

L'accesso condizionale verrà attivato solo per gli ambiti richiesti in modo esplicito

Data di entrata in vigore: agosto 2021, con implementazione graduale a partire da aprile.

Endpoint interessati: v2.0

Protocollo interessato: tutti i flussi che usano il consenso dinamico

Alle applicazioni che usano il consenso dinamico vengono attualmente concesse tutte le autorizzazioni di cui dispongono del consenso, anche se non sono state richieste dal nome nel parametro scope. Un'app che richiede solo user.read ma con il consenso a files.read può essere forzata a passare il requisito di accesso condizionale assegnato per files.read, ad esempio.

Per ridurre il numero di richieste di accesso condizionale non necessarie, Microsoft Entra ID modifica il modo in cui gli ambiti vengono forniti alle applicazioni in modo che solo gli ambiti richiesti in modo esplicito attivino l'accesso condizionale. Le applicazioni che si basano sul comportamento precedente di Microsoft Entra ID di includere tutti gli ambiti nel token, indipendentemente dal fatto che sia richiesto o meno, potrebbero interrompersi a causa di ambiti mancanti.

Le app riceveranno ora token di accesso con una combinazione di autorizzazioni: token richiesti e quelli per i quali non richiedono richieste di accesso condizionale. L'ambito di accesso per il token viene visualizzato nel parametro scope della risposta del token.

Questa modifica verrà apportata per tutte le app ad eccezione di quelle con una dipendenza caratterizzata da questo comportamento. Gli sviluppatori riceveranno informazioni di sensibilizzazione se sono esenti da questa modifica, in quanto potrebbero avere una dipendenza dalle richieste di accesso condizionale aggiuntive.

Esempi

Un'app ha il consenso per user.read, files.readwritee tasks.read. files.readwrite ha criteri di accesso condizionale applicati, mentre gli altri due non li hanno. Se un'app effettua una richiesta di token per scope=user.read e l'utente attualmente connesso non ha superato alcun criterio di accesso condizionale, il token risultante sarà per le autorizzazioni user.read e tasks.read. tasks.read è incluso perché l'app ha il consenso e non richiede l'applicazione di criteri di accesso condizionale.

Se l'app richiede scope=files.readwrite, verrà attivato l'accesso condizionale richiesto dal tenant, forzando l'app a visualizzare una richiesta di autenticazione interattiva in cui è possibile soddisfare i criteri di accesso condizionale. Il token restituito avrà tutti e tre gli ambiti in esso contenuti.

Se l'app effettua quindi un'ultima richiesta per uno dei tre ambiti (ad esempio scope=tasks.read), Microsoft Entra ID noterà che l'utente ha già completato i criteri di accesso condizionale necessari per files.readwrite e rilascia nuovamente un token con tutte e tre le autorizzazioni in esso contenute.

Giugno 2021

L'esperienza utente del flusso del codice del dispositivo includerà ora una richiesta di conferma dell'app

Data di entrata in vigore: giugno 2021.

Endpoint interessati: v2.0 e v1.0

Protocollo interessato: il flusso del codice del dispositivo

Per evitare attacchi di phishing, il flusso del codice del dispositivo include ora una richiesta che convalida l'accesso dell'utente all'app prevista.

Il prompt visualizzato è simile al seguente:

Maggio 2020

Correzione di bug: Microsoft Entra ID non codifica più il parametro di stato due volte

Data di entrata in vigore: maggio 2021

Endpoint interessati: v1.0 e v2.0

Protocollo interessato: tutti i flussi che visitano l'endpoint /authorize (flusso implicito e flusso del codice di autorizzazione)

È stato rilevato un bug e risolto nella risposta all'autorizzazione di Microsoft Entra. Durante l'autenticazione /authorize, il parametro state della richiesta viene incluso nella risposta, per mantenere lo stato dell'app e prevenire gli attacchi di richiesta intersito falsa. Microsoft Entra ID ha codificato in modo non corretto il parametro state prima di inserirlo nella risposta, dove è stato codificato ancora una volta. In questo modo le applicazioni rifiutano erroneamente la risposta da Microsoft Entra ID.

Microsoft Entra ID non codifica più questo parametro, consentendo alle app di analizzare correttamente il risultato. Questa modifica verrà apportata a tutte le applicazioni.

Gli endpoint di Azure per enti pubblici stanno cambiando

Data di entrata in vigore: 5 maggio 2020 (fine giugno 2020)

Endpoint interessati: tutti

Protocollo interessato: tutti i flussi

Il 1° giugno 2018, l'autorità ufficiale di Microsoft Entra per Azure per enti pubblici è cambiata da https://login-us.microsoftonline.com a https://login.microsoftonline.us. Questa modifica è stata applicata anche a Microsoft 365 GCC High e DoD, offerta anche da Microsoft Entra ID di Azure per enti pubblici. Se si è proprietari di un'applicazione all'interno di un tenant del governo degli Stati Uniti, è necessario aggiornare l'applicazione per consentire agli utenti di accedere all'endpoint .us.

Il 5 maggio 2020 Microsoft Entra ID inizierà ad applicare la modifica dell'endpoint, impedendo agli utenti pubblici di accedere alle app ospitate nei tenant del governo degli Stati Uniti usando l'endpoint pubblico (microsoftonline.com). Le app interessate inizieranno a visualizzare un errore AADSTS900439 - USGClientNotSupportedOnPublicEndpoint. Questo errore indica che l'app sta tentando di far accedere un utente del governo degli Stati Uniti nell'endpoint cloud pubblico. Se l'app si trova in un tenant del cloud pubblico e ha lo scopo di supportare gli utenti del governo degli Stati Uniti, è necessario aggiornare l'app per supportarli in modo esplicito. Ciò potrebbe richiedere la creazione di una nuova registrazione dell'app nel cloud del governo degli Stati Uniti.

L'applicazione di questa modifica verrà eseguita usando un'implementazione graduale in base alla frequenza con cui gli utenti del cloud del governo degli Stati Uniti accedono all'applicazione: l'applicazione della modifica sarà prima apportata alle app utilizzate rararamente per l'accesso dagli utenti del governo degli Stati Uniti, mentre le app usate frequentemente dagli utenti del governo degli Stati Uniti saranno le ultime a cui tale modifica verrà applicata. Ci aspettiamo che l'applicazione venga completata in tutte le app nel mese di giugno 2020.

Per altre informazioni, vedere il post di blog di Azure per enti pubblici su questa migrazione.

Marzo 2020

Le password utente saranno limitate a 256 caratteri.

Data di entrata in vigore: 13 marzo 2020

Endpoint interessati: tutti

Protocollo interessato: tutti i flussi utente.

Agli utenti con password superiori a 256 caratteri che accedono direttamente a Microsoft Entra ID (non a un IDP federato, ad esempio AD FS) verrà chiesto di modificare le password prima di poter accedere. Gli amministratori possono ricevere richieste per reimpostare la password dell'utente.

L'errore nei log di accesso sarà simile a AADSTS 50052: InvalidPasswordExceedsMaxLength.

Messaggio: The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.

Correzione:

L'utente non è in grado di accedere perché la password supera la lunghezza massima consentita. Devono contattare l'amministratore per reimpostare la password. Se la reimpostazione della password self-service è abilitata per il tenant, è possibile reimpostare la password seguendo il collegamento "Password dimenticata".

Febbraio 2020

I frammenti vuoti verranno aggiunti a ogni reindirizzamento HTTP dall'endpoint di accesso.

Data di entrata in vigore: 8 febbraio 2020

Endpoint interessati: sia la versione 1.0 che la versione 2.0

Protocollo interessato: flussi OAuth e OIDC che usano response_type=query che illustra il flusso codice di autorizzazione in alcuni casi e il flusso implicito.

Quando una risposta di autenticazione viene inviata da login.microsoftonline.com a un'applicazione tramite reindirizzamento HTTP, il servizio aggiungerà un frammento vuoto all'URL di risposta. In questo modo si impedisce una classe di attacchi di reindirizzamento assicurandosi che il browser elimini qualsiasi frammento esistente nella richiesta di autenticazione. Nessuna app deve avere una dipendenza da questo comportamento.

Agosto 2019

La semantica del modulo POST verrà applicata più rigorosamente. Gli spazi e le virgolette verranno ignorati

Data di entrata in vigore: 2 settembre 2019

Endpoint interessati: sia la versione 1.0 che la versione 2.0

Protocollo interessato: in qualsiasi luogo venga usato POST (credenziali cliente, riscatto del codice di autorizzazione, ROPC, OBO e riscatto token di aggiornamento)

A partire dalla settimana del 2 settembre 2019, le richieste di autenticazione che usano il metodo POST verranno convalidate usando standard HTTP più rigorosi. In particolare, gli spazi e le virgolette doppie (") non verranno più rimossi dai valori dei moduli di richiesta. Queste modifiche non provocheranno interruzioni nei client esistenti e contribuiranno ad assicurare che le richieste inviate a Microsoft Entra ID vengano gestite ogni volta in modo affidabile. In futuro (vedere sopra) prevediamo di rifiutare anche i parametri duplicati e di ignorare la distinta base all'interno delle richieste.

Esempio:

Al momento ?e= "f"&g=h viene analizzato in modo identico a ?e=f&g=h, quindi e == f. Con questa modifica verrà ora analizzata in modo che e == "f", probabilmente non sarà un argomento valido e la richiesta avrà esito negativo.

Luglio 2019

I token solo app per le applicazioni a tenant singolo vengono emessi solo se l'app client esiste nel tenant della risorsa

Data di entrata in vigore: 26 luglio 2019

Endpoint interessati: sia la versione 1.0 sia la versione 2.0

Protocollo interessato: credenziali client (token solo app)

Una modifica della sicurezza è stata applicata il 26 luglio 2019 modificando il modo in cui vengono rilasciati i token solo app (tramite la concessione delle credenziali client). In passatp le applicazioni erano autorizzate a ottenere token per chiamare qualsiasi altra app, indipendentemente dalla relativa presenza di questa nel tenant o nei ruoli a cui è stato concesso il consenso per tale applicazione. Questo comportamento è stato aggiornato in modo che per le risorse (talvolta denominate API Web) impostate come tenant singolo (impostazione predefinita), l'applicazione client deve esistere all'interno del tenant della risorsa. Il consenso esistente tra il client e l'API non è ancora obbligatorio e le app devono comunque eseguire controlli di autorizzazione personalizzati per accertarsi che un'attestazione roles sia presente e contenga il valore previsto per l'API.

Il messaggio di errore per questo scenario indica attualmente:

The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

Per risolvere questo problema, usare l'esperienza di consenso amministratore per creare l'entità servizio dell'applicazione client nel tenant o crearla manualmente. Questo requisito garantisce che il tenant abbia concesso all'applicazione l'autorizzazione per operare all'interno del tenant.

Richiesta di esempi

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... In questo esempio il tenant delle risorse (autorità) è contoso.com, l'app per le risorse è un'app a tenant singolo chiamata gateway.contoso.com/api per il tenant Contoso e l'app client è 00001111-aaaa-2222-bbbb-3333cccc4444. Se l'app client ha un'entità servizio all'interno di Contoso.com, questa richiesta può continuare. In caso contrario, la richiesta avrà esito negativo con l'errore precedente.

Se l'app gateway Contoso fosse un'applicazione multi-tenant, tuttavia, la richiesta continuerà indipendentemente dalla presenza di un'entità servizio all'interno di Contoso.com.

Gli URI di reindirizzamento possono ora contenere parametri di stringa di query

Data di entrata in vigore: 22 luglio 2019

Endpoint interessati: sia la versione 1.0 che la versione 2.0

Protocollo interessato: tutti i flussi

Per RFC 6749 le applicazioni Microsoft Entra possono ora registrare e usare URI di reindirizzamento (risposta) con parametri di query statici (ad esempio https://contoso.com/oauth2?idp=microsoft) per le richieste OAuth 2.0. Gli URI di reindirizzamento dinamici non sono ancora consentiti perché rappresentano un rischio per la sicurezza e non possono essere usati per conservare le informazioni sullo stato in una richiesta di autenticazione. A tale scopo usare il parametro state.

Il parametro di query statico è soggetto alla corrispondenza di stringhe per gli URI di reindirizzamento come qualsiasi altra parte dell'URI di reindirizzamento. Se non viene registrata alcuna stringa corrispondente al redirect_uri decodificato dall'URI, la richiesta verrà rifiutata. Se l'URI viene trovato nella registrazione dell'app, l'intera stringa verrà usata per reindirizzare l'utente, incluso il parametro di query statico.

A questo punto (fine luglio 2019), l'esperienza utente di registrazione dell'app nel portale di Azure blocca i parametri di query. Tuttavia, è possibile modificare manualmente il manifesto dell'applicazione per aggiungere parametri di query e testarlo nell'app.

marzo 2019

I client di ciclo verranno interrotti

Data di entrata in vigore: 25 marzo 2019

Endpoint interessati: sia la versione 1.0 che la versione 2.0

Protocollo interessato: tutti i flussi

Le applicazioni client possono talvolta comportarsi in modo errato, eseguendo centinaia richieste uguali di accesso in un breve periodo di tempo. Indipendentemente dall'esito positivo o negativo, queste richieste contribuiscono a creare un'esperienza utente di scarsa qualità e incrementano i carichi di lavoro per l'IdP, aumentando la latenza per tutti gli utenti e riducendo la disponibilità dell'IdP. Queste applicazioni operano al di fuori dei limiti di utilizzo normale e devono essere aggiornate in modo da comportarsi correttamente.

Ai client che eseguono richieste duplicate più volte verrà inviato un errore invalid_grant: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

La maggior parte dei client non dovrà modificare il comportamento per evitare questo errore. Solo i client configurati in modo errato (quelli senza memorizzazione nella cache dei token o quelli che presentano già cicli di richiesta) saranno interessati da questo errore. I client vengono rilevati in locale (tramite cookie) in base ai fattori seguenti:

• Suggerimento dell'utente, se disponibile

• Ambiti o risorse richiesti

• ID client

• URI di reindirizzamento

• Tipo di risposta e modalità

Le app che effettuano più richieste (15+) in un breve periodo di tempo (5 minuti) riceveranno un errore invalid_grant che spiega che stanno eseguendo il ciclo. I token richiesti hanno durate sufficientemente lunghe (almeno 10 minuti, 60 minuti per impostazione predefinita), quindi le richieste ripetute in questo periodo di tempo non sono necessarie.

Tutte le app devono gestire invalid_grant visualizzando un prompt interattivo, anziché richiedere automaticamente un token. Per evitare questo errore, i client devono assicurarsi di memorizzare correttamente nella cache i token ricevuti.

2018 ottobre

I codici di autorizzazione non possono più essere riutilizzati

Data di validità: 15 novembre 2018

Endpoint interessati: sia la versione 1.0 che la versione 2.0

Protocollo interessato: flusso del codice

A partire dal 15 novembre 2018, Microsoft Entra ID non accetterà più i codici di autenticazione usati in precedenza per le app. Questa modifica di sicurezza consente di allineare Microsoft Entra ID con la specifica OAuth e verrà applicata a entrambi gli endpoint v1 e v2.

Se l'app usa nuovamente i codici di autorizzazione per ottenere token per più risorse, è consigliabile usare il codice per ottenere un token di aggiornamento che consenta di acquisire token aggiuntivi per altre risorse. I codici di autorizzazione possono essere usati solo una volta, mentre quelli di aggiornamento possono essere usati più volte su più risorse. Qualsiasi nuova app che tenti di usare di nuovo un codice di autenticazione durante il flusso del codice OAuth genererà un errore invalid_grant.

Per altre informazioni sui token di aggiornamento, vedere Aggiornamento dei token di accesso. Se si usa ADAL o MSAL, questa operazione viene gestita automaticamente dalla libreria: sostituire la seconda istanza di AcquireTokenByAuthorizationCodeAsync con AcquireTokenSilentAsync.

maggio 2018

I token ID non possono essere usati per un flusso OBO

Data: 1 maggio 2018

Endpoint interessati: sia la versione 1.0 che la versione 2.0

Protocolli interessati: flusso implicito e flusso On-Behalf-Of

Dopo il 1° maggio 2018, i token ID non possono essere usati come asserzione in un flusso OBO per le nuove applicazioni. È invece necessario usare token di accesso per proteggere le API, anche tra un client e il livello intermedio della stessa applicazione. Le app registrate prima del 1° maggio 2018 continueranno a funzionare e a poter scambiare token ID per un token di accesso, ma questa non è una procedura consigliata.

Per ovviare a questa modifica, è possibile eseguire le operazioni seguenti:

1. Creare un'API Web per l'applicazione con uno o più ambiti. Questo punto di ingresso esplicito permetterà di ottenere il controllo e la sicurezza con granularità maggiore.
2. Nel manifesto dell'app, nel portale di Azure o nel portale di registrazione delle app assicurarsi che all'app sia consentito rilasciare token di accesso usando il flusso implicito. Questa funzionalità è controllata attraverso la chiave oauth2AllowImplicitFlow.
3. Quando l'applicazione client richiede un token ID tramite response_type=id_token, richiede anche un token di accesso (response_type=token) per l'API Web creata in precedenza. Di conseguenza, quando si usa l'endpoint 2.0, il parametro scope dovrebbe essere simile a api://GUID/SCOPE. Nell'endpoint v1.0 il parametro resource deve essere l'URI dell'app dell'API Web.
4. Passare questo token di accesso al livello intermedio al posto del token ID.