PushedAuthorizationBehavior default in OidcHandler PAR

[narbit]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The following is most likely corner case back-compatibility scenario with OidcHandler but I still wanted to bring it to your attention.

We started observing Okta challenge breaking with the following error The client secret supplied for a confidential client is invalid returned from Okta after upgrading to Microsoft.AspNetCore.Authentication.OpenIdConnect 9.0.0.0. We use Okta in a federated scenario. The request to Okta /authorize endpoint includes clientId, openId scope with response type set to id_token. The above error was only returned by one of the two Okta tenants we tested with. The exception was thrown in OpenIdConnectHandler.GetPushedAuthorizationRequestUri.

After inspecting the following commit bef4dae#diff-4241f2e2b0ba30cfdc11b53849a5574912f65ab3c7bfc710a93c3176f0b3e49a , we realized that the default for PushedAuthorizationBehavior in OpenIdConnectOptions is set to PushedAuthorizationBehavior.UseIfAvailable. The Okta instance which returned the error had pushed_authorization_request_endpoint listed in its discovery document while the other instance did not. Neither had require_pushed_authorization_requests flag set to enabled.

The UseIfAvailable default forced the request to go via PAR backchannel. Subsequently, the Okta instance that exposed pushed_authorization_request_endpoint started requiring client secret when request came via PAR. It probably treats PAR as a dedicated confidential client channel. Our app didn't originally supply a secret as it was configured as public client. The fix was to set PushedAuthorizationBehavior = PushedAuthorizationBehavior.Disable in our code. In light of this, I was wondering if a better PushedAuthorizationBehavior default should be PushedAuthorizationBehavior.Disable. Alternatively, the intent could be expressed by client setting UsePushedAuthorization bool as was initially proposed by @josephdecock in this discussion - #51686 - but doesn't appear to be implemented.

Expected Behavior

The oidc challenge continues to work after upgrade to Microsoft.AspNetCore.Authentication.OpenIdConnect 9.0.0.0 for all existing scenarios.

Steps To Reproduce

No response

Exceptions (if any)

Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectProtocolException: Message contains error: 'invalid_client', error_description: 'The client secret supplied for a confidential client is invalid.', error_uri: 'error_uri is null'.
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.GetPushedAuthorizationRequestUri(HttpResponseMessage parResponseMessage)
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.PushAuthorizationRequest(OpenIdConnectMessage authorizeRequest, AuthenticationProperties properties)
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.HandleChallengeAsyncInternal(AuthenticationProperties properties)
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.HandleChallengeAsync(AuthenticationProperties properties)

.NET Version

9.0

Anything else?

#51686

bef4dae#diff-4241f2e2b0ba30cfdc11b53849a5574912f65ab3c7bfc710a93c3176f0b3e49a

[MackinnonBuck]

Thanks for reaching out, @narbit.

We knew that this might come up, but we believe that the new default is still the most common case, and we want to use the more secure option by default when possible - we haven't received significant feedback that Disable should be the default setting.

[narbit]

@MackinnonBuck , I agree that the most secure option should be a default whenever possible. But this has a potential to break not only clients with id_token response type but also public clients using authorization code + pkce without a secret. What do you think about letting apps set the intent via UsePushedAuthorization bool and documenting it? It took a little while to find the culprit of this issue only to realize that IdP now controls the behavior expressed via metadata disco doc, not the client configuration itself.