This wiki is no longer active and is left here for historical purposes. Please visit oauth.net for up-to-date information.

ProblemReporting


Extension: Problem Reporting

This is an extension to OAuth, defining how a Service Provider can report a problem to a Consumer. This enables the Consumer to provide a more satisfying experience to the User, by solving the problem quietly or giving the User actionable advice for solving the problem.

To discuss this extension, please use the API failure handling thread in the Google Group OAuth Extensions.

A Service Provider MAY report a problem by including the following parameters in any HTTP response. These parameters SHOULD be included in an OAuth WWW-Authenticate header (per OAuth section 5.4.2), and MAY also be included in the response body (per OAuth section 5.3). These parameters MAY be sent in both the header and body of the same response, in which case these parameters SHOULD be identical in these two places.  Note that parameter values are percent encoded, as specified by OAuth.

The parameter named oauth_problem is a brief string identifying a problem. Its permitted values and their meanings are: 

Other values of oauth_problem MUST NOT be used. However, a Consumer SHOULD be prepared to receive other values, from a Service Provider that implements a future version of problem reporting.

The parameter named oauth_acceptable_versions consists of two version numbers separated by '-' (hyphen). It's the range of versions acceptable to the sender. That is, it means the sender will currently accept an oauth_version that's not less than the first number and not greater than the second number. A version A.B is considered greater than C.D if either A > C, or A = C and B > D.

The parameter named oauth_acceptable_timestamps consists of two numbers in decimal notation, separated by '-' (hyphen). It's the range of timestamps acceptable to the sender. That is, it means the sender will currently accept an oauth_timestamp that's not less than the first number and not greater than the second number.

The parameter named oauth_parameters_absent consists of a set of parameter names, percent-encoded and then separated by '&'. Note that this string will be percent-encoded again, because it's the value of oauth_parameters_absent. For example, a response body may contain: oauth_problem=parameter_absent&oauth_parameters_absent=oauth_token%26oauth_nonce

The parameter named oauth_parameters_rejected consists of a set of parameters, encoded as they would be in a URL query string. These are parameters that the sender recently received but didn't expect. Note that these parameters will be percent-encoded twice: once to form a query string and again because the query string is the value of oauth_parameters_rejected.

The parameter named oauth_problem_advice consists of free-form text to be shown to the User. It SHOULD describe the problem in a way that's meaningful to the User, and suggest how to resolve the problem. The Consumer MUST NOT interpret it as HTML or any other markup language; all the characters MUST be displayed to the user. To indicate a line break, the single character LF (Unicode U+000A) MUST be used. 


New Parameter to request Error (status) code in Response Body:

If the Service Provider also supports the custom response data format extension, the return status code and text should be added as an oauth parameter "oauth_error_code" and "oauth_error_text" inside the "response" object along with "oauth_problem" and other related parameters to this extension.

Sample XML:

     <response>
        <oauth_parameter name="oauth_error_code">401</oauth_parameter>
        <oauth_parameter name="oauth_error_text">Unauthorized</oauth_parameter>
        <oauth_parameter name="oauth_problem">token_expired</oauth_parameter>        
     </response>