Allowing formats othen than JSON

[iliocatallo]

Hi,

It would be nice to support representational formats other than JSON. Specifically, I would like to be able to convey the following:

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}

as HTML. This would allow the oauth2 endpoints to be indistinguishable from the other endpoints in the application (which provide HTML payloads).

Thanks.

[deefactorial]

an access token is consumed by the client application to be used for successive requests by the client to the resource end points. why would you need to display it to the user in html ?

[iliocatallo]

Hi,

My backend exposes a REST API that uses HTML, rather than JSON, as its hypermedia format. For the sake of uniformity, I would like the oauth2 endpoint to do the same. That is, once the third party application has been authorized by the resource owner, I want the oauth2 endpoint to communicate the corresponding access token in HTML. As you suggest, the resource owner does not consequently need to inspect the access token.

In other words, being able to choose the representational format generated from oauth2-server would avoid the need, for a third party client of my application, to deal with HTML when interacting with the backend and JSON when interacting with the oauth2 endpoint.

Thanks.

[deefactorial]

Perhaps I could see XML payloads but HTML is for web pages not raw data, there is nothing to display here, there is only data for the client(3rd party application) to parse.

The token end point returns a token that is parsed by the client and successive requests are made to resource end points with this header set in the request:

Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA

Have a look at the oauth2 spec protocol flow: https://tools.ietf.org/html/rfc6749#section-1.2

[iliocatallo]

Hi,

The reason why we use HTML is that, unlike JSON and XML, it natively supports hypermedia controls (e.g., <link> and <form>). That is, HTML is a hypermedia – rather then a media – format. Thanks to the presence of such hypermedia controls, it is possible to adhere to the HATEOAS constraint of the REST architectural style. You can see an example of such an approach, e.g., here. In the context of REST APIs, HTML confronts favorably to XML, in that it provides a similar syntax with the advantage of a superior semantic power.

Although lately we have seen the proliferation of hypermedia formats (e.g., HAL, Siren, JSON:API, etc.) we decided to stick with HTML for the vast library support and for the fact that HTML suffices for nicely expressing our API.

I agree with you that – once the client is provided with a token - it needs to send it as part of the HTTP request each time it communicates with the resource provider . However, I don't think that the oauth2 spec prescribes a specific media format for communicating such token to the third party application. If this is the case, I think there will be no problem in supporting many different (hyper)media format.

Thanks.

[luckv]

@iliocatallo

The parameters are included in the entity-body of the HTTP response using the "application/json" media type as defined by [RFC4627].

See the specification https://tools.ietf.org/html/rfc6749.html#section-5.1