Begränsningar och begränsningar för omdirigerings-URI (svars-URL)
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-oidc
anger 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 ärquery
ellerfragment
.Exempel:
https://contoso.com
returneras somhttps://contoso.com/
http://localhost:7071
returneras somhttp://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 somhttps://contoso.com/abc
https://contoso.com/abc/response-oidc
returneras somhttps://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:
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
- 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
-ellerspa
-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/MyNativeApp
till exempelhttp://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
:
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:
- Skapa en "delad" omdirigerings-URI per program för att bearbeta säkerhetstoken som du får från auktoriseringsslutpunkten.
- 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.
- 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.
- När Microsoft Entra-ID:t skickar ett svar på omdirigerings-URI:n "delad" skickas tillståndsparametern tillbaka till programmet.
- 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.