Auth server and Postman non-conforming? HTTP Basic Auth x-www-form-urlencoded

[simonyarde]

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.

// Postman (base64 decoded)
// app-...:01-0GM-U5b-!V2g$899h?-Mt0y?_sB

// node-openid-client (base64 decoded)
// app-...:01-0GM-U5b-!V2g%24899h%3F-Mt0y%3F_sB

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.

[panva]

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.

[simonyarde]

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.