Feature Request: oauth2/token endpoint json payload option

[sandrom]

Would it be possible to consider respecting the Content Type like application/json in the POST oauth2/token request? currently it seems only to support forms and I am aware that the IETF explicitly only specified them. Problem is, because everyone somehow does json, so do the customers and does the old implementation here, so I am either putting yet another service in front of hydra just to translate json to forms, or hydra can directly understand json. It would be awesome, if that could be considered.

[aeneasr]

Thank you for your suggestions. We want to keep Hydra as close to the spec as possible and not introduce any custom features for those specs. Customers should not be using their own code anyways and use well-tested open source libraries for interacting with oauth2. In conclusion, this request will not make it into hydra, sorry!

[sandrom]

@arekkas While I understand your point, hope vs reality is different beasts at time. For us here its not possible to change from json easily as changing anything the customers are currently doing is a big issue and they do json right now. One battle at a time. Furthermore its not that uncommon to use json for doing exactly that, see https://auth0.com/docs/api-auth/tutorials/client-credentials

While I understand, that its possibly not favorite, for us using hydra means just adding a service in front to translate from json to forms if that feature can not be mapped by hydra and I see already people questioning the use of hydra then. The age old problem of kiss vs reality. :(

[aeneasr]

For us here its not possible to change from json easily as changing anything the customers are currently doing is a big issue and they do json right now.

I am sorry to hear that, your customers however should rely on open source libraries to implement oauth2 flows. If that is, for some reason, not the case then - unfortunately - hydra can not natively handle those payloads or help with migration.

One battle at a time. Furthermore its not that uncommon to use json for doing exactly that, see https://auth0.com/docs/api-auth/tutorials/client-credentials

That's exactly the problem, because people allow this behaviour, other libraries have to implement that as well, although it's not how things should work.

While I understand, that its possibly not favorite, for us using hydra means just adding a service in front to translate from json to forms

This is actually quite common when introducing breaking changes in APIs, check out this blog article on api versioning, which explains that they use modifiers for older clients which transform things so breaking changes are "hidden"

[aeneasr]

ps: If you find a IETF/OpenID spec which either allows extension of body payloads for those endpoints, or specifically mentions json I'd be open to add it.

[sandrom]

funny, that API article was already posted by our team as one of the many desperate attempts to introduce some kind of any version management around, which currently is non-existent. tell me about it :)

anyway, no problem, we can solve it and I know where you're coming from standing for that (usually it's one of us waving IETF specs around that should be considered instead of another ruby-halfbaked-iknoweverythingbetter-solution). Just had to make sure as there are still many other battles to fight and our time is simply rather limited. I'd also rather get rid of simple client_credentials flows generally, but that's another story altogether.

nevermind and thank you a lot for taking the time!

[aeneasr]

You're welcome, and good luck with fighting the battles ;)

You probably don't need to implement that on your own, I think API Gateways such as Kong support request transforms out of the box - maybe there's some json to form plugin available already

[aeneasr]

It is encouraged to run hydra behind an api gateway anyways, at least something capable of handling TLS termination