8.5. 定义其他错误代码(8.5. Defining Additional Error Codes)

8.5. 定义其他错误代码

在协议扩展（例如，访问令牌类型、扩展参数或扩展许可类型等）需要其他错误代码用于授权码许可错误响应（4.1.2.1节）、隐式许可错误响应（4.2.2.1节）、令牌错误响应（5.2节）或资源访问错误响应（7.2节）的情况下，这些错误代码可以被定义。

如果用于与它们配合的扩展是已注册的访问令牌类型，已注册的端点参数或者扩展许可类型，扩展错误代码必须被注册。用于未注册扩展的错误代码可以被注册。

错误代码必须符合的error ABNF，且可能的话应该以一致的名称作前缀。例如，一个表示给扩展参数“example”设置了无效值的错误应该被命名为“example_invalid”。

 error      = 1*error-char
 error-char = %x20-21 / %x23-5B / %x5D-7E

8.5. Defining Additional Error Codes

   In cases where protocol extensions (i.e., access token types,
   extension parameters, or extension grant types) require additional
   error codes to be used with the authorization code grant error
   response (Section 4.1.2.1), the implicit grant error response
   (Section 4.2.2.1), the token error response (Section 5.2), or the
   resource access error response (Section 7.2), such error codes MAY be
   defined.






Hardt                        Standards Track                   [Page 51]

 
RFC 6749                        OAuth 2.0                   October 2012


   Extension error codes MUST be registered (following the procedures in
   Section 11.4) if the extension they are used in conjunction with is a
   registered access token type, a registered endpoint parameter, or an
   extension grant type.  Error codes used with unregistered extensions
   MAY be registered.

   Error codes MUST conform to the error ABNF and SHOULD be prefixed by
   an identifying name when possible.  For example, an error identifying
   an invalid value set to the extension parameter "example" SHOULD be
   named "example_invalid".

     error      = 1*error-char
     error-char = %x20-21 / %x23-5B / %x5D-7E