Allow callers to specify resource provider to avoid challenge responses

[heaths]

In relation to #15650 we should allow callers to somehow specify the resource provider to authenticate the principal and issue a bearer token without requiring a challenge response from the service. I can think of a couple of different ways users might opt in, and feedback here is welcome:

1. Add a property to an options class (perhaps in the clients that automatically use the policy from Add support for challenge-based auth to Azure.Core #15650) to specify the resource ID. If present, authenticate using that resource.
2. Since most requests are problem for resources in the public cloud, default the resource provider in a client options class (it will vary) and have a separate property to opt into pre-authenticating the principal. Anyone on another cloud or Azure Stack can set the appropriate resource provider as needed.

This would reduce the number of network calls by at least 1.

[heaths]

It's also worth noting that exposing properties to opt into this behavior would likely have to be on the client options class anyway, since the client is typically adding this policy (if required) automatically anyway, without ever exposing it directly to the callers. And the default resource provider will also vary by client, most likely.

[jsquire]

@heaths: Given that the Azure Identity team has changed guidance to recommend against auth challenges as a means for discovering the token scope, is this still needed?

[heaths]

This recommendation actually mitigates discovery: it's to be explicit with the scope so we don't have to scan the auth challenge or, potentially, even issue a challenge. That's what this is really about: avoiding the need to send an unauthenticated (and empty bodied) request just to get the scope.

/cc @schaabs

[pallavit]

/cc: @christothes to weigh in.

[christothes]

As @heaths notes above, this would be controlled by the client rather than Identity. The resource provider scope is controlled via the TokenRequestContext sent to GetToken

[christothes]

I'd also note that trying to eliminate the first unauthenticated request may not be worth the time, as upcoming Entra Id features such as Proof of Possession tokens may require an initial unauthenticated request as well, in some scenarios.

[heaths]

I've been hearing about that as well. Still, if people aren't using it - unless the service would require it, (@jlichwa?) - many have asked for this over the years.

Still, given how long this has been open, we should probably discuss closing it. The main reason has been to eliminate the 401s from telemetry, but that's not an uncommon OAuth flow and should be ignored. Is the effort - both to implement and to use - worth eliminating occasional 401s that are non-errors like e.g., 429s?

[christothes]

I've been hearing about that as well. Still, if people aren't using it - unless the service would require it, (@jlichwa Jack Lichwa FTE?) - many have asked for this over the years.

AFAIK, the only thing that would enforce this is a policy for the tenant. But I imagine it could become popular to use for enterprises, like MFA.

Still, given how long this has been open, we should probably discuss closing it. The main reason has been to eliminate the 401s from telemetry, but that's not an uncommon OAuth flow and should be ignored. Is the effort - both to implement and to use - worth eliminating occasional 401s that are non-errors like e.g., 429s?

My vote would be to close

[jlichwa]

I agree that considering lack of alignment for this (there many opinions), and even if go that path, it is likely should be driven across resources vs Key Vault. I think we can close it for now, and once there is initiative to tackle this problem with broad customer communication, we can revisit it.

[pallavit]

Given the conversation, I will close this issue for now and we can revisit in future as needed.