Support application/json requests

[pboling]

• [x ] I read and understood how to enable logging

Question / Issue

IdentityServer3 does not support requests for tokens in JSON format, despite that appearing to be the intent. Is there a reason? Can it be enabled?

Looks good in PreventUnsupportedRequestMediaTypesAttribute https://github.com/IdentityServer/IdentityServer3/blob/master/source/Core/Configuration/Hosting/PreventUnsupportedRequestMediaTypesAttribute.cs

But then it falls apart in the TokenEndpointController https://github.com/IdentityServer/IdentityServer3/blob/master/source/Core/Endpoints/Connect/TokenEndpointController.cs#L37 https://github.com/IdentityServer/IdentityServer3/blob/master/source/Core/Endpoints/Connect/TokenEndpointController.cs#L70

[brockallen]

The spec requires form-urlencoded for the token endpoint. I'm not sure what you mean by "it falls apart".

[pboling]

The spec "requires" that it support form-urlencoded. Does the spec explicitly say that also supporting JSON would invalidate spec compliance? Not sure why support for one implies non-support of the other, unless it explicitly says something to that effect.

By "falls apart" I mean that support for JSON looks like it is instrumented up to a point where it stops being an option. I don't think it would take a great deal of effort to get JSON support for the token endpoint.

I am asking because, like perhaps many others, I am building a JSON API for internal use, and I would like my JSON API to be all JSON, so I can use global request handlers in my javascript, C#, and Ruby, that wrap / validate / debug / log / enhance all requests the same way without if isJson? switches everywhere.

[leastprivilege]

Let me read the spec for you ...

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:

[pboling]

And I have USB stick that is Mac and Windows compatible. What is your point? I even have a web browser that can do HTTP and HTTPS. APIs can be spec compliant and speak additional data encodings, can they not?

Let me read my previous comment to you:

Does the spec explicitly say that also supporting JSON would invalidate spec compliance? Not sure why support for one implies non-support of the other, unless it explicitly says something to that effect.

This is a legitimate concern:

I am building a JSON API for internal use, and I would like my JSON API to be all JSON, so I can use global request handlers in my javascript, C#, and Ruby, that wrap / validate / debug / log / enhance all requests the same way without if isJson? switches everywhere.

[brockallen]

Perhaps you're right, but where do you stop and what's the benefit? Clients should also be following the spec, since that's what this is -- a spec compliant OIDC implementation. That's sort of the purpose of following the spec -- since everyone's using the same protocol you can use off the shelf components rather than doing everything from scratch.

If they're not also following the spec, then you're in the world of your own custom security plumbing. This is FOSS, so feel free to fork.

[pboling]

what's the benefit (of having an API that is JSON front to back)?

I would like my JSON API to be all JSON, so I can use global request handlers in my javascript, C#, and Ruby, that wrap / validate / debug / log / enhance all requests the same way without if isJson? switches everywhere.

For now my request handlers will have to handle non-JSON requests when every single other request they make will be JSON.

Forking for this change, if the change would not be accepted upstream, is a commitment to understanding and maintaining this code base which I cannot make. We'll deal with bifurcated request handlers until we replace our IdentityServer3 with a JSON OAuth provider.

[ghost]

@brockallen @leastprivilege Change the spec then. Why should a compliant JSON web token generating service be incompatible with accepting JSON?

The issue I have seen is the web browser's implementation of URLSearchParams/encodeURIComponent is different across different browsers. Some encode spaces to a space and some encode spaces to a plus symbol. When using an email address with a plus in it for testing Identity server "falls apart". Can't process requests because of encoding isn't a problem with the specification, it's a problem with the design and usability.

http://caniuse.com/#feat=urlsearchparams

JSON support across the board would solve encoding problems.