Wat is er nieuw voor verificatie?

Microsoft voegt regelmatig functies en functionaliteit aan het Microsoft-identiteitsplatform toe en wijzigt deze om van de beveiliging, bruikbaarheid en naleving van standaarden te verbeteren.

Tenzij anders vermeld, gelden de hier beschreven wijzigingen alleen voor toepassingen die zijn geregistreerd na de aangegeven ingangsdatum van de wijziging.

Raadpleeg dit artikel regelmatig voor meer informatie over:

• Bekende problemen en oplossingen
• Protocolwijzigingen
• Vervangen functionaliteit

Tip

Als u op de hoogte wilt worden gesteld van updates op deze pagina, voegt u deze URL toe aan uw RSS-feedlezer:
https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us

Augustus 2024

Federatieve identiteitsreferenties gebruiken nu hoofdlettergevoelige overeenkomsten

Ingangsdatum: september 2024

Beïnvloed protocol: federatie van workloadidentiteit

Wijzigen

Voorheen werd bij het vergelijken van de Federatieve identiteitsreferenties (FIC) issuersubjecten audience waarden ten opzichte van de bijbehorende issuer, subjecten audience waarden die zijn opgenomen in het token dat door een externe IdP naar Microsoft Entra-id is verzonden, hoofdlettergevoelige overeenkomsten gebruikt. Om klanten meer nauwkeurige controle te bieden, schakelen we over naar het afdwingen van hoofdlettergevoelige overeenkomsten.

Ongeldig voorbeeld:

• Tokenonderwerp: repo:contoso/contoso-org:ref:refs/heads/main
• FIC-onderwerp: repo:Contoso/Contoso-Org:ref:refs/heads/main

Deze twee onderwerpwaarden komen niet hoofdlettergevoelig overeen, dus de validatie mislukt. Hetzelfde mechanisme wordt toegepast op issuer en audience validatie.

Deze wijziging wordt in eerste instantie toegepast op toepassingen of beheerde identiteiten die zijn gemaakt na August 14th, 2024. Inactieve toepassingen of beheerde identiteiten, die worden bepaald door nul aanvragen voor workloadidentiteitsfederatie die zijn gedaan door de genoemde toepassing of beheerde identiteit tussen de periode August 1st, 2024 tot August 31st, 2024en met , zijn vereist voor het gebruik van hoofdlettergevoelige overeenkomsten September 27th, 2024. Voor actieve toepassingen komt hoofdlettergevoelige overeenkomst op een later tijdstip te worden gecommuniceerd.

Om fouten beter te markeren vanwege hoofdlettergevoeligheid, wordt het foutbericht voor AADSTS700213. Het zal nu een status hebben;

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

De tijdelijke aanduiding '{subject}' biedt de waarde van de onderwerpclaim die is opgenomen in het token dat wordt verzonden van de externe IdP naar Microsoft Entra-id. Deze foutsjabloon wordt ook gebruikt voor hoofdlettergevoelige fouten rondom issuer en audience validatie. Als u deze fout tegenkomt, moet u de federatieve identiteitsreferentie vinden die overeenkomt met de issuer, subjectof audience vermeld in de fout en controleert u of de bijbehorende waarden gelijkwaardig zijn vanuit een hoofdlettergevoelig perspectief. Als er sprake is van een onjuiste overeenkomst, moet u de huidige issuer, subjectof audience waarde in de FIC vervangen door de issuer, subjectof audience de waarde die in het foutbericht is opgenomen.

Notitie

Voor Azure-app Service-klanten die GitHub Actions gebruiken en deze fout tegenkomt, kunt u dit adresseren door naar uw werkstroombestand in /.github/workflows uw GitHub-opslagplaats te gaan en de omgevingseigenschap name bij te werken van "Production" naar "production". Deze richtlijnen zijn alleen van toepassing op Azure-app Service-scenario's. Als u deze fout in een ander scenario tegenkomt, raadpleegt u de bovenstaande richtlijnen.

Juni 2024

Toepassingen moeten worden geregistreerd in een directory

Ingangsdatum: juni 2024

Betrokken eindpunten: v2.0 en v1.0

Betrokken protocol: alle stromen

Wijzigen

