Restrizioni e limitazioni dell'URI di reindirizzamento (URL di risposta)

  • Articolo

Un URI di reindirizzamento o un URL di risposta è il percorso a cui il server di autorizzazione invia l'utente dopo che l'app è stata autorizzata correttamente e ha ottenuto un codice di autorizzazione o un token di accesso. Il server di autorizzazione invia il codice o il token all'URI di reindirizzamento, quindi è importante registrare la posizione corretta come parte del processo di registrazione dell'app.

Il modello di applicazione Microsoft Entra specifica queste restrizioni per reindirizzare gli URI:

  • Gli URI di reindirizzamento devono iniziare con lo schema https. Esistono alcune eccezioni per gli URI di reindirizzamento localhost .

  • Gli URI di reindirizzamento fanno distinzione tra maiuscole e minuscole e devono corrispondere al caso del percorso URL dell'applicazione in esecuzione. Ad esempio, se l'applicazione include come parte del percorso .../abc/response-oidc, non specificare .../ABC/response-oidc nell'URI di reindirizzamento. Poiché il Web browser rileva la distinzione tra maiuscole e minuscole nei percorsi, è possibile che i cookie associati a .../abc/response-oidc vengano esclusi se reindirizzati all'URL .../ABC/response-oidc senza la corrispondenza tra maiuscole e minuscole.

  • Gli URI di reindirizzamento non configurati con un segmento di percorso vengono restituiti con una barra finale ('/) nella risposta. Questo vale solo quando la modalità di risposta è query o fragment.

    Esempi:

    • https://contoso.com viene restituito come https://contoso.com/
    • http://localhost:7071 viene restituito come http://localhost:7071/

  • Gli URI di reindirizzamento che contengono un segmento di percorso non vengono aggiunti con una barra finale nella risposta.

    Esempi:

    • https://contoso.com/abc viene restituito come https://contoso.com/abc
    • https://contoso.com/abc/response-oidc viene restituito come https://contoso.com/abc/response-oidc

  • Gli URI di reindirizzamento non supportano caratteri speciali: ! $ ' ( ) , ;

Numero massimo di URI di reindirizzamento

Questa tabella mostra il numero massimo di URI di reindirizzamento che è possibile aggiungere a una registrazione dell'app in Microsoft Identity Platform.

Account visitati Numero massimo di URI di reindirizzamento Descrizione
Account microsoft aziendali o dell'istituto di istruzione nel tenant Microsoft Entra di qualsiasi organizzazione 256 Il campo signInAudience nel manifesto dell'applicazione è impostato su AzureADMyOrg o su AzureADMultipleOrgs
Account Microsoft personali e account aziendali e dell'istituto di istruzione 100 Il campo signInAudience nel manifesto dell'applicazione è impostato su AzureADandPersonalMicrosoftAccount

Il numero massimo di URI di reindirizzamento non può essere generato per motivi di sicurezza. Se lo scenario richiede più URI di reindirizzamento rispetto al limite massimo consentito, prendere in considerazione l'approccio del parametro di stato seguente come soluzione.

Lunghezza massima dell'URI

È possibile usare un massimo di 256 caratteri per ogni URI di reindirizzamento aggiunto a una registrazione dell'app.

URI di reindirizzamento negli oggetti applicazione e entità servizio

  • Aggiungere sempre gli URI di reindirizzamento solo all'oggetto applicazione.
  • Non aggiungere valori URI di reindirizzamento a un'entità servizio perché potrebbero essere rimossi quando l'oggetto entità servizio viene sincronizzato con l'oggetto applicazione. Ciò può verificarsi a causa di qualsiasi operazione di aggiornamento che attiva una sincronizzazione tra i due oggetti.

Supporto dei parametri di query negli URI di reindirizzamento

I parametri di query sono consentiti negli URI di reindirizzamento per le applicazioni che accedono solo agli utenti con account aziendali o dell'istituto di istruzione.

I parametri di query non sono consentiti negli URI di reindirizzamento per qualsiasi registrazione dell'app configurata per l'accesso degli utenti con account Microsoft personali, ad esempio Outlook.com (Hotmail), Messenger, OneDrive, MSN, Xbox Live o Microsoft 365.

Gruppo di destinatari per l'accesso alla registrazione dell'app Supporta i parametri di query nell'URI di reindirizzamento
Account solo in questa directory dell'organizzazione (Solo Contoso - Tenant singolo)
Account in qualsiasi directory dell'organizzazione (qualsiasi directory Microsoft Entra - multi-tenant)
Account in qualsiasi directory organizzativa (qualsiasi directory Di Microsoft Entra - Multi-tenant) e account Microsoft personali (ad esempio Skype, Xbox)
Solo account Microsoft personali

Schemi supportati

HTTPS: lo schema HTTPS (https://) è supportato per tutti gli URI di reindirizzamento basati su HTTP.

HTTP: lo schema HTTP (http://) è supportato solo per gli URI localhost e deve essere usato solo durante lo sviluppo e il test delle applicazioni locali attive.

URI di reindirizzamento di esempio Validità
https://contoso.com Valido
https://contoso.com/abc/response-oidc Valido
https://localhost Valido
http://contoso.com/abc/response-oidc Non valido
http://localhost Valido
http://localhost/abc Valido

Eccezioni localhost

Per RFC 8252 sezioni 8.3 e 7.3, gli URI di reindirizzamento "loopback" o "localhost" sono dotati di due considerazioni speciali:

  1. http Gli schemi URI sono accettabili perché il reindirizzamento non lascia mai il dispositivo. Di conseguenza, entrambi questi URI sono accettabili:
    • http://localhost/myApp
    • https://localhost/myApp
  2. A causa di intervalli di porte temporanei spesso richiesti dalle applicazioni native, il componente della porta (ad esempio, :5001 o :443) viene ignorato ai fini della corrispondenza di un URI di reindirizzamento. Di conseguenza, tutti questi URI sono considerati equivalenti:
    • http://localhost/MyApp
    • http://localhost:1234/MyApp
    • http://localhost:5000/MyApp
    • http://localhost:8080/MyApp

Dal punto di vista dello sviluppo, ciò significa alcuni aspetti:

  • Non registrare più URI di reindirizzamento in cui è diversa solo la porta. Il server di accesso selezionerà un server di accesso arbitrariamente e userà il comportamento associato a tale URI di reindirizzamento, ad esempio se si tratta di un webreindirizzamento -, native-o spa-type.

    Ciò è particolarmente importante quando si vogliono usare flussi di autenticazione diversi nella stessa registrazione dell'applicazione, ad esempio sia la concessione del codice di autorizzazione che il flusso implicito. Per associare il comportamento di risposta corretto a ogni URI di reindirizzamento, il server di accesso deve essere in grado di distinguere tra gli URI di reindirizzamento e non può farlo quando solo la porta è diversa.

  • Per registrare più URI di reindirizzamento in localhost per testare flussi diversi durante lo sviluppo, differenziarli usando il componente path dell'URI. Ad esempio, http://localhost/MyWebApp non corrisponde a http://localhost/MyNativeApp.

  • L'indirizzo di loopback IPv6 ([::1]) non è attualmente supportato.

Preferire 127.0.0.1 rispetto a localhost

Per impedire che l'app venga interrotta da firewall non configurati correttamente o interfacce di rete rinominate, usare l'indirizzo 127.0.0.1 di loopback letterale IP nell'URI di localhostreindirizzamento anziché . Ad esempio, https://127.0.0.1.

Non è tuttavia possibile usare la casella di testo URI di reindirizzamento nella portale di Azure per aggiungere un URI di reindirizzamento basato su loopback che usa lo http schema:

Error dialog in Azure portal showing disallowed http-based loopback redirect URI

Per aggiungere un URI di reindirizzamento che usa lo http schema con l'indirizzo 127.0.0.1 di loopback, è attualmente necessario modificare l'attributo replyUrlsWithType nel manifesto dell'applicazione.

Restrizioni sui caratteri jolly negli URI di reindirizzamento

Gli URI con caratteri jolly come https://*.contoso.com possono sembrare pratici, ma devono essere evitati a causa di implicazioni per la sicurezza. In base alla specifica OAuth 2.0 (sezione 3.1.2 del documento RFC 6749), un URI di endpoint di reindirizzamento deve essere un URI assoluto. Di conseguenza, quando un URI con caratteri jolly configurato corrisponde a un URI di reindirizzamento, le stringhe di query e i frammenti nell'URI di reindirizzamento vengono rimossi.

Gli URI con caratteri jolly non sono attualmente supportati nelle registrazioni delle app configurate per accedere agli account Microsoft personali e agli account aziendali o dell'istituto di istruzione. Gli URI con caratteri jolly sono tuttavia consentiti per le app configurate per l'accesso solo agli account aziendali o dell'istituto di istruzione nel tenant di Microsoft Entra di un'organizzazione.

Per aggiungere URI di reindirizzamento con caratteri jolly alle registrazioni dell'app che accedono agli account aziendali o dell'istituto di istruzione, usare l'editor del manifesto dell'applicazione in Registrazioni app nel portale di Azure. Anche se è possibile impostare un URI di reindirizzamento con un carattere jolly usando l'editor del manifesto, è consigliabile attenersi alla sezione 3.1.2 di RFC 6749. e usano solo URI assoluti.

Se lo scenario richiede più URI di reindirizzamento rispetto al limite massimo consentito, prendere in considerazione l'approccio del parametro di stato seguente anziché aggiungere un URI di reindirizzamento con caratteri jolly.

Uso di un parametro di stato

Se sono presenti diversi sottodomini e lo scenario richiede che, al termine dell'autenticazione, gli utenti vengano reindirizzati alla stessa pagina da cui sono stati avviati, l'uso di un parametro di stato potrebbe essere utile.

In questo approccio:

  1. Creare un URI di reindirizzamento "condiviso" per ogni applicazione per elaborare i token di sicurezza che si ricevono dall'endpoint di autorizzazione.
  2. L'applicazione può inviare parametri specifici dell'applicazione ,ad esempio l'URL del sottodominio in cui l'utente ha avuto origine o qualsiasi informazione di personalizzazione, nel parametro di stato. Quando si usa un parametro di stato, proteggersi dalla protezione CSRF come specificato nella sezione 10.12 di RFC 6749.
  3. I parametri specifici dell’applicazione includono tutte le informazioni necessarie all’applicazione per funzionare correttamente, vale a dire, creare lo stato dell'applicazione appropriato. L'endpoint di autorizzazione Di Microsoft Entra rimuove il codice HTML dal parametro di stato, quindi assicurarsi di non passare il contenuto HTML in questo parametro.
  4. Quando Microsoft Entra ID invia una risposta all'URI di reindirizzamento "condiviso", invierà di nuovo il parametro di stato all'applicazione.
  5. L’applicazione può quindi usare il valore del parametro di stato per determinare a quale URL indirizzare l’utente. Assicurarsi di convalidare la protezione CSRF.

Avviso

Questo approccio consente a un client compromesso di modificare i parametri aggiuntivi inviati nel parametro di stato, reindirizzando quindi l'utente a un URL diverso. Questa è la minaccia del redirector aperto descritta nella specifica RFC 6819. Pertanto, il client deve proteggere questi parametri crittografando lo stato o verificandolo con altri mezzi, ad esempio convalidando il nome di dominio nell'URI di reindirizzamento sul token.

Passaggi successivi

Informazioni sul manifesto dell'applicazione di registrazione dell'app.