OAuth 2.0 RFC 6749内容类型应用程序/json是否符合规范？

我有一个应用程序是OAuth2.0和RFC6749兼容

我现在需要扩展这个行为，这样一个新的RP将调用my/auth端点，并且它期望一个包含我的auth_ref的响应，因此我认为应该在请求中使用application/json，而不是默认的application/x-www-form-urlencoded格式。这有两个原因：

如果请求来自web浏览器，我不需要使用登录页面响应更改http web重定向的现有行为 我可以扩展该系统以适应新的RP，该RP需要包含auth_ref等内容的JSON响应 问题1。这符合规范吗？据我了解,

问题2。我正在考虑的另一种选择是只公开不同的端点/authz

第三季度。还考虑在同一/auth端点上向请求添加新参数的可能性。这是否也会变得不符合规范？还是将其视为规范的扩展？如果我扩展它，有什么影响吗

提前感谢。

如果您的/auth是RFC 6749中定义的授权端点，则使用application/json作为请求的内容类型是违反规范的

另一方面，允许在响应中包含其他参数。以下是RFC6749的摘录。您可以在响应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"
 }

与上面一样，您可以在响应中包含auth_req。它符合RFC 6749

---

授权端点接受application/x-www-form-urlencoded，并使用302 find和Location头进行响应。令牌端点接受application/x-www-form-urlencoded，并用200 OK和application/json响应。有关详细信息，请参阅。

感谢您的回复。不幸的是，出于我考虑的目的，我需要与我现有的/auth端点保持向后兼容性，这是一个基于web的登录，同时还允许另一种登录模式。另一个站点希望使用我的后端进行登录，因此我将仅在该响应中共享json。因此，我可能会选择一个新的端点，它仍然使用内容类型：application/x-www-form-urlencoded。这样，新端点也将符合规范，但这是系统的一个不同功能。谢谢你的回答，图表和电影都很酷！