The Hyves API uses oAuth to authenticate a application, sign a request, block replay attacks and allow Applications to do calls as a particular user. The Hyves API should be completely compatible with the oAuth 1.0 specification. If you believe that a part of the specification was not correctly implemented, please report it to us as a bug.
We believe that oAuth will become the de facto standard for authentication and authorization in API calls. The way that oAuth calculates its signatures, depends heavily on the method used for url encoding, and it is essential that this happens exactly the same way on the Hyves side and the Application side. Please make sure that your url encoding method adheres to the oauth specification and RFC3986. You should also check the section on content encoding and check the examples.
For obtaining request- and accesstokens, oAuth defines the format of the reply. Since the Hyves API has its own controls for the format of the reply, this format is used by default. You can enforce adherence to the oAuth specification by adding stric_oauth_spec_response=true to your request. For more information, see the auth.requesttoken and auth.accesstoken methods. The format is only being used if the request succeeds, if not the format of ha_format is used to send the errormessage (however the response code is correct per the oAuth specification.
Note that Hyves does never send the WWW-Authenticate header as a response to incorrect requests, sending this header is optional per section 5.4.2. Note furthermore that Hyves does not require that timestamps are sent in ascending order; the oAuth specification on timestamps does only force the application not to decrease the timestamp, but does not specify how the Service Provider should react in case of an illegal order, so we believe we stay within the specification. You can find more information on our timestamp requirements at oAuth (oauth_*) parameters.
Note that accesstokens are authorizing communication between the Application and Service Provider. Therefor we recommend not exposing accesstokens to any third parties, not even the user the token is for. The Application is advised to implement another identification method to match user to their accesstoken.
See User Authorization.