Skip to content

PushedAuthorizationBehavior default in OidcHandler PAR #62166

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
1 task done
narbit opened this issue May 29, 2025 · 2 comments
Closed
1 task done

PushedAuthorizationBehavior default in OidcHandler PAR #62166

narbit opened this issue May 29, 2025 · 2 comments
Labels
area-auth Includes: Authn, Authz, OAuth, OIDC, Bearer ✔️ Resolution: By Design Resolved because the behavior in this issue is the intended design. Status: Resolved

Comments

@narbit
Copy link

narbit commented May 29, 2025 •
edited
Loading

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
@github-actions github-actions bot added the area-auth Includes: Authn, Authz, OAuth, OIDC, Bearer label May 29, 2025
@MackinnonBuck
Copy link
Member

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.

@MackinnonBuck MackinnonBuck closed this as not planned Won't fix, can't repro, duplicate, stale Jun 2, 2025
@MackinnonBuck MackinnonBuck added the ✔️ Resolution: By Design Resolved because the behavior in this issue is the intended design. label Jun 2, 2025
@narbit
Copy link
Author

narbit commented Jun 2, 2025

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area-auth Includes: Authn, Authz, OAuth, OIDC, Bearer ✔️ Resolution: By Design Resolved because the behavior in this issue is the intended design. Status: Resolved
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@narbit @MackinnonBuck