Voorheen, bij het registreren van een toepassing met de Microsoft Entra-app-registraties, als de gebruiker was aangemeld met zijn persoonlijke Microsoft-account (MSA), konden ze ervoor kiezen om de toepassing alleen te koppelen aan hun persoonlijke account. Dit betekent dat de toepassing niet zou worden gekoppeld aan of opgenomen in een map (ook wel 'tenant' of 'organisatie' genoemd). Vanaf juni 2024 moeten alle toepassingen echter worden geregistreerd in een directory. Dit kan een bestaande directory zijn, of een nieuwe map die de persoonlijke Microsoft-accountgebruiker maakt voor het huis van hun Microsoft Entra-toepassingen en andere Microsoft-resources. Gebruikers kunnen eenvoudig een nieuwe directory maken die voor dit doel kan worden gebruikt door deel te nemen aan het Microsoft 365 Developer Program of zich aan te melden voor Azure.

Het registreren van een toepassing in een directory, in plaats van deze alleen te koppelen aan een persoonlijk account, heeft verschillende voordelen. Deze omvatten:

• Toepassingen die zijn geregistreerd in een directory, hebben meer functies beschikbaar, zoals de mogelijkheid om meer dan één eigenaar aan de app toe te voegen en de mogelijkheid om de app te verifiëren .
• De toepassing bevindt zich op dezelfde locatie als andere Microsoft-resources die de ontwikkelaar gebruikt, zoals Azure-resources.
• De toepassing krijgt verbeterde tolerantievoordelen.

Dit heeft geen invloed op bestaande toepassingen, inclusief bestaande toepassingen die alleen zijn gekoppeld aan een persoonlijk account. Alleen de mogelijkheid om nieuwe toepassingen te registreren, wordt beïnvloed.

Oktober 2023

RemoteConnect UX-prompt bijgewerkt

Ingangsdatum: oktober 2023

Betrokken eindpunten: v2.0 en v1.0

Protocol beïnvloed: RemoteConnect

RemoteConnect is een stroom voor meerdere apparaten die wordt gebruikt voor gerelateerde scenario's van Microsoft Authentication Broker en Microsoft Intune met betrekking tot primaire vernieuwingstokens. Om phishingaanvallen te voorkomen, ontvangt de RemoteConnect-stroom bijgewerkte UX-taal om aan te roepen dat het externe apparaat (het apparaat dat de stroom heeft gestart) toegang heeft tot alle toepassingen die door uw organisatie worden gebruikt nadat de stroom is voltooid.

De prompt die wordt weergegeven, ziet er ongeveer als volgt uit:

Juni 2023

Weglating van e-mailclaims met een niet-geverifieerde domeineigenaar

Ingangsdatum: juni 2023

Betrokken eindpunten: v2.0 en v1.0

Wijzigen

Voor toepassingen met meerdere tenants worden e-mailberichten die niet door een domeineigenaar zijn geverifieerd, standaard weggelaten wanneer de optionele email claim wordt aangevraagd in een tokenpayload.

Een e-mailbericht wordt beschouwd als domeineigenaar geverifieerd als:

1. Het domein behoort tot de tenant waar het gebruikersaccount zich bevindt en de tenantbeheerder heeft verificatie van het domein uitgevoerd.
2. De e-mail is afkomstig van een Microsoft-account (MSA).
3. De e-mail is afkomstig van een Google-account.
4. De e-mail is gebruikt voor verificatie met behulp van de eenmalige wachtwoordcodestroom (OTP).

Er moet ook worden opgemerkt dat Facebook- en SAML-/WS-Fed-accounts geen geverifieerde domeinen hebben.

Mei 2023

De rol Van Power BI-beheerder wordt gewijzigd in Fabric-beheerder.

Ingangsdatum: juni 2023

Eindpunten beïnvloed:

• RoleDefinitions weergeven - Microsoft Graph v1.0
• List directoryRoles - Microsoft Graph v1.0

Wijzigen

De rol Power BI-beheerder wordt hernoemd naar Fabric-beheerder.

Op 23 mei 2023 onthulde Microsoft Fabric, dat een data factory-integratie-ervaring biedt, synapse-powered data engineering, datawarehouse, data science en realtime analyse-ervaringen en business intelligence (BI) met Power BI, die allemaal worden gehost op een SaaS-oplossing met lake-centric. De tenant- en capaciteitsbeheer voor deze ervaringen worden gecentraliseerd in de fabric-beheerportal (voorheen bekend als de Power BI-beheerportal).

Vanaf juni 2023 wordt de rol Power BI-beheerder gewijzigd in Infrastructuurbeheerder, zodat deze overeenkomt met het veranderende bereik en de verantwoordelijkheid van deze rol. Alle toepassingen, waaronder Microsoft Entra ID, Microsoft Graph API's, Microsoft 365 en GDAP, zullen de nieuwe rolnaam in de loop van enkele weken weerspiegelen.

Ter herinnering mogen uw toepassingscode en scripts geen beslissingen nemen op basis van de rolnaam of weergavenaam.

December 2021

AD FS-gebruikers zien meer aanmeldingsprompts om ervoor te zorgen dat de juiste gebruiker is aangemeld.

Ingangsdatum: december 2021

Betrokken eindpunten: geïntegreerde Windows-verificatie

Betrokken protocol: geïntegreerde Windows-verificatie

Wijzigen

Wanneer een gebruiker nu naar AD FS wordt verzonden om zich te verifiëren, wordt deze op de achtergrond aangemeld bij een account dat al een sessie met AD FS heeft. De aanmelding op de achtergrond vindt plaats, zelfs als de gebruiker zich bij een ander gebruikersaccount wilde aanmelden. Als u de frequentie van deze onjuiste aanmelding wilt verminderen, stuurt Microsoft Entra ID vanaf december de prompt=login parameter naar AD FS als de webaccountmanager in Windows Microsoft Entra ID een login_hint tijdens het aanmelden biedt, wat aangeeft dat een specifieke gebruiker is gewenst voor aanmelding.

Wanneer aan de bovenstaande vereisten wordt voldaan (WAM wordt gebruikt om de gebruiker naar Microsoft Entra-id te verzenden om zich aan te melden, is een login_hint opgenomen, en het AD FS-exemplaar voor het domein van de gebruiker ondersteunt prompt=login) de gebruiker wordt niet op de achtergrond aangemeld en in plaats daarvan wordt gevraagd om een gebruikersnaam op te geven om door te gaan met aanmelden bij AD FS. Als gebruikers zich willen aanmelden bij hun bestaande AD FS-sessie, kunnen ze de optie 'Doorgaan als huidige gebruiker selecteren' die onder de aanmeldingsprompt wordt weergegeven. Anders kunnen ze doorgaan met de gebruikersnaam waarmee ze zich willen aanmelden.

Deze wijziging wordt in december 2021 in de loop van enkele weken uitgerold. Het aanmeldingsgedrag wordt niet gewijzigd voor:

• Toepassingen die IWA rechtstreeks gebruiken
• Toepassingen die OAuth gebruiken
• Domeinen die niet zijn gefedereerd naar een AD FS-exemplaar

Oktober 2021

Fout 50105 is opgelost: interaction_required wordt niet geretourneerd tijdens interactieve verificatie

Ingangsdatum: oktober 2021

Betrokken eindpunten: v2.0 en v1.0

Betrokken protocol: alle gebruikersstromen voor apps waarvoor gebruikerstoewijzing is vereist

Wijzigen

Fout 50105 (de huidige aanduiding) wordt gegenereerd wanneer een niet-toegewezen gebruiker zich probeert aan te melden bij een app waarvoor een beheerder heeft gemarkeerd dat gebruikerstoewijzing vereist is. Dit is een algemeen patroon voor toegangsbeheer en gebruikers moeten vaak een beheerder vinden om toewijzing aan te vragen om de blokkering van de toegang op te heffen. De fout bevatte een bug die oneindige lussen zou veroorzaken in goed gecodeerde toepassingen die de foutreactie interaction_required correct afhandelden. interaction_required vertelt een app om interactieve verificatie uit te voeren, maar zelfs nadat dit is gedaan, retourneert Microsoft Entra ID nog steeds een interaction_required foutreactie.

Het foutscenario is bijgewerkt, zodat tijdens niet-interactieve verificatie (waarbij prompt=none wordt gebruikt om UX te verbergen), de app de instructie krijgt om interactieve verificatie uit te voeren met behulp van de foutreactie interaction_required. In de volgende interactieve verificatie bevat Microsoft Entra ID nu de gebruiker en wordt er rechtstreeks een foutbericht weergegeven, waardoor er geen lus optreedt.

Ter herinnering: uw toepassingscode mag geen beslissingen nemen op basis van foutcodetekenreeksen zoals AADSTS50105. Volg in plaats daarvan onze richtlijnen voor foutafhandeling en gebruik de gestandaardiseerde verificatieantwoorden, zoals interaction_required en login_required die te vinden zijn in het standaard error-veld in het antwoord. De andere antwoordvelden zijn alleen bedoeld voor gebruik door mensen die hun problemen oplossen.

U kunt de huidige tekst van de fout 50105 en meer bekijken in de service voor het opzoeken van fouten: https://login.microsoftonline.com/error?code=50105.

AppId-URI in toepassingen met één tenant vereist gebruik van het standaardschema of geverifieerde domeinen

Ingangsdatum: oktober 2021

Betrokken eindpunten: v2.0 en v1.0

Betrokken protocol: alle stromen

