Authorization Flow w/PKCE asks for Client Secret #6290
Comments
|
+1 for this. It would be ideal if the |
|
+1 also. If you have |
|
+1 as well. Would be less confusing as |
|
+1 as well. |
|
May I address this issue with a small pull-request that omits the |
) Co-authored-by: Ignacio Lozano <nacholozano@gmail.com> Co-authored-by: Vladimir Gorej <vladimir.gorej@gmail.com> Refs #6290
|
Hi there, I've just encountered this issue and I don't know what to think. OAuth2 still recommends using both the client secret and PKCE in conjunction for confidential clients, as using a secret does not prevent the same class of vulnerabilities as PKCE. A lot of top Google search results for OAuth2 and PKCE mention that those two are not replacements for each other: https://oauth.net/2/pkce/ Why have those been treated as mutually exclusive when they are not? |
PKCE and Client Secrets are allowed to coexist and neither is designed as a replacement for the other. [1] It is wrong to assume that a client secret must not or cannot be used in combination with PKCE. Quite the opposite, when possible both PKCE and client secret should be used. [2] So the premises of swagger-api#6290 and swagger-api#8146 are not correct. Admittedly, for users of the PKCE mechanism WITHOUT a client secret it might be a minor nuisance to see the client secret input in the Swagger UI. But they can just leave it empty. On the other hand, for users of the PKCE mechanism WITH a client secret it is more than just a nuisance if the client secret input is not shown. The Swagger UI becomes unusable for them (unless they've set a default value for the client secret, which will be used hiddenly without being shown to the user). Therefore the right course of action for now would be to revert swagger-api#7438 to show the client secret input always regardless of PKCE. In the future a new flag could be introduced to hide the client secret input regardless of the PKCE flag. [1] https://oauth.net/2/pkce/ [2] https://www.oauth.com/oauth2-servers/pkce/
PKCE and Client Secrets are allowed to coexist and neither is designed as a replacement for the other. [1] It is wrong to assume that a client secret must not or cannot be used in combination with PKCE. Quite the opposite, when possible both PKCE and client secret should be used. [2] So the premises of swagger-api#6290 and swagger-api#8146 are not correct. Admittedly, for users of the PKCE mechanism WITHOUT a client secret it might be a minor nuisance to see the client secret input in the Swagger UI. But they can just leave it empty. On the other hand, for users of the PKCE mechanism WITH a client secret it is more than just a nuisance if the client secret input is not shown. The Swagger UI becomes unusable for them (unless they've set a default value for the client secret, which will be used hiddenly without being shown to the user). Therefore the right course of action for now would be to revert swagger-api#7438 to show the client secret input always regardless of PKCE. In the future a new flag could be introduced to hide the client secret input regardless of the PKCE flag. [1] https://oauth.net/2/pkce/ [2] https://www.oauth.com/oauth2-servers/pkce/
* fix: show client secret input for PKCE auth code flow PKCE and Client Secrets are allowed to coexist and neither is designed as a replacement for the other. [1] It is wrong to assume that a client secret must not or cannot be used in combination with PKCE. Quite the opposite, when possible both PKCE and client secret should be used. [2] So the premises of #6290 and #8146 are not correct. Admittedly, for users of the PKCE mechanism WITHOUT a client secret it might be a minor nuisance to see the client secret input in the Swagger UI. But they can just leave it empty. On the other hand, for users of the PKCE mechanism WITH a client secret it is more than just a nuisance if the client secret input is not shown. The Swagger UI becomes unusable for them (unless they've set a default value for the client secret, which will be used hiddenly without being shown to the user). Therefore the right course of action for now would be to revert #7438 to show the client secret input always regardless of PKCE. In the future a new flag could be introduced to hide the client secret input regardless of the PKCE flag. [1] https://oauth.net/2/pkce/ [2] https://www.oauth.com/oauth2-servers/pkce/ * docs: explain why client secret input is shown despite PKCE
|
I am shocked by this, Confidential clients use both PKCE and ClientSecret, PKCE is not a replacement for a client_secret, a white list of redirect URLs is. I still need an input for Client Secret, Swagger is useless to me without it. Have the option to toggle it, sure, and have it change behaviour when it's empty sure. But to reduce the security of an API because 6 people find having the box shown mildly irritating seems ridiculous. |
Q&A (please complete the following information)
Content & configuration
Any API with Authorization Flow and PKCE enabled.
I'm using DotNet Core and Swashbuckle, so it's a little hard to provide anything here.
Describe the bug you're encountering
The Authorize UI still prompts for the Client Secret even though it's not required for the PKCE flow.
To reproduce...
Steps to reproduce the behavior:
a. Passing any value (valid or not) in that field and clicking 'Authorize' will cause an error.
b. Leaving the field blank, will cause the auth flow to work correctly.
Expected behavior
When 'UsePKCE' flag is enabled, Client Secret field is not shown.
Screenshots
The text was updated successfully, but these errors were encountered: