in description you mentioned that metadata can be requested from https://{host}/common/discovery/instance and provided to app, but as i understand form previous conversation this endpoint is not available in region specific configs.

@SomkaPe This is a good point. I will update the wiki page with instructions for region specific configuration.

If Instance Discovery Response set manually, during construction of application object we might want to check "validate authority" flag, and throw Exception if it is true.

"Authority validation" feature is essentially check that authority is known to AAD (we do it by issuing instance discovery request to hardcoded AAD endpoint).
So, if we use provided by developer instance discovery response, we do no validation at all.

Also we should discuss option of throwing exception if application object is configured with ADFS or B2C authority and "validate authority" flag is set as true.
@henrik-me, @bgavrilMS, @navyasric, @rayluo it would be nice to hear yours opinions as well.

@SomkaPe - ValidateAuthority is a good intention but a bad API. Users don't understand it and they shouldn't be asked to understand. AFAIK MSAL.Android even removed this API and we should strive to do the same, but bear in mind this is a breaking change and since we're all GA now, breaking changes have a much higher bar.

In the end, what we want to protect against is the user calling an hacked IdP. But in 99% of the cases, the authority is hardcoded, I have yet to see applications that call an API, get a 401, extract the authority blindly and start talking to it.

As such, in my opinion, we should not throw if the user doesn't set ValidateAuthority properly, i.e. for B2C ValidateAuthority does not make sense so just ignore the param. For ADFS, ValidateAuthority makes sense, there is a specific API for it.

So the general algorithm is:

• try the user metadata first (if it exists). If the authority is not found in the user json, throw (bad config).
• try the instance metadata static cache second, do not throw
• call the instance discovery endpoint. If it fails with invalid_instance throw. If it fails with anything else (especially timeouts), DO NOT throw (this is to increase availability of AAD). It's true that in this case we might not understand aliases, but this is much more preferable to crashing people's apps.

I agree that we should get rid of ValidateAuthority whenever we next introduce breaking changes.

@SomkaPe Instead of throwing exception, the other would be to clearly document in the AadInstanceDiscovery, ValidateAuthority, and B2cAuthority API JavaDoc that validate authority will only be validated if it's an AAD/ADFS authority and instance discovery metadata is not passed in.

I agree that we should get rid of ValidateAuthority whenever we next introduce breaking changes.

@SomkaPe Instead of throwing exception, the other would be to clearly document in the AadInstanceDiscovery, ValidateAuthority, and B2cAuthority API JavaDoc that validate authority will only be validated if it's an AAD/ADFS authority and instance discovery metadata is not passed in.

Java Doc might be good enough, ... only be validated if it's an AAD/ADFS authority - may be if it is AAD authority