Closed simonyarde closed 1 year ago
Maybe you can use client_secret_post client auth method with your provider instead then? RFC6749 is very clear on how the client_id and client_secret are to be encoded before being passed into Basic Auth as username and password tokens.
Thanks for the response. Yes, fortunately the auth server does support sending client_id and client_secret in the form body.
Strange that Postman is non-conforming and this hasn't been picked up as an issue yet.
Hopefully this note is helpful for future travellers.
I've had callback failing with a major auth server and it was hard to find the problem.
Seems the auth server is expecting basic auth header client_id and client_secret without encoding application/x-www-form-urlencode.
The tests worked because Postman appears not to apply the application/x-www-form-urlencode encoding, against the OAuth 2.0 spec.
Probably not seen this issue before since I don't recall working with secrets containing special chars.
Is this a situation where standard practice deviates from the OAuth 2.0 spec? I suspect many people will copy Postman in server and client implementations.
Ideally, I would like node-openid-client to allow me to turn off encoding of client_id and client_secret in the header. I have little chance of getting the auth server to change, and I cannot set my own secrets without special chars.