Begränsningar och begränsningar för omdirigerings-URI (svars-URL)

  • Artikel

En omdirigerings-URI, eller svars-URL, är den plats där auktoriseringsservern skickar användaren när appen har auktoriserats och beviljats en auktoriseringskod eller åtkomsttoken. Autentiseringsservern skickar koden eller token till om omdirigerings-URI, så det är viktigt att du registrerar rätt plats som en del av appregistreringsprocessen.

Microsoft Entra-programmodellen anger dessa begränsningar för omdirigering av URI:er:

  • Omdirigerings-URI:er måste börja med schemat https. Det finns vissa undantag för omdirigerings-URI:er för localhost .

  • Omdirigerings-URI:er är skiftlägeskänsliga och måste matcha fallet med URL-sökvägen för ditt program som körs. Om ditt program till exempel ingår som en del av sökvägen .../abc/response-oidcanger du .../ABC/response-oidc inte i omdirigerings-URI:n. Eftersom webbläsaren behandlar sökvägar som skiftlägeskänsliga kan cookies som är associerade med .../abc/response-oidc undantas om de omdirigeras till den skiftlägesmatchade .../ABC/response-oidc URL:en.

  • Omdirigerings-URI:er som inte har konfigurerats med ett sökvägssegment returneras med ett avslutande snedstreck ('/') i svaret. Detta gäller endast när svarsläget är query eller fragment.

    Exempel:

    • https://contoso.com returneras som https://contoso.com/
    • http://localhost:7071 returneras som http://localhost:7071/

  • Omdirigerings-URI:er som innehåller ett sökvägssegment läggs inte till med ett avslutande snedstreck i svaret.

    Exempel:

    • https://contoso.com/abc returneras som https://contoso.com/abc
    • https://contoso.com/abc/response-oidc returneras som https://contoso.com/abc/response-oidc

  • Omdirigerings-URI:er stöder inte specialtecken – ! $ ' ( ) , ;

Maximalt antal omdirigerings-URI:er

Den här tabellen visar det maximala antalet omdirigerings-URI:er som du kan lägga till i en appregistrering i Microsofts identitetsplattform.

Konton som loggas in Maximalt antal omdirigerings-URI:er beskrivning
Microsofts arbets- eller skolkonton i någon organisations Microsoft Entra-klientorganisation 256 signInAudience fältet i programmanifestet är inställt på antingen AzureADMyOrg eller AzureADMultipleOrgs
Personliga Microsoft-konton och arbets- och skolkonton 100 signInAudience fältet i programmanifestet är inställt på AzureADandPersonalMicrosoftAccount

Det maximala antalet omdirigerings-URI:er kan inte höjas av säkerhetsskäl. Om ditt scenario kräver fler omdirigerings-URI:er än den högsta tillåtna gränsen bör du överväga följande metod för tillståndsparameter som lösning.

Maximal URI-längd

Du kan använda högst 256 tecken för varje omdirigerings-URI som du lägger till i en appregistrering.

Omdirigerings-URI:er i programobjekt jämfört med tjänstens huvudnamn

  • Lägg alltid till omdirigerings-URI:er endast till programobjektet.
  • Lägg inte till omdirigerings-URI-värden till ett tjänsthuvudnamn eftersom dessa värden kan tas bort när objektet för tjänstens huvudnamn synkroniseras med programobjektet. Detta kan inträffa på grund av en uppdateringsåtgärd som utlöser en synkronisering mellan de två objekten.

Stöd för frågeparameter i omdirigerings-URI:er

Frågeparametrar tillåts i omdirigerings-URI:er för program som bara loggar in användare med arbets- eller skolkonton.

Frågeparametrar tillåts inte i omdirigerings-URI:er för appregistrering som konfigurerats för att logga in användare med personliga Microsoft-konton som Outlook.com (Hotmail), Messenger, OneDrive, MSN, Xbox Live eller Microsoft 365.

Inloggningspublik för appregistrering Stöder frågeparametrar i omdirigerings-URI
Endast konton i den här organisationskatalogen (endast Contoso – enskild klientorganisation)
Konton i valfri organisationskatalog (valfri Microsoft Entra-katalog – flera klienter)
Konton i valfri organisationskatalog (Alla Microsoft Entra-kataloger – Multitenant) och personliga Microsoft-konton (t.ex. Skype, Xbox)
Endast personliga Microsoft-konton

Scheman som stöds

