Skip to content

PushedAuthorizationBehavior default in OidcHandler PAR #62166

Closed as not planned
Closed as not planned
@narbit

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    ✔️ Resolution: By DesignResolved because the behavior in this issue is the intended design.Status: Resolvedarea-authIncludes: Authn, Authz, OAuth, OIDC, Bearer

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions