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

Om du vill logga in en användare måste ditt program skicka en inloggningsbegäran till Microsoft Entra-auktoriseringsslutpunkten, med en omdirigerings-URI angiven som en parameter. Omdirigerings-URI:n är en viktig säkerhetsfunktion som säkerställer att Microsoft Entra-autentiseringsservern endast skickar auktoriseringskoder och åtkomsttoken till den avsedda mottagaren. Den här artikeln beskriver funktionerna och begränsningarna för omdirigerings-URI:er i Microsofts identitetsplattform.

Vad är en omdirigerings-URI?

En omdirigerings-URI eller svars-URL är den plats där Microsoft Entra-autentiseringsservern skickar användaren när de har godkänts och beviljats en åtkomsttoken. För att logga in en användare måste ditt program skicka en inloggningsbegäran med en omdirigerings-URI som anges som en parameter, så när användaren har loggat in omdirigerar autentiseringsservern användaren och utfärdar en åtkomsttoken till den omdirigerings-URI som anges i inloggningsbegäran.

Varför måste omdirigerings-URI:er läggas till i en appregistrering?

Av säkerhetsskäl omdirigerar inte autentiseringsservern användare eller skickar token till en URI som inte läggs till i appregistreringen. Microsoft Entra-inloggningsservrar omdirigerar bara användare och skickar token för att omdirigera URI:er som har lagts till i en appregistrering. Om omdirigerings-URI:n som anges i inloggningsbegäran inte matchar någon av de omdirigerings-URI:er som du har lagt till i ditt program får du ett felmeddelande som AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application.

Mer information om felkoder finns i Felkoder för Microsoft Entra-autentisering och auktorisering.

Ska jag lägga till en omdirigerings-URI i en appregistrering?

Om du ska lägga till en omdirigerings-URI i din appregistrering beror på vilket auktoriseringsprotokoll programmet använder. Du måste lägga till lämpliga omdirigerings-URI:er i din appregistrering om programmet använder följande auktoriseringsprotokoll:

• OAuth 2.0-auktoriseringskodflöde
• Flöde för OAuth 2.0-klientautentiseringsuppgifter
• Implicit beviljandeflöde för OAuth 2.0
• OpenID Connect
• SAML-protokoll för enkel inloggning

Du behöver inte lägga till omdirigerings-URI:er i din appregistrering om programmet använder följande auktoriseringsprotokoll eller funktioner.

• Intern autentisering
• OAuth 2.0-enhetskodflöde
• OAuth 2.0 Å-Behalf-Of-flödet
• OAuth 2.0 Resursägarens flöde för lösenordsautentiseringsuppgifter
• Windows-integrerat autentiseringsflöde
• SAML 2.0 Identity Provider (IdP) för Enkel inloggning

Vilken plattform ska jag lägga till mina omdirigerings-URI:er till?

Om programmet som du skapar innehåller en eller flera omdirigerings-URI:er i appregistreringen måste du aktivera en konfiguration för offentligt klientflöde. Följande tabeller ger vägledning om vilken typ av omdirigerings-URI som du bör eller inte bör lägga till baserat på den plattform som du skapar ditt program på.

URI-konfiguration för omdirigering av webbprogram

Typ av program	Vanliga språk/ramverk	Plattform för att lägga till omdirigerings-URI i appregistrering
Ett traditionellt webbprogram där det mesta av programlogik utförs på servern	Node.js, web, ASP.NET, Python, Java, ASP.NET Core, PHP, Ruby, Blazor Server	Webb
Ett ensidesprogram där det mesta av användargränssnittslogik utförs i en webbläsare som kommunicerar med webbservern främst med hjälp av webb-API:er	JavaScript, Angular, React, Blazor WebAssembly, Vue.js	Ensidesprogram (SPA)

URI-konfiguration för omdirigering av mobil- och skrivbordsprogram

Typ av program	Vanliga språk/ramverk	Plattform för att lägga till omdirigerings-URI i appregistrering
En iOS- eller macOS-app exklusive scenarier som anges under den här tabellen	Swift, Objective-C, Xamarin	IOS/macOS
En Android-app	Java, Kotlin, Xamarin	Android
En app som körs internt på en mobil enhet eller stationär dator	Node.js elektron, Windows Desktop, UWP, React Native, Xamarin, Android, iOS/macOS	Mobil- och skrivbordsprogram

Om du skapar en iOS-app med någon av följande metoder använder du plattformen för mobil- och skrivbordsprogram för att lägga till en omdirigerings-URI:

• iOS-appar med äldre SDK:er (ADAL)
• iOS-appar med öppen källkod SDK:er (AppAuth)
• iOS-appar med teknik över flera plattformar som vi inte stöder (Flutter)
• iOS-appar implementerar våra OAuth-protokoll direkt
• macOS-appar med teknik över flera plattformar som vi inte stöder (Elektron)

Program som inte kräver en omdirigerings-URI

Typ av program	Exempel/anteckningar	Associerat OAuth-flöde
Program som körs på enheter som inte har något tangentbord	Program som körs på smart-TV, IoT-enhet eller skrivare	Mer information om enhetskodflöde
Program som hanterar lösenord som användare anger direkt, i stället för att omdirigera användare till entra värdbaserad inloggningswebbplats och låta Entra hantera användarlösenord på ett säkert sätt.	Du bör bara använda det här flödet när andra säkrare flöden, till exempel auktoriseringskodflöde, inte är livskraftiga eftersom det inte är lika säkert.	Läs mer i flödet för lösenordsautentiseringsuppgifter för resursägare
Skrivbords- eller mobilprogram som körs i Windows eller på en dator som är ansluten till en Windows-domän (AD eller Azure AD-ansluten) med Windows Integrated Auth Flow i stället för Web Account Manager	Ett skrivbords- eller mobilprogram som ska loggas in automatiskt när användaren har loggat in på Windows PC-systemet med en Entra-autentiseringsuppgift	Mer information om Windows Integrated Auth Flow

Vilka är begränsningarna för omdirigerings-URI:er för Microsoft Entra-program?

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

• Omdirigerings-URI:er måste börja med schemat https, med undantag för vissa 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.

  Exempel:

  • Om programmet 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 – ! $ ' ( ) , ;

• Omdirigerings-URI:er stöder inte internationaliserade domännamn

Maximalt antal omdirigerings-URI:er och URI-längd

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. I följande tabell visas 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

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 till programobjektet.
• Lägg aldrig till omdirigerings-URI-värden i tjänstens huvudnamn 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 alla uppdateringsåtgärder 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 (till exempel Skype och 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 webomdirigering av typen -, native-eller spa-).

  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 går sönder på grund 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 Portal för att lägga till en loopback-baserad omdirigerings-URI som använder http schemat:

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 i appregistreringar som loggar in arbets- eller skolkonton använder du programmanifestredigeraren i Appregistreringar i Azure Portal. Ä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 krä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 till omdirigerings-URI:n "delad" skickar det tillbaka tillståndsparametern 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.