Open ojathelonius opened 1 week ago
The library never is a public client, it always is a trusted client with a client secret. so there is no reason to support the none
algorithm as it would be way less secure than any of the supported alternatives.
I don't follow why none
is considered as less secure, as long as it is using PKCE. Unauthorized clients cannot generate tokens due to the authorization code flow. Why does the library require authentication for token generation when the OIDC specs do not?
I don't follow why
none
is considered as less secure, as long as it is using PKCE. Unauthorized clients cannot generate tokens due to the authorization code flow. Why does the library require authentication for token generation when the OIDC specs do not?
The PKCE does not serve as a way to authenticate clients. It only means that the client, which made the authorization endpoint request, is the one accessing the token endpoint. There is no client authentication, which is represented by value "none" actually.
What @oldium says. lua-resty-openidc is not really a library, it is a client running inside an environment that is able to keep secrets, so there really is no need to not use a proper way to authenticate the client itself.
Thank you for the explanation!
there really is no need to not use a proper way to authenticate the client itself.
I believe there are some cases where you would want to protect a resource using a public client, which OIDC supports. I understand that you recommend using a client that has secrets, but this is not always possible. This use case seems to be confirmed by the same feature request in oauth2-proxy. Is there then a strong case for not enabling this flow?
At least I don't see why it would "not be possible" to use a secret for a client that is a server based application - which lua-resty-openidc is. Again "at least I" wouldn't want to encourage a configuration that is less secure.
It appears that
none
is the recommended configuration when using the PKCE auth flow for public clients (see OIDC 1.0 specs, Okta docs, Hydra docs). Is there a reason why this is not supported by the library? If not, is there a chance this is a minor change I could contribute to?Environment
Expected behaviour
Using
token_endpoint_auth_method="none"
is supported when usinguse_pkce=true
, enabling authorization code grant flow with PKCE for public clients that do not have aclient_secret
Actual behaviour
The library does not support
token_endpoint_auth_method="none"
thus defaults to using basic auth which obviously fails for public clients due to the lack ofclient_secret
Configuration and NGINX server log files
Sample nginx config