Vad är nytt för autentisering?

Microsoft lägger regelbundet till och ändrar funktionerna i Microsofts identitetsplattform för att förbättra dess säkerhet, användbarhet och standardefterlevnad.

Om inget annat anges gäller de ändringar som beskrivs här endast för program som registrerats efter det angivna ikraftträdandedatumet för ändringen.

Läs den här artikeln regelbundet om du vill veta mer om:

• Kända problem och korrigeringar
• Protokolländringar
• Föråldrade funktioner

Dricks

Om du vill få ett meddelande om uppdateringar på den här sidan lägger du till den här URL:en i RSS-feedläsaren:
https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us

Augusti 2024

Federerade identitetsautentiseringsuppgifter använder nu skiftlägeskänslig matchning

Från och med september 2024

Protokollet påverkas: Identitetsfederation för arbetsbelastning

Ändra

Tidigare användes skiftlägesokänslig matchning vid matchning av de federerade identitetsautentiseringsuppgifterna (FIC) issuer, subjectoch audience värdena mot motsvarande issuer, subjectoch audience värden som finns i token som skickades till Microsoft Entra ID av en extern IdP. För att ge kunderna mer detaljerad kontroll växlar vi till att framtvinga skiftlägeskänslig matchning.

Ogiltigt exempel:

• Tokenämne: repo:contoso/contoso-org:ref:refs/heads/main
• FIC-ämne: repo:Contoso/Contoso-Org:ref:refs/heads/main

Dessa två ämnesvärden matchar inte skiftlägeskänsligt, så verifieringen misslyckas. Samma mekanism tillämpas på issuer och audience validering.

Den här ändringen tillämpas inledningsvis på program eller hanterade identiteter som skapats efter August 14th, 2024. Inaktiva program eller hanterade identiteter, som bestäms av att det inte finns några begäranden om arbetsbelastningsidentitetsfederation som görs av programmet eller den hanterade identiteten mellan perioden August 1st, 2024 till August 31st, 2024, krävs för att använda skiftlägeskänslig matchning från och med September 27th, 2024. För aktiva program kommer skiftlägesokänslig matchning vid ett senare datum som ska kommuniceras.

För att bättre markera fel på grund av skiftlägeskänslighet förnyar vi felmeddelandet för AADSTS700213. Den kommer nu att ange;

`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.` 

Platshållaren '{subject}' tillhandahåller värdet för det ämnesanspråk som finns i token som skickas från den externa IdP:t till Microsoft Entra-ID. Den här felmallen används också för skiftlägesokänsliga fel som omger issuer och audience validerar. Om det här felet uppstår bör du hitta den federerade identitetsautentiseringsuppgiften som motsvarar , subjecteller audience som anges i felet och bekräfta att motsvarande värden är likvärdiga ur ett skiftlägeskänsligt issuerperspektiv. Om det finns ett matchningsfel måste du ersätta det aktuella issuervärdet , subjecteller audience i FIC med värdet issuer, subjecteller audience som fanns i felmeddelandet.

Kommentar

För Azure App Service-kunder som använder GitHub Actions och stöter på det här felet är ett alternativ för att åtgärda detta att gå till arbetsflödesfilen under /.github/workflows i github-lagringsplatsen och uppdatera miljöegenskapen name från "Production" till "production". Den här vägledningen gäller endast för Azure App Service-scenarier. Om du stöter på det här felet i ett annat scenario kan du läsa riktlinjerna ovan.

Juni 2024

Program måste vara registrerade i en katalog

Från och med juni 2024

Slutpunkter som påverkas: v2.0 och v1.0

Protokollet påverkas: Alla flöden

Ändra

Tidigare, när du registrerar ett program med hjälp av Microsoft Entra-appregistreringsupplevelsen, om användaren var inloggad med sitt personliga Microsoft-konto (MSA), kunde de välja att endast associera programmet med sitt personliga konto. Det innebär att programmet inte skulle associeras med eller finnas i någon katalog (kallas även "klientorganisation" eller "organisation"). Från och med juni 2024 måste dock alla program registreras i en katalog. Det kan vara en befintlig katalog eller en ny katalog som den personliga Microsoft-kontoanvändaren skapar för att hysa sina Microsoft Entra-program och andra Microsoft-resurser. Användare kan enkelt skapa en ny katalog som ska användas för detta ändamål genom att ansluta till Microsoft 365 Developer Program eller registrera sig för Azure.

Att registrera ett program i en katalog, i stället för att bara associera det med ett personligt konto, har olika fördelar. Dessa kan vara:

• Program som är registrerade i en katalog har fler tillgängliga funktioner, till exempel möjligheten att lägga till fler än en ägare till appen och möjligheten att verifiera appen.
• Programmet finns på samma plats som andra Microsoft-resurser som utvecklaren använder, till exempel Azure-resurser.
• Programmet får förbättrade återhämtningsfördelar.

Detta påverkar inte några befintliga program, inklusive befintliga program som endast är associerade med ett personligt konto. Endast möjligheten att registrera nya program påverkas.

Oktober 2023

RemoteConnect UX-prompten har uppdaterats

Från och med oktober 2023

Slutpunkter som påverkas: v2.0 och v1.0

Protokollet påverkas: RemoteConnect

RemoteConnect är ett flöde mellan enheter som används för Microsoft Authentication Broker och Microsoft Intune-relaterade scenarier som omfattar primära uppdateringstoken. För att förhindra nätfiskeattacker tar RemoteConnect-flödet emot uppdaterat UX-språk för att meddela att fjärrenheten (enheten som initierade flödet) kommer att kunna komma åt alla program som används av din organisation när flödet har slutförts.

Uppmaningen som visas ser ut ungefär så här:

Juni 2023

Utelämnande av e-postanspråk med en overifierad domänägare

Från och med juni 2023

Slutpunkter som påverkas: v2.0 och v1.0

Ändra

För program med flera klientorganisationer utelämnas e-postmeddelanden som inte är domänägare som standard när det valfria email anspråket begärs i en tokennyttolast.

Ett e-postmeddelande anses vara domänägare verifierat om:

1. Domänen tillhör den klientorganisation där användarkontot finns och klientadministratören har verifierat domänen.
2. E-postmeddelandet kommer från ett Microsoft-konto (MSA).
3. E-postmeddelandet kommer från ett Google-konto.
4. E-postmeddelandet användes för autentisering med hjälp av engångslösenordsflödet (OTP).

Det bör också noteras att Facebook- och SAML/WS-Fed-konton inte har verifierade domäner.

maj 2023

Power BI-administratörsrollen kommer att byta namn till Infrastrukturadministratör.

Från och med juni 2023

Slutpunkter som påverkas:

• Lista roleDefinitions – Microsoft Graph v1.0
• Lista directoryRoles – Microsoft Graph v1.0

Ändra

Power BI-administratörsrollen har bytt namn till Infrastrukturadministratör.

Den 23 maj 2023 presenterade Microsoft Fabric, som tillhandahåller en Data Factory-baserad dataintegreringsupplevelse, Synapse-baserad datateknik, informationslager, datavetenskap och analysupplevelser i realtid och Business Intelligence (BI) med Power BI – som alla finns på en sjöcentrerad SaaS-lösning. Klientorganisationen och kapacitetsadministration för dessa upplevelser centraliseras i infrastrukturadministrationsportalen (tidigare kallad Power BI-administratörsportalen).

Från och med juni 2023 byter Power BI-administratörsrollen namn till Infrastrukturadministratör för att anpassa till rollens ändrade omfång och ansvar. Alla program inklusive Microsoft Entra-ID, Microsoft Graph-API:er, Microsoft 365 och GDAP börjar återspegla det nya rollnamnet under flera veckor.

