Open krzema12 opened 3 years ago
Looking into the code:
I think the library doesn't specify any headers in the request, but specifies some legal content types in response. So next to customizing request content type, another idea would be to allow text/plain
or anything there. Then the JSON deserialization could be attempted and if it fails, then bubble up the failure to the user. Otherwise, if the request comes with content-type: whatever-that-deserializes-successfully-to-JSON
, simply deserialize and carry on. It would give more flexibility to OAuth2 server implementations, and such little discrepancies are known to cause headaches.
I found a workaround. I set loadUserInfo
to false
and it appears that user data from a response from /token
call is put in useAuth().userData
. I then deserialize the JWT token from access_token
and extract what I need.
This issue is still worth discussing because not in every case such simplification can be done.
Hi Team!
I'm using the library to integrate with my company's internal SSO. Due to some historical reasons, the service responds to userinfo endpoint with
content-type: text/plain
when requested withAccept: */*
. In such case, the library crashes as it expectscontent-type: application/json
:While our SSO could possibly respond with
content-type: application/json
and the problem would disappear, that's a though topic because it requires ensuring that no existing SSO clients will be broken because of such change. In the meantime, I'd like to request a possibility to customize the content type (or any other header field?) when making requests from this library.FWIW: I use this library through a React wrapper https://github.com/bjerkio/oidc-react, but looking at its code, it doesn't deal with raw network calls - it literally wraps oidc-client-js. That's why I think any customization needs to be exposed here first.
Best, Piotr