How to limit or control the outbound IP addresses used by Entra ID for authentication?

Hi Thanks for the question

I am a bit confused though. In your question you refer to the "Oauth2-JWKSURL" - what in oauth terms would be wrapped up in the .wellknown endpoint which provides access to the public key information - as well as other oauth meta data. But, this is a service side API endpoint (client calls) - its protected by Azure - not your global DDoS system.

So with that in mind, I presume the issue here is the redirect back from the login (Entra IDP) - user goes to application, the application redirects to Entra for login / SSO and of course then the IDP needs to redirect the user back to the application? The redirect target being your app/site behind your DDoS protection?

There is indeed potentially a lot of IP addresses - this former Q&A question addresses the services tags which cover the login endpoint https://video2.skills-academy.com/en-us/answers/questions/1315490/which-virtual-network-service-tag-covers-login-mic
As per the data here https://www.microsoft.com/en-us/download/details.aspx?id=56519

The issue being that whilst service tags are a neat answer within Az they dont work outside and of course this data sometimes changes - making IP based rules a moving target

Entra as an IDP is a global SaaS type offering - it cant know of your network (virtual or otherwise) and there's no provision today to make it aware of (and use) a private endpoint

Therefore the only option I could think of is that if indeed this is about redirect - that you redirect via a proxy that [conceptually] sits in front of your geo-based-ddos-protection service - Azure front door wouldnt work here because it is in itself a geo based edge proxy (and you're back to dealing with lots of IPs)
You would need to use your own proxy with a public IP or with outbound through a NAT GW or NVA (firewall) with a small number of public IP for outbound NAT

Doing that would give you a known IP. But, of course the major flaw in that idea is the fact you'd have to "funnel" requests through a resource which itself is not DDoS protected (at least not by the solution you use) which somewhat defeats the point

In my humble opinion, I don't think there will be a good answer to this challenge - unless you switch to a DDoS solution which is not relying on a customer supplied configuration => IP ACL list. (For example, threat detection analysis based on client IP reputation would be dynamic and controlled by the vendor.)