HTTPS: HTTPS-schemat (https://) stöds för alla HTTP-baserade omdirigerings-URI:er.

HTTP: HTTP-schemat (http://) stöds endast för localhost-URI :er och bör endast användas under aktiv lokal programutveckling och testning.

Exempel på omdirigerings-URI Giltighet
https://contoso.com Giltigt
https://contoso.com/abc/response-oidc Giltigt
https://localhost Giltigt
http://contoso.com/abc/response-oidc Ogiltig
http://localhost Giltigt
http://localhost/abc Giltigt

Localhost-undantag

Enligt RFC 8252 avsnitt 8.3 och 7.3, "loopback" eller "localhost" omdirigerings-URI:er har två särskilda överväganden:

  1. http URI-scheman är acceptabla eftersom omdirigeringen aldrig lämnar enheten. Därför är båda dessa URI:er godtagbara:
    • http://localhost/myApp
    • https://localhost/myApp
  2. På grund av tillfälliga portintervall som ofta krävs av interna program ignoreras portkomponenten (till exempel :5001 eller :443) i syfte att matcha en omdirigerings-URI. Därför betraktas alla dessa URI:er som likvärdiga:
    • http://localhost/MyApp
    • http://localhost:1234/MyApp
    • http://localhost:5000/MyApp
    • http://localhost:8080/MyApp

Ur utvecklingssynpunkt innebär detta några saker:

  • Registrera inte flera omdirigerings-URI:er där endast porten skiljer sig åt. Inloggningsservern väljer en godtyckligt och använder beteendet som är associerat med omdirigerings-URI:n (till exempel om det är en web-, native-eller spa-type-omdirigering).

    Detta är särskilt viktigt när du vill använda olika autentiseringsflöden i samma programregistrering, till exempel både beviljande av auktoriseringskod och implicit flöde. Om du vill associera rätt svarsbeteende med varje omdirigerings-URI måste inloggningsservern kunna skilja mellan omdirigerings-URI:erna och kan inte göra det när endast porten skiljer sig åt.

  • Om du vill registrera flera omdirigerings-URI:er på localhost för att testa olika flöden under utvecklingen kan du särskilja dem med hjälp av sökvägskomponenten i URI:n. Matchar http://localhost/MyNativeApptill exempel http://localhost/MyWebApp inte .

  • IPv6-loopback-adressen ([::1]) stöds inte för närvarande.

Föredrar 127.0.0.1 framför localhost

Om du vill förhindra att appen bryts av felkonfigurerade brandväggar eller omdöpta nätverksgränssnitt använder du IP-literal loopback-adressen 127.0.0.1 i omdirigerings-URI:n i stället för localhost. Exempel: https://127.0.0.1

Du kan dock inte använda textrutan Omdirigerings-URI:er i Azure-portalen för att lägga till en loopback-baserad omdirigerings-URI som använder schemat http :

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

Om du vill lägga till en omdirigerings-URI som använder http schemat med 127.0.0.1 loopback-adressen måste du för närvarande ändra attributet replyUrlsWithType i programmanifestet.

Begränsningar för jokertecken i omdirigerings-URI:er

Jokertecken-URI:er kan https://*.contoso.com verka praktiska, men bör undvikas på grund av säkerhetskonsekvenser. Enligt OAuth 2.0-specifikationen (avsnitt 3.1.2 i RFC 6749) måste en omdirigeringsslutpunkts-URI vara en absolut URI. När en konfigurerad jokertecken-URI matchar en omdirigerings-URI tas därför frågesträngar och fragment i omdirigerings-URI:n bort.

Jokertecken-URI:er stöds för närvarande inte i appregistreringar som konfigurerats för att logga in personliga Microsoft-konton och arbets- eller skolkonton. Jokertecken-URI:er tillåts dock för appar som har konfigurerats för att endast logga in arbets- eller skolkonton i en organisations Microsoft Entra-klientorganisation.

Om du vill lägga till omdirigerings-URI:er med jokertecken till appregistreringar som loggar in arbets- eller skolkonton använder du programmanifestredigeraren i Appregistreringar i Azure-portalen. Även om det är möjligt att ange en omdirigerings-URI med ett jokertecken med hjälp av manifestredigeraren rekommenderar vi starkt att du följer avsnitt 3.1.2 i RFC 6749. och använd endast absoluta URI:er.

Om ditt scenario kräver fler omdirigerings-URI:er än den högsta tillåtna gränsen bör du överväga följande metod för tillståndsparameter i stället för att lägga till en omdirigerings-URI för jokertecken.

Använda en tillståndsparameter

Om du har flera underdomäner och ditt scenario kräver att du vid lyckad autentisering omdirigerar användare till samma sida som de startade från, med hjälp av en tillståndsparameter kan vara till hjälp.

I den här metoden:

  1. Skapa en "delad" omdirigerings-URI per program för att bearbeta säkerhetstoken som du får från auktoriseringsslutpunkten.
  2. Ditt program kan skicka programspecifika parametrar (till exempel underdomän-URL där användaren har sitt ursprung eller något liknande varumärkesinformation) i tillståndsparametern. När du använder en tillståndsparameter skyddar du mot CSRF-skydd enligt beskrivningen i avsnitt 10.12 i RFC 6749.
  3. De programspecifika parametrarna innehåller all information som behövs för att programmet ska återge rätt upplevelse för användaren, det vill säga konstruera rätt programtillstånd. Microsoft Entra-auktoriseringsslutpunkten tar bort HTML från tillståndsparametern så se till att du inte skickar HTML-innehåll i den här parametern.
  4. När Microsoft Entra-ID:t skickar ett svar på omdirigerings-URI:n "delad" skickas tillståndsparametern tillbaka till programmet.
  5. Programmet kan sedan använda värdet i tillståndsparametern för att avgöra vilken URL som användaren ska skickas vidare till. Kontrollera att du verifierar CSRF-skydd.

Varning

Med den här metoden kan en komprometterad klient ändra de ytterligare parametrar som skickas i tillståndsparametern, vilket omdirigerar användaren till en annan URL, vilket är det öppna omdirigeringshotet som beskrivs i RFC 6819. Därför måste klienten skydda dessa parametrar genom att kryptera tillståndet eller verifiera det på något annat sätt, som att verifiera domännamnet i omdirigerings-URI:n mot token.

Nästa steg

Läs mer om programmanifestet för appregistrering.