Som en påminnelse bör programkoden och skripten inte fatta beslut baserat på rollnamn eller visningsnamn.

December 2021

AD FS-användare ser fler inloggningsmeddelanden för att säkerställa att rätt användare är inloggad.

Från och med december 2021

Slutpunkter som påverkas: Integrerad Windows-autentisering

Protokollet påverkas: Integrerad Windows-autentisering

Ändra

I dag, när en användare skickas till AD FS för att autentisera, loggas de tyst in på alla konton som redan har en session med AD FS. Den tysta inloggningen sker även om användaren har för avsikt att logga in på ett annat användarkonto. Om du vill minska frekvensen för den här felaktiga inloggningen kommer Microsoft Entra-ID från och med december att skicka parametern prompt=login till AD FS om webbkontohanteraren i Windows tillhandahåller Microsoft Entra-ID under login_hint inloggningen, vilket indikerar att en specifik användare är önskad för inloggning.

När ovanstående krav uppfylls (WAM används för att skicka användaren till Microsoft Entra-ID för att logga in, en login_hint ingår och AD FS-instansen för användarens domän stöder prompt=login) kommer användaren inte att vara tyst inloggad och i stället uppmanas att ange ett användarnamn för att fortsätta logga in på AD FS. Om de vill logga in på sin befintliga AD FS-session kan de välja alternativet "Fortsätt som aktuell användare" som visas under inloggningsprompten. Annars kan de fortsätta med det användarnamn som de tänker logga in med.

Ändringen kommer att lanseras i december 2021 under flera veckor. Det ändrar inte inloggningsbeteendet för:

• Program som använder IWA direkt
• Program som använder OAuth
• Domäner som inte är federerade till en AD FS-instans

Oktober 2021

Fel 50105 har åtgärdats för att inte returneras interaction_required under interaktiv autentisering

Från och med oktober 2021

Slutpunkter som påverkas: v2.0 och v1.0

Protokollet påverkas: Alla användarflöden för appar som kräver användartilldelning

Ändra

Fel 50105 (den aktuella beteckningen) genereras när en ej tilldelad användare försöker logga in på en app som en administratör har markerat som kräver användartilldelning. Det här är ett vanligt mönster för åtkomstkontroll och användarna måste ofta hitta en administratör för att begära tilldelning för att avblockera åtkomst. Felet hade en bugg som skulle orsaka oändliga loopar i välkodade program som hanterade felsvaret interaction_required korrekt. interaction_required uppmanar en app att utföra interaktiv autentisering, men även efter detta returnerar Microsoft Entra-ID fortfarande ett interaction_required felsvar.

Felscenariot har uppdaterats, så att appen under icke-interaktiv autentisering (där prompt=none används för att dölja UX) instrueras att utföra interaktiv autentisering med hjälp av ett interaction_required felsvar. I den efterföljande interaktiva autentiseringen kommer Microsoft Entra-ID nu att innehålla användaren och visa ett felmeddelande direkt, vilket förhindrar att en loop inträffar.

Som en påminnelse bör din programkod inte fatta beslut baserat på felkodssträngar som AADSTS50105. Följ i stället vår vägledning för felhantering och använd standardiserade autentiseringssvar som interaction_required och login_required finns i standardfältet error i svaret. De andra svarsfälten är endast avsedda för förbrukning av människor som felsöker sina problem.

Du kan granska den aktuella texten i 50105-felet och mer om uppslagstjänsten för fel: https://login.microsoftonline.com/error?code=50105.

AppId Uri i program med en enda klientorganisation kräver användning av standardschema eller verifierade domäner

Från och med oktober 2021

Slutpunkter som påverkas: v2.0 och v1.0

Protokollet påverkas: Alla flöden

Ändra