Wijzigen

Voor toepassingen met één tenant valideert het toevoegen of bijwerken van de AppId-URI dat het domein in de HTTPS-schema-URI wordt vermeld in de lijst met geverifieerde domeinen in de tenant van de klant of dat de waarde gebruikmaakt van het standaardschema (api://{appId}) dat wordt geleverd door Microsoft Entra ID. Dit kan verhinderen dat via toepassingen een AppId-URI wordt toegevoegd als het domein niet wordt vermeld op de lijst met geverifieerde domeinen of als voor de waarde niet het standaardschema wordt gebruikt. Raadpleeg de documentatie over aangepaste domeinen voor meer informatie over geverifieerde domeinen.

De wijziging heeft geen invloed op bestaande apps die niet-geverifieerde domeinen in hun AppID-URI gebruiken. Er worden alleen nieuwe toepassingen gevalideerd wanneer een bestaande toepassing een id-URI bijwerkt of een nieuwe toepassing aan de identifierUri-verzameling toevoegt. De nieuwe beperkingen gelden alleen voor URI's die na 15 oktober 2021 zijn toegevoegd aan de identifierUris-verzameling van een app. AppId-URI's die al in de identifierUris-verzameling van een toepassing aanwezig waren op het moment dat de beperking in werking is getreden op 15 oktober 2021 blijven werken, ook als u nieuwe URI's aan die verzameling toevoegt.

Als een aanvraag niet aan de validatiecontrole voldoet, retourneert de toepassings-API voor maken/bijwerken de foutmelding 400 badrequest naar de client die HostNameNotOnVerifiedDomain aangeeft.

De volgende URI-indelingen voor toepassings-id's op basis van API- en HTTP-schema’s worden ondersteund. Vervang de waarden van de tijdelijke aanduidingen zoals beschreven in de lijst onder de tabel.

Ondersteunde toepassings-id URI-indelingen	Voorbeelden van URI’s van toepassings-id’s
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://<verifiedCustomDomain>/<string>	https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain>	https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId>: de eigenschap van de toepassings-id (appId) van het toepassingsobject.
• <string>: de tekenreekswaarde voor de host of het API-padsegment.
• <tenantId>: een GUID die door Azure wordt gegenereerd om de tenant in Azure weer te geven.
• <tenantInitialDomain> - <tenantInitialDomain.onmicrosoft.com>, waarbij <tenantInitialDomain> de initiële domeinnaam is die de maker van de tenant heeft opgegeven bij het maken van de tenant.
• <verifiedCustomDomain> : een geverifieerd aangepast domein dat is geconfigureerd voor uw Microsoft Entra-tenant.

Notitie

Als u het api://-schema gebruikt, voegt u direct na api:// een tekenreekswaarde toe. Bijvoorbeeld: api://<tekenreeks>. Deze tekenreekswaarde kan een GUID of een willekeurige tekenreeks zijn. Als u een GUID-waarde toevoegt, moet deze overeenkomen met de app-id of de tenant-id. De URI-waarde van de toepassings-id moet uniek zijn voor uw tenant. Als u api://< tenantId> als de URI van de toepassings-id toevoegt, kan niemand anders die URI in een andere app gebruiken. Het is aan te bevelen om in plaats daarvan api://< appId> of het HTTP-schema te gebruiken.

Belangrijk

De URI-waarde van de toepassings-id mag niet eindigen met een slash "/"-teken.

Notitie

Hoewel het veilig is om de identifierUris te verwijderen voor app-registraties binnen de huidige tenant, kan het verwijderen van de identifierUris ertoe leiden dat clients mislukken voor andere app-registraties.

Augustus 2021

Voorwaardelijke toegang wordt alleen geactiveerd voor expliciet aangevraagde bereiken

Ingangsdatum: augustus 2021, met een geleidelijke implementatie vanaf april.

Betrokken eindpunten: v2.0

Betrokken protocol: alle stromen die dynamische toestemming gebruiken

Toepassingen die nu dynamische toestemming gebruiken, krijgen alle machtigingen waarvoor ze toestemming hebben, zelfs als ze niet op naam in de scope parameter zijn aangevraagd. Een app die alleen user.read aanvraagt, maar met toestemming voor files.read, kan bijvoorbeeld worden gedwongen de vereiste voor voorwaardelijke toegang door te geven die is toegewezen voor files.read.

Om het aantal onnodige prompts voor voorwaardelijke toegang te verminderen, wijzigt Microsoft Entra ID de manier waarop bereiken worden verstrekt aan toepassingen, zodat alleen expliciet aangevraagde bereiken voorwaardelijke toegang activeren. Toepassingen die afhankelijk zijn van het vorige gedrag van Microsoft Entra ID, waarbij alle bereiken in het token worden opgenomen, ongeacht of dit is aangevraagd, kunnen worden verbroken vanwege ontbrekende bereiken.

Apps ontvangen nu toegangstokens met een combinatie van machtigingen: aangevraagde tokens en tokens waarvoor ze toestemming hebben waarvoor geen prompts voor voorwaardelijke toegang zijn vereist. Het toegangsbereik voor het token wordt weergegeven in de parameter scope van het tokenantwoord.

Deze wijziging wordt doorgevoerd voor alle apps, met uitzondering van apps met een waargenomen afhankelijkheid van dit gedrag. Ontwikkelaars ontvangen hulp als ze zijn uitgesloten van deze wijziging, omdat ze mogelijk afhankelijk zijn van de aanvullende prompts voor voorwaardelijke toegang.

Voorbeelden

Een app heeft toestemming voor user.read, files.readwriteen tasks.read. Op files.readwrite is beleid voor voorwaardelijke toegang toegepast, maar op de andere twee niet. Als een app een tokenaanvraag indient voor scope=user.readen de momenteel aangemelde gebruiker geen beleid voor voorwaardelijke toegang heeft doorgegeven, is het resulterende token voor de machtigingen user.read en tasks.read. tasks.read is opgenomen omdat de app hiervoor toestemming heeft en er geen beleid voor voorwaardelijke toegang hoeft te worden afgedwongen.

Als de app vervolgens scope=files.readwrite aanvraagt, wordt de voorwaardelijke toegang die door de tenant wordt vereist, geactiveerd, waardoor de app een interactieve verificatieprompt weergeeft waar aan het beleid voor voorwaardelijke toegang kan worden voldaan. Het geretourneerde token bevat alle drie de bereiken.

Als de app vervolgens een laatste aanvraag indient voor een van de drie bereiken (bijvoorbeeld scope=tasks.read), ziet Microsoft Entra ID dat de gebruiker het beleid voor voorwaardelijke toegang dat nodig is files.readwriteal heeft voltooid en opnieuw een token met alle drie de machtigingen erin heeft uitgeven.

Juni 2021

De UX van de apparaatcodestroom bevat nu een app-bevestigingsprompt

Ingangsdatum: juni 2021.

Betrokken eindpunten: v2.0 en v1.0

Betrokken protocol: de apparaatcodestroom

Om phishingaanvallen te voorkomen, bevat de apparaatcodestroom nu een prompt waarmee wordt gevalideerd of de gebruiker zich aanmeldt bij de verwachte app.

De prompt die wordt weergegeven, ziet er als volgt uit:

Mei 2020

Opgeloste fout: De statusparameter wordt door Microsoft Entra ID niet meer tweemaal gecodeerd met url-codering

Ingangsdatum: mei 2021

Betrokken eindpunten: v1.0 en v2.0

Betrokken protocol: alle stromen die het eindpunt /authorize bezoeken (impliciete stroom en autorisatiecodestroom)

Er is een fout gevonden en opgelost in het Microsoft Entra-autorisatieantwoord. Tijdens het /authorize-gedeelte van de verificatie wordt de parameter state uit de aanvraag opgenomen in de reactie, om de app-status te behouden en CSRF-aanvallen te voorkomen. Microsoft Entra ID heeft de state parameter onjuist gecodeerd voordat deze in het antwoord wordt ingevoegd, waar deze opnieuw is gecodeerd. Dit zou ertoe leiden dat toepassingen het antwoord van Microsoft Entra-id onjuist weigeren.

Met Microsoft Entra ID wordt deze parameter niet langer dubbel gecodeerd, zodat apps het resultaat correct kunnen parseren. Deze wijziging wordt doorgevoerd voor alle toepassingen.

Azure Government-eindpunten worden gewijzigd

Ingangsdatum: 5 mei 2020 (eindigt in juni 2020)

Betrokken eindpunten: alle

Betrokken protocol: alle stromen

Op 1 juni 2018 is de officiële Microsoft Entra Authority voor Azure Government gewijzigd van https://login-us.microsoftonline.com in https://login.microsoftonline.us. Deze wijziging is ook toegepast op Microsoft 365 GCC High en DoD, die ook services van Azure Government Microsoft Entra ID biedt. Als u eigenaar bent van een toepassing in een tenant van de Amerikaanse overheid, moet u uw toepassing bijwerken om gebruikers aan te melden op het eindpunt .us.

Op 5 mei 2020 begint Microsoft Entra-id de wijziging van het eindpunt af te dwingen, waardoor overheidsgebruikers zich niet kunnen aanmelden bij apps die worden gehost in tenants van de Amerikaanse overheid met behulp van het openbare eindpunt (microsoftonline.com). Betrokken apps krijgen de fout AADSTS900439 - USGClientNotSupportedOnPublicEndpoint te zien. Deze fout geeft aan dat de app probeert om een gebruiker van de Amerikaanse overheid aan te melden bij het eindpunt van de openbare cloud. Als uw app zich in een tenant van een openbare cloud bevindt en bedoeld is om gebruikers van de Amerikaanse overheid te ondersteunen, moet u uw app bijwerken om deze expliciet te ondersteunen. Hiervoor moet mogelijk een nieuwe app-registratie worden gemaakt in de cloud van de Amerikaanse overheid.

Het afdwingen van deze wijziging wordt uitgevoerd via een geleidelijke implementatie op basis van hoe vaak gebruikers van de cloud van de Amerikaanse overheid zich aanmelden bij de toepassing. Apps die af en toe gebruikers van de Amerikaanse overheid aanmelden, krijgen het eerst te maken met deze wijziging en op apps die vaak door gebruikers van de Amerikaanse overheid worden gebruikt, wordt de wijziging het laatst afgedwongen. We verwachten dat deze wijziging voor alle apps in juni 2020 is afgerond.

Zie de Azure Government-blogpost over deze migratie voor meer informatie.

Maart 2020

Gebruikerswachtwoorden worden beperkt tot 256 tekens.

Ingangsdatum: 13 mei 2020

Betrokken eindpunten: alle

Betrokken protocol: alle gebruikersstromen.

Gebruikers met wachtwoorden die langer zijn dan 256 tekens die zich rechtstreeks aanmelden bij Microsoft Entra ID (geen federatieve IDP, zoals AD FS), worden gevraagd hun wachtwoorden te wijzigen voordat ze zich kunnen aanmelden. Beheerders ontvangen mogelijk aanvragen om het wachtwoord van de gebruiker opnieuw in te stellen.

De fout in de aanmeldingslogboeken is vergelijkbaar met AADSTS 50052: InvalidPasswordExceedsMaxLength.

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

Oplossing:

De gebruiker kan zich niet aanmelden omdat het wachtwoord de toegestane maximale lengte overschrijdt. De gebruiker moet contact opnemen met de beheerder om het wachtwoord opnieuw in te stellen. Als SSPR is ingeschakeld voor de tenant, kunnen gebruikers hun wachtwoord opnieuw instellen door de koppeling 'Bent u uw wachtwoord vergeten?' te volgen.

Februari 2020

Lege fragmenten worden toegevoegd aan elke HTTP-omleiding vanaf het eindpunt voor aanmelding.

Ingangsdatum: 8 februari 2020

Betrokken eindpunten: v1.0 en v2.0

Betrokken protocol: OAuth- en OIDC-stromen die response_type=query gebruiken. Dit omvat in sommige gevallen de autorisatiecodestroom en de impliciete stroom.

Wanneer een verificatieantwoord via HTTP-omleiding wordt verzonden van login.microsoftonline.com naar een toepassing, voegt de service een leeg fragment toe aan de antwoord-URL. Dit voorkomt een bepaalde soort omleidingsaanvallen omdat de browser alle bestaande fragmenten in de verificatieaanvraag wist. Apps mogen niet afhankelijk zijn van dit gedrag.

Augustus 2019

Semantiek van POST-formulieren wordt strikter afgedwongen: spaties en aanhalingstekens worden genegeerd

Ingangsdatum: 2 september 2019

Betrokken eindpunten: v1.0 en v2.0

Betrokken protocol: overal waar POST wordt gebruikt (clientreferenties, inwisseling van autorisatiecodes, ROPC, OBO en inwisseling van vernieuwingstokens)

Met ingang van 2 september 2019 worden verificatieaanvragen waarvoor de POST-methode wordt gebruikt strenger gevalideerd aan de hand van de HTTP-standaarden. Met name spaties en dubbele aanhalingstekens (") worden niet langer uit de waarden in het aanvraagformulier verwijderd. Deze wijzigingen worden naar verwachting niet onderbroken door bestaande clients en zorgen ervoor dat aanvragen die naar Microsoft Entra-id worden verzonden, elke keer betrouwbaar worden verwerkt. In de toekomst (zie hierboven) zijn we ook van plan om dubbele parameters af te wijzen en de BOM binnen aanvragen te negeren.

Voorbeeld:

Nu wordt ?e= "f"&g=h op dezelfde manier geparseerd als ?e=f&g=h - dus e == f. Met deze wijziging zou dit nu worden geparseerd als e == "f" - dit is waarschijnlijk geen geldig argument, en de aanvraag mislukt nu.

Juli 2019

Alleen-app-tokens voor toepassingen met één tenant worden alleen uitgegeven als de client-app in de resourcetenant bestaat

Ingangsdatum: 26 juli 2019

Beïnvloede eindpunten: zowel v1.0 als v2.0

Protocol beïnvloed: clientreferenties (alleen-app-tokens)

Op 26 juli 2019 is een beveiligingswijziging van kracht gegaan, waarmee de manier is gewijzigd waarop alleen-app-tokens (via de toekenning van clientreferenties) worden uitgegeven. Voorheen konden toepassingen tokens ophalen om een andere app aan te roepen, ongeacht aanwezigheid in de tenant of rollen waarvoor die toepassing toestemming heeft gekregen. Dit gedrag is bijgewerkt, zodat voor resources (ook wel web-API's genoemd) die voor één tenant (de standaardinstelling) zijn ingesteld, de clienttoepassing binnen de resourcetenant moet bestaan. Bestaande toestemming tussen de client en de API is nog steeds niet vereist en apps moeten nog steeds hun eigen autorisatiecontroles uitvoeren om ervoor te zorgen dat een roles-claim aanwezig is en de verwachte waarde voor de API bevat.

Het foutbericht voor dit scenario geeft momenteel het volgende aan:

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.

U kunt dit probleem oplossen door de beheerderstoestemming te gebruiken om de service-principal van de clienttoepassing in uw tenant te maken, of deze handmatig te maken. Dit vereiste zorgt ervoor dat de tenant de toepassingsmachtiging heeft verleend om binnen de tenant te kunnen werken.

Voorbeeld van aanvraag

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... In dit voorbeeld is de resourcetenant (instantie) contoso.com, is de resource-app een app met één tenant die gateway.contoso.com/api heeft aangeroepen voor de Contoso-tenant en is de client-app 00001111-aaaa-2222-bbbb-3333cccc4444. Als de client-app een service-principal binnen Contoso.com heeft, kan deze aanvraag worden voortgezet. Als dit niet het geval is, mislukt de aanvraag met de bovenstaande fout.

Als de Contoso-gateway-app echter een toepassing met meerdere tenants is, wordt de aanvraag voortgezet, ongeacht de client-app met een service-principal binnen Contoso.com.

Omleidings-URI's kunnen nu queryreeksparameters bevatten

Ingangsdatum: 22 juli 2019

Betrokken eindpunten: v1.0 en v2.0

Betrokken protocol: alle stromen

Per RFC 6749 kunnen Microsoft Entra-toepassingen nu omleidings-URI's (antwoord) registreren en gebruiken met statische queryparameters (zoals https://contoso.com/oauth2?idp=microsoft) voor OAuth 2.0-aanvragen. Dynamische omleidings-URI's zijn nog steeds verboden omdat ze een beveiligingsrisico vertegenwoordigen. Dit kan niet worden gebruikt om statusgegevens in een verificatieaanvraag te bewaren. Gebruik hiervoor de parameter state.

De statische queryparameter is afhankelijk van tekenreeksvergelijking voor omleidings-URI's, net zoals andere delen van de omleidings-URI. Als er geen geregistreerde tekenreeks bestaat die overeenkomt met de met een URI versleutelde redirect-uri, wordt de aanvraag afgewezen. Als de URI wordt gevonden in de app-registratie, wordt de hele tekenreeks gebruikt om de gebruiker om te leiden, inclusief de statische queryparameter.

Op dit moment (eind juli 2019) blokkeert de UX voor app-registratie in Azure Portal nog steeds queryparameters. U kunt het toepassingsmanifest echter handmatig bewerken om queryparameters toe te voegen en dit te testen in uw app.

maart 2019

Lusgedrag van clients wordt onderbroken

Ingangsdatum: 25 mei 2019

Betrokken eindpunten: v1.0 en v2.0

Betrokken protocol: alle stromen

Clienttoepassingen kunnen zich soms misdragen en honderden dezelfde aanmeldingsaanvragen gedurende een korte periode uitgeven. Deze aanvragen kunnen al dan niet succesvol zijn, maar ze dragen allemaal bij aan een slechte gebruikerservaring en verhoogde workloads voor de IDP. Hierdoor neemt de latentie voor alle gebruikers toe en neemt de beschikbaarheid van de IDP af. Deze toepassingen werken buiten de grenzen van normaal gebruik en moeten worden bijgewerkt voor een correcte werking.

Clients die meerdere keren dubbele aanvragen uitgeven, krijgen een invalid_grant-fout toegezonden: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

De meeste clients hoeven hun gedrag niet te wijzigen om deze fout te voorkomen. Deze fout heeft alleen betrekking op onjuist geconfigureerde clients (zonder tokencaching of met promptlussen). Clients worden lokaal (via cookies) per exemplaar bijgehouden op basis van de volgende factoren:

• Hint van de gebruiker, indien aanwezig

• Bereiken of resource die wordt aangevraagd

• Client ID

• Omleidings-URI

• Antwoordtype en -modus

Apps die meerdere aanvragen (meer dan 15) in een korte periode (5 minuten) indienen, krijgen een invalid_grant-fout waarin wordt uitgelegd dat ze zich in een lus bevinden. De tokens die worden aangevraagd, hebben een levensduur die lang genoeg is (minimaal 10 minuten, standaard 60 minuten), zodat herhaalde aanvragen gedurende deze periode onnodig zijn.

Alle apps moeten invalid_grant afhandelen door een interactieve prompt weer te geven in plaats van op de achtergrond een token aan te vragen. Om deze fout te voorkomen, moeten clients ervoor zorgen dat ze de tokens die ze ontvangen correct in de cache opslaan.

2018 oktober

Autorisatiecodes kunnen niet meer opnieuw worden gebruikt

Ingangsdatum: 15 november 2018

Betrokken eindpunten: v1.0 en v2.0

Betrokken protocol: codestroom

Vanaf 15 november 2018 zal Microsoft Entra ID stoppen met het accepteren van eerder gebruikte verificatiecodes voor apps. Deze beveiligingswijziging helpt microsoft Entra-id in overeenstemming te brengen met de OAuth-specificatie en wordt afgedwongen op zowel de v1- als v2-eindpunten.

Als uw app autorisatiecodes opnieuw gebruikt om tokens voor meerdere resources op te halen, raden we u aan de code te gebruiken om een vernieuwingstoken op te halen en dat vernieuwingstoken vervolgens te gebruiken om extra tokens voor andere resources te verkrijgen. Autorisatiecodes kunnen slechts eenmaal worden gebruikt, maar vernieuwingstokens kunnen meerdere keren worden gebruikt voor meerdere resources. Elke nieuwe app die probeert een verificatiecode te hergebruiken tijdens de OAuth-codestroom, krijgt de fout 'invalid_grant'.

Zie De toegangstokens vernieuwen voor meer informatie over het vernieuwen van tokens. Als u ADAL of MSAL gebruikt, wordt dit voor u afgehandeld door de bibliotheek. Vervang het tweede exemplaar van AcquireTokenByAuthorizationCodeAsyncdoorAcquireTokenSilentAsync.

Mei 2018

Id-tokens kunnen niet worden gebruikt voor de OBO-stroom

Datum: 1 mei 2018

Betrokken eindpunten: v1.0 en v2.0

Betrokken protocollen: impliciete stroom en On-Behalf-Of-stroom

Na 1 mei 2018 kunnen id-tokens niet worden gebruikt als de assertie in een OBO-stroom voor nieuwe toepassingen. In plaats daarvan moeten toegangstokens worden gebruikt om API's te beveiligen, zelfs tussen een client- en middelste laag van dezelfde toepassing. Apps die vóór 1 mei 2018 zijn geregistreerd, blijven werken en kunnen id-tokens uitwisselen voor een toegangstoken; dit patroon wordt echter niet beschouwd als een best practice.

Als u deze wijziging wilt omzeilen, kunt u het volgende doen:

1. Maak een web-API voor uw toepassing, met een of meer bereiken. Dit expliciete ingangspunt zorgt voor een nauwkeurigere controle en beveiliging.
2. Controleer in het manifest van uw app, in de Azure Portal of de portal voor app-registratie, of de app toegangstokens mag uitgeven via de impliciete stroom. Dit wordt geregeld via de sleutel oauth2AllowImplicitFlow.
3. Wanneer uw clienttoepassing een id-token aanvraagt via response_type=id_token, vraagt u ook een toegangstoken (response_type=token) aan voor de web-API die hierboven is gemaakt. Wanneer u dus het v2.0-eindpunt gebruikt, moet de scope-parameter er ongeveer als volgt api://GUID/SCOPEuitzien. Op het v1.0-eindpunt moet de resource-parameter de app-URI van de web-API zijn.
4. Geef dit toegangstoken door aan de middelste laag in plaats van het id-token.