Request body data encoding for credential endpoint as JSON instead of form encoding

[Tobias Looker]

Currently the spec defines the request body as form encoded rather than JSON which is inconsistent with the response body format. I would like to propose that we change the request body encoding to JSON instead as this improves debugging especially for credential requests that contain nest JSON objects as parameter values.

[Thomas Bellebaum]

The current solution is consistent with e.g. the OAuth 2.0 Token Endpoint, for which the request is also form encoded and the response JSON.

I am not disagreeing with you, though I do like the possibility to use cURL without having to format JSON for most parameters

[Tobias Looker]

Yes IMO the improved developer experience of having the credential endpoint request body be JSON based is worth breaking consistency with the existing OAuth2 precedent set by the token endpoint which from my understanding was done for legacy reasons.

[Torsten Lodderstedt]

I’m on the fence regarding this topic. On one hand, the current design is consistent with the token endpoint (as pointed out by Thomas), which would also allow us to roll the credential issuance up into the token request/response (something we had in mind initially but postponded until the design is more stable). On the other hand, almost any API these days uses JSON in and out. Also form encoding is limited, depending on the outcome of #1544 we might want to have the extended power of JSON structures for the request (not as a hybrid like now where the top level is form encoded and starting with the second level, e.g. the proof parameter , we switch to JSON)

[David W Chadwick]

Would it not be possible for the Oauth endpoint to accept either form encoded or JSON encoded and leave the choice up to the client to decided?

[Torsten Lodderstedt]

RFC 6749 is very precise on that: https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.3 states

The client makes a request to the token endpoint by sending the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:

‌

[Andrii Deinega]

A couple of random comments on this one if I may :)

1. cURL made some improvements on how to handle JSON, see https://everything.curl.dev/http/post/json
2. some OAuth 2 server implementations handle well a JSON encoded request to the token endpoint. Of course, it’s a deviation from RFC 6749.

IMO, it would be great to specify/use both requests and responses in the same format these days.

[Torsten Lodderstedt]

IMO, it would be great to specify/use both requests and responses in the same format these days.

I agree. That’s the reason we have this issue for the credential endpoint.

The token endpoint is a different thing. If you want to modify/evolve it, please propose it to the OAuth WG.

[Brian Campbell]

(I don’t know but) If the credential endpoint uses regular OAuth client authentication, it’s kinda needs to continue using form encoding b/c client auth methods use form parameters. If it’s a protected resource more like the userinfo endpoint, then that constraint doesn’t apply.

[Andrii Deinega]

@Brian Campbell , the credential endpoint is nothing more than an OAuth-protected resource.

[Kristina Yasuda]

Credential Endpoint does not use regular OAuth client authentication. I suggest we make the change to application/json for the credential request.

[Kristina Yasuda]

PR #262

[Kristina Yasuda]

PR #262