Closed hequ closed 5 years ago
client_secret should not be URIEncoded as it breaks secrets with special characters
No it definitely should, see https://tools.ietf.org/html/rfc6749#section-2.3.1 and the related appendix, this was fixed (introduced) in https://github.com/panva/node-openid-client/releases/tag/v2.0.1 and will stay as such.
If the provider you're using openid-client with does not process your client_secret correctly then you should request them to fix it. If you can't get them to fix client_secret_basic see if you can use client_secret_post instead.
Note this behaviour is certified with OIDC Certification Suite where this behaviour was also missing until recently
Thanks for clarifying this.
Happy to.
Describe the bug
Client secret with special characters should not be URIEncoded before tranformed to base64 string. This produces a wrong base64 encoded Basic auth string which results the token server to reject the authorization.
To Reproduce Issuer and Client configuration: (inline or gist) - Don't forget to redact your secrets.
Steps to reproduce the behaviour:
client.authorizationUrl({...})
client.authorizationCallback({...})
Expected behaviour Expected to get the autorization token response from the token server.
Environment:
Additional context I pinpointed the behaviour to be in lib/client.js in function
authFor
which callsformUrlEncode
to encode the client_id and client_secret. I think these parameters should not be URIEncoded, but to base64 encoded only.