Xero currently uses OAuth 1.0a for its authentication and to secure communication on an ongoing basis. OAuth 1.0a was originally designed for use in web applications. Unfortunately, both desktop and mobile solutions require on-device storage of key information that creates a significant security risk that Xero has determined is not acceptable. The key area where mobile and desktop solutions present an issue is allowing direct access to the underlying filesystem for decompilation / reverse engineering of code or access to key security features such as certificate files and consumer key and secret information.
OAuth 2.0 will address the on-device security concerns raised above. Xero SDKs will also be updated to reflect the changes from OAuth 1.0a to 2.0 and Xero will also have a migration path to allow existing OAuth 1.0a apps to move simply to OAuth 2.0.
In some cases, the desktop or mobile device may only integrate a few Xero endpoints (example, pushing an invoice), so creating a webservice which manages these maybe appropriate. Creating a Comms Proxy will comprise the following 2 elements:
The advantage of the comms proxy is that the Webservice manages all the comms and token management without any knowledge of the underlying desktop or mobile solution and importantly, the certificate file is not stored on device. This may simplify the complexity of the desktop or mobile application as the Webservice manages the majority of the delivery to Xero. It simplifies the logic associated with token refreshes as the Webservice can use semaphores, critical sections or singleton classes to guarantee multi-threaded access to a single org is maintained.
An example of the flow to initiate and setup:
Once communication and setup have been done, the desktop/mobile application can look at the workflows that will interact with the Xero API and design their Webservice to make calls on behalf of the mobile/desktop application based on their workflow needs; some examples might be: