senddr partner API -- OAuth Issues

Overview

Some common OAuth issues and explanations as to how you can fix them.

1. Token rejected
2. Token expired
3. Nonce used
4. Timestamp refused
5. Signature method rejected
6. Signature invalid
7. Permission Denied

Token Rejected (token_rejected)

There are a number of conditions where this can be seen:

Error: The access token has not been authorized:
<response><code>401</code><message>access_token refused</message></response> = The access token has not been authorized, or has been revoked by the user
There are a number of scenarios where this can occur:

1. A user has revoked access
2. User permissions changed
3. A second authentication has taken place

Resolution: There is no technical solution to the above conditions – you should ensure your application can handle a situation where the authentication session has been lost gracefully, and prompt the user to re-authenticate. If this is happening because of one of the above scenarios on a regular basis, you might need to examine more closely the reasons why, and educate users accordingly.

Error: Does not match an expected access token:
oauth_problem=token_rejected&oauth_problem_advice=Token THISISANCCESSTOKEN does not match an expected REQUEST token
This error will occur in a partner API application when an attempt to renew the access token is made, but the Xero API is expecting the access token to be swapped out that is not the same as the one presented, so somehow your application may have lost track of what the most recently expired token is eg:

1. Get new token access token 1
2. Swap for access token 2, but somehow your application does not save access token 2
3. Attempt to renew token with access token 1, but we now expect access token 2, so we throw the above error

Resolution: The key thing is to understand how your application may lose track of a given access token – potentially a race condition exists where an access token renewal is made in parallel, or the current token is not being saved to a persistent storage object.

Error: The organisation for this access token is not active:
oauth_problem=token_rejected&oauth_problem_advice=The organisation for this access token is not active

This occurs typically when a Demo company is being used to test/develop an application. Demo companies reset every 28 days, and in doing so all existing data including access tokens and private applications are disabled. Other possibilities are if the organisation has been suspended or disabled for billing issues or the subscription has been cancelled.

Resolution: Create a new connection with the new demo company, or in the case of issues not related to demo companies, contact the Xero subscriber for more information.

---

 

Token Expired (token_expired)

Error: The access token has expired:
oauth_problem=token_expired&oauth_problem_advice=The access token has expired.

This is a normal response in both Public and Partner API application types where access tokens last only 30 minutes.

Resolution: For Public applications, authentication sessions last 30 minutes. The user will need to re-authenticate the connection, and your application will then use a new access token. For Partner API applications, the session lasts longer, and a new access token can be requested via the API.

[top]

---

 

Nonce Used (nonce_used)

Error: The nonce value “XXX” has already been used:
oauth_problem=nonce_used&oauth_problem_advice=The nonce value “XXX” has already been used

This error occurs when you make an OAuth request using a nonce value that has been already submitted in a previous request.

Resolution: If you are using one of the code samples, the nonce value should be randomly generated and unique to each request. It may be that the your application is resubmitting the same OAuth request a second time (a double hit) somehow. Once you have ensured your nonce value is being randomly generated, you could use a HTTP proxy such as Fiddler or Charles to see what is being sent to the server.

---

 

Timestamp Refused (timestamp_refused)

This error can occur when the OAuth timestamp you present to the Xero API is either 5mins slower or 5mins faster than the actual time. This time is not timezone dependent – the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. It should therefore be correct unless the clock on your server is out of sync with the actual time by 5mins or more.

Error: Too old
oauth_problem=timestamp_refused&oauth_problem_advice=The timestamp is too old, it must be at most 300 seconds before the server’s

Error: Too new
oauth_problem=timestamp_refused&oauth_problem_advice=The timestamp is too far in the future, it must be at most 300 seconds after the server’s current date and time

Resolution: You should ensure that your server clock is up to date. If you are unsure if the timestamp generated by your server is correct, you can check it at UnixTimeStamp.com.

---

 

Signature Method Rejected (signature_method_rejected)

Error: Public applications must use the HMAC-SHA1 signature method:
<response><code>401</code><message>signature refused, senddr parnter api v1.0 must use HMAC-SHA1</message></response>

= Partner applications must use the HMAC-SHA1 signature method
This can be encountered if the consumer key used to identify the API application in use is not a public API application.

Resolution: Ensure that you are using a consumer key of a Public API application.

---

 

Signature Invalid (signature_invalid)

This can be quite generic reason for a number of signature generation errors. The best tip here is using an up to date version of one of our recommended code samples as they take care of signature generation.

Error: Failed to validate signature:
<response><code>401</code><message>Signature refused, invaild signature</message></response>
Some possible causes:

1. The public-private application certificate keypair used to sign requests does not match the public key uploaded to your application 
2. The application consumer key does not match the application certificate keypair
3. Not all expected elements are being used to generate the signature.

Resolution: No easy way to advise on the specific issues here. Again we recommend using a code sample if possible, but if you are still stuck having gone through the possible causes above, ask a question in our developer community. A GET request requires less parts of the request to be signed – check if you can make a GET request before moving on to PUT/POST as this will help isolate the cause.