Om du lägger till eller uppdaterar AppId-URI:n för en enskild klientorganisation verifieras att domänen i HTTPS-schema-URI:n visas i listan över verifierade domäner i kundens klientorganisation eller att värdet använder standardschemat (api://{appId}) som tillhandahålls av Microsoft Entra-ID. Detta kan hindra program från att lägga till en AppId-URI om domänen inte finns i listan över verifierade domäner eller om värdet inte använder standardschemat. Mer information om verifierade domäner finns i dokumentationen om anpassade domäner.

Ändringen påverkar inte befintliga program som använder overifierade domäner i sin AppID-URI. Den validerar endast nya program eller när ett befintligt program uppdaterar en identifierar-URI eller lägger till en ny i identifierUri-samlingen. De nya begränsningarna gäller endast för URI:er som lagts till i en apps identifierUris-samling efter den 15 oktober 2021. AppId-URI:er som redan finns i ett programs identifierUris-samling när begränsningen börjar gälla den 15 oktober 2021 fortsätter att fungera även om du lägger till nya URI:er i samlingen.

Om en begäran misslyckas med verifieringskontrollen returnerar program-API:et för create/update en 400 badrequest till klienten som anger HostNameNotOnVerifiedDomain.

Följande API- och HTTP-schemabaserade program-ID URI-format stöds. Ersätt platshållarvärdena enligt beskrivningen i listan som följer tabellen.

Program-ID som stöds URI-format	Exempel på app-ID-URI:er
<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:// verifieradCustomDomain>/<sträng>	https://contoso.com/productsapi
<https:// sträng.><verifiedCustomDomain>	https://product.contoso.com
<https:// sträng.><verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId> – programidentifieraregenskapen (appId) för programobjektet.
• <string> – strängvärdet för värden eller api-sökvägssegmentet.
• <tenantId> – ett GUID som genereras av Azure för att representera klientorganisationen i Azure.
• <tenantInitialDomain> - <tenantInitialDomain.onmicrosoft.com>, där< tenantInitialDomain> är det första domännamnet som klientskapare angav när klientorganisationen skapades.
• <verifiedCustomDomain> – en verifierad anpassad domän som konfigurerats för din Microsoft Entra-klientorganisation.

Kommentar

Om du använder api:// -schemat lägger du till ett strängvärde direkt efter "api://". Till exempel api://< sträng.> Strängvärdet kan vara ett GUID eller en godtycklig sträng. Om du lägger till ett GUID-värde måste det matcha antingen app-ID:t eller klientorganisations-ID:t. URI-värdet för program-ID måste vara unikt för din klientorganisation. Om du lägger till api://< tenantId> som program-ID-URI kan ingen annan använda den URI:n i någon annan app. Rekommendationen är att använda api://< appId> i stället eller HTTP-schemat.

Viktigt!

URI-värdet för program-ID får inte sluta med snedstrecket "/".

Kommentar

Även om det är säkert att ta bort identifierarenUris för appregistreringar i den aktuella klientorganisationen kan det leda till att klienter misslyckas med andra appregistreringar om identifieraren tas bort.

Augusti 2021

Villkorsstyrd åtkomst utlöses endast för uttryckligen begärda omfång

Från och med augusti 2021, med gradvis distribution som börjar i april.

Slutpunkter som påverkas: v2.0

Protokollet påverkas: Alla flöden med dynamiskt medgivande

Program som använder dynamiskt medgivande i dag får alla behörigheter som de har medgivande för, även om de inte begärdes med namn i parametern scope . En app som endast user.read begär men med medgivande till files.read kan till exempel tvingas att godkänna kravet på villkorsstyrd åtkomst som tilldelats för files.read.

För att minska antalet onödiga frågor om villkorlig åtkomst ändrar Microsoft Entra-ID hur omfång tillhandahålls till program så att endast uttryckligen begärda omfång utlöser villkorsstyrd åtkomst. Program som förlitar sig på Microsoft Entra-ID:ts tidigare beteende att inkludera alla omfång i token – oavsett om de begärs eller inte – kan brytas på grund av saknade omfång.

Appar får nu åtkomsttoken med en blandning av behörigheter: begärda token och de som de har medgivande för som inte kräver frågor om villkorsstyrd åtkomst. Åtkomstomfånget för token återspeglas i tokensvarets scope parameter.

Den här ändringen görs för alla appar utom de som har ett observerat beroende av det här beteendet. Utvecklare får uppsökande information om de är undantagna från den här ändringen, eftersom de kan ha ett beroende av ytterligare frågor om villkorsstyrd åtkomst.

Exempel

En app har medgivande för user.read, files.readwriteoch tasks.read. files.readwrite har principer för villkorsstyrd åtkomst tillämpade på den, medan de andra två inte har det. Om en app gör en tokenbegäran för , och den för närvarande inloggade användaren inte har godkänt några principer för scope=user.readvillkorsstyrd åtkomst, kommer den resulterande token att vara för behörigheterna user.read och tasks.read . tasks.read ingår eftersom appen har medgivande för den och den inte kräver att en princip för villkorsstyrd åtkomst tillämpas.

Om appen sedan begär scope=files.readwriteutlöser den villkorliga åtkomst som krävs av klientorganisationen, vilket tvingar appen att visa en interaktiv auth-prompt där principen för villkorsstyrd åtkomst kan uppfyllas. Token som returneras har alla tre omfången i sig.

Om appen sedan gör en sista begäran för något av de tre omfången (till exempel scope=tasks.read), ser Microsoft Entra-ID att användaren redan har slutfört de principer för villkorsstyrd åtkomst som behövs för files.readwriteoch återigen utfärda en token med alla tre behörigheterna i den.

Juni 2021

Enhetskodflödets UX innehåller nu en appbekräftelsefråga

Från och med juni 2021.

Slutpunkter som påverkas: v2.0 och v1.0

Protokollet påverkas: Enhetens kodflöde

För att förhindra nätfiskeattacker innehåller enhetskodflödet nu en uppmaning som verifierar att användaren loggar in på den app som de förväntar sig.

Uppmaningen som visas ser ut så här:

Maj 2020

Felkorrigering: Microsoft Entra-ID:t url-kodar inte längre tillståndsparametern två gånger

Giltighetsdatum: maj 2021

Slutpunkter som påverkas: v1.0 och v2.0

Protokollet påverkas: Alla flöden som besöker /authorize slutpunkten (implicit flöde och auktoriseringskodflöde)

En bugg hittades och åtgärdades i Microsoft Entra-auktoriseringssvaret. Under autentiseringen /authorize ingår parametern state från begäran i svaret för att bevara apptillståndet och förhindra CSRF-attacker. Microsoft Entra-ID:t url-kodade parametern state felaktigt innan den infogades i svaret, där den kodades en gång till. Detta skulle leda till att program felaktigt avvisar svaret från Microsoft Entra-ID.

Microsoft Entra-ID:t kommer inte längre att dubbelkoda den här parametern, vilket gör att appar kan parsa resultatet korrekt. Den här ändringen görs för alla program.

Azure Government-slutpunkter ändras

Från och med den 5 maj 2020 (slutar juni 2020)

Slutpunkter som påverkas: Alla

Protokollet påverkas: Alla flöden

Den 1 juni 2018 ändrades den officiella Microsoft Entra-utfärdaren för Azure Government från https://login-us.microsoftonline.com till https://login.microsoftonline.us. Den här ändringen gäller även för Microsoft 365 GCC High och DoD, som Även Azure Government Microsoft Entra ID tjänster. Om du äger ett program i en us government-klientorganisation måste du uppdatera ditt program för att logga in användare på .us slutpunkten.

Den 5 maj 2020 börjar Microsoft Entra-ID:t framtvinga slutpunktsändringen, vilket blockerar myndighetsanvändare från att logga in på appar som finns i amerikanska myndighetsklientorganisationer med hjälp av den offentliga slutpunkten (microsoftonline.com). Berörda appar börjar se ett fel AADSTS900439 - USGClientNotSupportedOnPublicEndpoint. Det här felet anger att appen försöker logga in en us government-användare på slutpunkten för det offentliga molnet. Om din app finns i en klientorganisation för offentliga moln och är avsedd att stödja amerikanska myndighetsanvändare måste du uppdatera din app för att uttryckligen stödja dem. Detta kan kräva att du skapar en ny appregistrering i US Government-molnet.

Tillämpningen av den här ändringen kommer att göras med hjälp av en gradvis distribution baserat på hur ofta användare från US Government-molnet loggar in på programmet – appar som loggar in användare av amerikanska myndigheter ser sällan verkställighet först och appar som ofta används av amerikanska myndigheters användare kommer senast att ha tillämpning. Vi förväntar oss att verkställigheten ska vara klar för alla appar i juni 2020.

Mer information finns i azure government-blogginlägget om den här migreringen.

Mars 2020

Användarlösenord begränsas till 256 tecken.

Giltighetsdatum: 13 mars 2020

Slutpunkter som påverkas: Alla

Protokollet påverkas: Alla användarflöden.

Användare med lösenord som är längre än 256 tecken och som loggar in direkt på Microsoft Entra-ID (inte en federerad IDP, som AD FS) uppmanas att ändra sina lösenord innan de kan logga in. Administratörer kan ta emot begäranden om att återställa användarens lösenord.

Felet i inloggningsloggarna liknar AADSTS 50052: InvalidPasswordExceedsMaxLength.

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

Sanering:

Användaren kan inte logga in eftersom lösenordet överskrider den tillåtna maximala längden. De bör kontakta administratören för att återställa lösenordet. Om SSPR är aktiverat för klientorganisationen kan de återställa sitt lösenord genom att följa länken "Glömt lösenordet".

Februari 2020

Tomma fragment läggs till i varje HTTP-omdirigering från inloggningsslutpunkten.

Giltighetsdatum: 8 februari 2020

Slutpunkter som påverkas: Både v1.0 och v2.0

Protokoll som påverkas: OAuth- och OIDC-flöden som använder response_type=query – detta omfattar auktoriseringskodflödet i vissa fall och det implicita flödet.

När ett autentiseringssvar skickas från login.microsoftonline.com till ett program via HTTP-omdirigering lägger tjänsten till ett tomt fragment i svars-URL:en. Detta förhindrar en klass av omdirigeringsattacker genom att se till att webbläsaren rensar bort alla befintliga fragment i autentiseringsbegäran. Inga appar ska ha ett beroende av det här beteendet.

Augusti 2019

POST-formulärsemantik tillämpas striktare – blanksteg och citattecken ignoreras

Giltighetsdatum: 2 september 2019

Slutpunkter som påverkas: Både v1.0 och v2.0

Protokollet påverkas: Var som helst post används (klientautentiseringsuppgifter, inlösen av auktoriseringskod, ROPC, OBO och inlösen av uppdateringstoken)

Från och med veckan den 2 september 2019 verifieras autentiseringsbegäranden som använder POST-metoden med striktare HTTP-standarder. Mer specifikt tas blanksteg och dubbla citattecken (") inte längre bort från formulärvärden för begäran. Dessa ändringar förväntas inte bryta några befintliga klienter och ser till att begäranden som skickas till Microsoft Entra-ID hanteras på ett tillförlitligt sätt varje gång. I framtiden (se ovan) planerar vi att dessutom avvisa dubblettparametrar och ignorera bommen i begäranden.

Exempel:

?e= "f"&g=h Idag parsas identiskt som ?e=f&g=h - så e == f. Med den här ändringen skulle den nu parsas så att e == "f" - detta är osannolikt att vara ett giltigt argument, och begäran skulle nu misslyckas.

Juli 2019

Endast apptoken för program med en klientorganisation utfärdas endast om klientappen finns i resursklientorganisationen

Giltighetsdatum: 26 juli 2019

Slutpunkter som påverkas: Både v1.0 och v2.0

Protokollet påverkas: Klientautentiseringsuppgifter (endast apptoken)

En säkerhetsändring trädde i kraft den 26 juli 2019 och ändrar hur endast apptoken (via beviljandet av klientautentiseringsuppgifter) utfärdas. Tidigare tilläts program att hämta token för att anropa andra appar, oavsett närvaro i klientorganisationen eller roller som godkänts för programmet. Det här beteendet har uppdaterats så att klientprogrammet måste finnas i resursklientorganisationen för resurser (kallas ibland webb-API:er) som en enda klientorganisation (standard). Befintligt medgivande mellan klienten och API:et krävs fortfarande inte, och appar bör fortfarande utföra sina egna auktoriseringskontroller för att säkerställa att ett roles anspråk finns och innehåller det förväntade värdet för API:et.

Felmeddelandet för det här scenariot anger för närvarande:

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.

Du kan åtgärda problemet genom att använda administratörsmedgivande för att skapa klientprogramtjänstens huvudnamn i klientorganisationen eller skapa det manuellt. Det här kravet säkerställer att klientorganisationen har gett programmet behörighet att arbeta inom klientorganisationen.

Exempelbegäranden

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... I det här exemplet är resursklientorganisationen (utfärdaren) contoso.com, resursappen är en app med en enda klientorganisation som anropas gateway.contoso.com/api för Contoso-klientorganisationen och klientappen är 00001111-aaaa-2222-bbbb-3333cccc4444. Om klientappen har ett huvudnamn för tjänsten inom Contoso.com kan den här begäran fortsätta. Om det inte gör det misslyckas dock begäran med felet ovan.

Om Contoso-gatewayappen var ett program med flera klienter fortsätter dock begäran oavsett om klientappen har ett huvudnamn för tjänsten inom Contoso.com.

Omdirigerings-URI:er kan nu innehålla frågesträngsparametrar

Giltighetsdatum: 22 juli 2019

Slutpunkter som påverkas: Både v1.0 och v2.0

Protokollet påverkas: Alla flöden

Enligt RFC 6749 kan Microsoft Entra-program nu registrera och använda omdirigerings-URI:er (svar) med statiska frågeparametrar (till exempel https://contoso.com/oauth2?idp=microsoft) för OAuth 2.0-begäranden. Dynamiska omdirigerings-URI:er är fortfarande förbjudna eftersom de utgör en säkerhetsrisk, och detta kan inte användas för att behålla tillståndsinformation i en autentiseringsbegäran – för det använder du parametern state .

Den statiska frågeparametern omfattas av strängmatchning för omdirigerings-URI:er som alla andra delar av omdirigerings-URI:n – om ingen sträng har registrerats som matchar den URI-avkodade redirect_uri avvisas begäran. Om URI:n hittas i appregistreringen används hela strängen för att omdirigera användaren, inklusive den statiska frågeparametern.

För närvarande (slutet av juli 2019) blockerar appregistrerings-UX i Azure Portal fortfarande frågeparametrar. Du kan dock redigera programmanifestet manuellt för att lägga till frågeparametrar och testa detta i din app.

Mars 2019

Loopningsklienter avbryts

Giltighetsdatum: 25 mars 2019

Slutpunkter som påverkas: Både v1.0 och v2.0

Protokollet påverkas: Alla flöden

Klientprogram kan ibland ha fel och utfärda hundratals av samma inloggningsbegäran under en kort tidsperiod. Dessa begäranden kanske eller kanske inte lyckas, men de bidrar alla till dålig användarupplevelse och ökade arbetsbelastningar för IDP: t, ökar svarstiden för alla användare och minskar tillgängligheten för IDP. Dessa program fungerar utanför gränserna för normal användning och bör uppdateras för att fungera korrekt.

Klienter som utfärdar duplicerade begäranden flera gånger skickas ett invalid_grant fel: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

De flesta klienter behöver inte ändra beteendet för att undvika det här felet. Endast felkonfigurerade klienter (de som saknar tokencachelagring eller de som redan har promptloopar) påverkas av det här felet. Klienter spåras per instans lokalt (via cookie) utifrån följande faktorer:

• Användartips, om det finns

• Omfattningar eller resurser som begärs

• Client ID

• Omdirigerings-URI

• Svarstyp och -läge

Appar som gör flera begäranden (15+) på kort tid (5 minuter) får ett invalid_grant fel som förklarar att de loopar. De token som begärs har tillräckligt lång livslängd (minst 10 minuter, 60 minuter som standard), så upprepade begäranden under den här tidsperioden är onödiga.

Alla appar ska hantera invalid_grant genom att visa en interaktiv fråga i stället för att tyst begära en token. För att undvika det här felet bör klienterna se till att de cachelagrar de token som de får korrekt.

2018 oktober

Auktoriseringskoder kan inte längre återanvändas

Giltighetsdatum: 15 november 2018

Slutpunkter som påverkas: Både v1.0 och v2.0

Protokollet påverkas: Kodflöde

Från och med den 15 november 2018 slutar Microsoft Entra-ID:t att acceptera tidigare använda autentiseringskoder för appar. Den här säkerhetsändringen hjälper till att anpassa Microsoft Entra-ID till OAuth-specifikationen och tillämpas på både v1- och v2-slutpunkterna.

Om din app återanvänder auktoriseringskoder för att hämta token för flera resurser rekommenderar vi att du använder koden för att hämta en uppdateringstoken och sedan använder den uppdateringstoken för att hämta ytterligare token för andra resurser. Auktoriseringskoder kan bara användas en gång, men uppdateringstoken kan användas flera gånger över flera resurser. Alla nya appar som försöker återanvända en autentiseringskod under OAuth-kodflödet får ett invalid_grant fel.

Mer information om uppdateringstoken finns i Uppdatera åtkomsttoken. Om du använder ADAL eller MSAL hanteras detta åt dig av biblioteket – ersätt den andra instansen av AcquireTokenByAuthorizationCodeAsync med AcquireTokenSilentAsync.

Maj 2018

ID-token kan inte användas för OBO-flödet

Datum: 1 maj 2018

Slutpunkter som påverkas: Både v1.0 och v2.0

Protokoll som påverkas: Implicit flöde och å uppdrag av flöde

Efter den 1 maj 2018 kan id_tokens inte användas som försäkran i ett OBO-flöde för nya program. Åtkomsttoken ska användas i stället för att skydda API:er, även mellan en klient och en mellannivå i samma program. Appar som registrerats före den 1 maj 2018 fortsätter att fungera och kan utbyta id_tokens mot en åtkomsttoken. Det här mönstret anses dock inte vara bästa praxis.

Om du vill kringgå den här ändringen kan du göra följande:

1. Skapa ett webb-API för ditt program med ett eller flera omfång. Den här explicita startpunkten tillåter finare detaljerad kontroll och säkerhet.
2. I appens manifest i Azure Portal eller appregistreringsportalen kontrollerar du att appen får utfärda åtkomsttoken via det implicita flödet. Detta styrs via oauth2AllowImplicitFlow nyckeln.
3. När klientprogrammet begär en id_token via response_type=id_tokenbegär du även en åtkomsttoken (response_type=token) för webb-API:et som skapades ovan. När du använder v2.0-slutpunkten bör parametern scope därför se ut ungefär api://GUID/SCOPEsom . På v1.0-slutpunkten ska parametern resource vara app-URI:n för webb-API:et.
4. Skicka den här åtkomsttoken till mellannivån i stället för id_token.