1

I have an app which is OAuth2.0 and RFC 6749 compliant.

I need to extend the behaviour now such that a new RP will invoke my /auth endpoint and it is expecting a response containing my auth_ref, hence I thought instead of the default application/x-www-form-urlencoded format, I should use application/json in the request. This is for 2 reasons:

  1. I dont need to change my existing behaviour of http web redirect with login page response if the request is from a web browser
  2. I can extend the system to cater to the new RP that expects a JSON response containing the auth_ref, among other things

Q1. Is this spec compliant? According to my understanding of the RFC

Q2. an alternative I am considering is to just expose a different endpoint /authz

Q3. Also considering the possibility of adding a new param to the request on the same /auth endpoint. Will this also become non compliant with the spec? or will it be treated as an extension to the spec? Any implications if I extend it?

Thanks in advance.

Community
  • 1
  • 1
cyberjar09
  • 770
  • 1
  • 7
  • 18

1 Answers1

2

If your /auth is an authorization endpoint which is defined in RFC 6749, it is a spec violation to use application/json as Content-Type of requests.

On the other hand, it is allowed to include additional parameters in responses. The following is an excerpt from RFC 6749. You can see example_parameter in the response JSON.

 HTTP/1.1 200 OK
 Content-Type: application/json;charset=UTF-8
 Cache-Control: no-store
 Pragma: no-cache

 {
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
   "example_parameter":"example_value"
 }

Like the above, you can include auth_req in responses. It is compliant with RFC 6749.

An authorization endpoint accepts application/x-www-form-urlencoded and responds with 302 Found and Location header. A token endpoint accepts application/x-www-form-urlencoded and responds with 200 OK and application/json. See "Diagrams And Movies Of All The OAuth 2.0 Flows" for details.

Takahiko Kawasaki
  • 18,118
  • 9
  • 62
  • 105
  • thanks for responding. Unfortunately, for the purposes im considering, I need to maintain backward compatability with my existing `/auth` endpoint which is a web based login, while also allowing for another "mode" of login (another site wants to use my backend for login so I will share json in that response only). Hence I may go down the route of a new endpoint which still talks with `Content Type: application/x-www-form-urlencoded`. That way the new endpoint will also be spec compliant but it is a different feature of the system. Thanks for the answer, the diagrams and movies are cool! – cyberjar09 Aug 28 '19 at 03:43