Closed GrannyOlli closed 5 years ago
Hi @GrannyOlli
This is correct behaviour, see https://tools.ietf.org/html/rfc6749#section-2.3.1 and the related appendix.
The client identifier is encoded using the "application/x-www-form-urlencoded" encoding algorithm per Appendix B, and the encoded value is used as the username; the client password is encoded using the same algorithm and used as the password.
If the AS you're using openid-client with does not process credentials 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 or request a client_id/secret without special characters that need URL form encoding
Note this behaviour is certified with OIDC Certification Suite where this behaviour was also missing until recently
Steps to reproduce the behaviour: Authentication with an openidconnect-idp to receive access-token with code fails because of invalid credentials. Cause: in client.js, client_id and client_secret are formUrlEncoded before base64-encoding. According to RFC2617, client_id and client_secret must not be formUrlEncoded (https://tools.ietf.org/html/rfc2617#section-2)
Code from client.js, starting from line 968
const encoded =
${formUrlEncode(this.client_id)}:${formUrlEncode(this.client_secret)}
; const value = Buffer.from(encoded).toString('base64'); return { headers: { Authorization:Basic ${value}
} };Expected behaviour client_id and client_secret are not formUrlEncoded before base64 encoding
Environment: