-
Notifications
You must be signed in to change notification settings - Fork 370
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.
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
Discussion: Separated EnforcePKCE settings for public and confidential clients ? #389
Comments
Good idea! |
@aeneasr |
We could also add a flag to OAuth2 Client definitions saying whether it's enforced or not? |
But I think your suggestion is easier to manage from an admin perspective and solves a very basic use case. |
Yeah, very true. |
I think your proposal is good. We can always add the flag later :) |
Thank you! |
Is your feature request related to a problem? Please describe.
In this PR, set EnforcePKCE to true also forces PKCE to be enabled for confidential clients.
#382
I am totally agree that allow PKCE to be enabled on confidential clients is a good feature.
However I think in some cases, we want PKCE to be only force enabled on public clients, but not confidential clients.
Because confidential clients require client authentication and public clients doesn't, those two types of clients have different security level in the first place.
Of course, enable PKCE on confidential clients will make them more secure, but also make it more difficult to implement.
It will be good if we can set PKCE policy separately on public and confidential clients.
Describe the solution you'd like
Separate EnforcePKCE option by client types.
For example (to avoid breaking change)
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
My usecase is basically
The text was updated successfully, but these errors were encountered: