By Augusto Goncalves (@augustomaia)
This is a follow up from this previous post, which demonstrates a basic approach for desktop app with 3-legged OAuth. One of the biggest challenge is to ensure your client ID & secret are protected.
For that, this sample has 3 projects:
- Forge: a class library (.DLL) that wraps some endpoints for OAuth, Data Management API and OSS.
- ServerOAuth: this is the ASP.NET server that stores the client ID & secret and implements the redirects and callback for 3-legged OAuth.
- A360Sync: a WinForm (.EXE) desktop app that monitors a local folder and upload files to the respective A360 account.
Enough talking, let's see this sample in action:
The A360Sync project will call the ServerOAuth project to get the Authorize endpoint URL and redirect the end-user to the sign-in page. As the client ID is passed on the URL, it's not really hidden (e.g. a proxy server will see this URL with the client ID), but the desktop client don't expose it. As soon as the end-user types his/her password, it will callback the ServerOAuth, which calls GetToken endpoint with the client secret (which should not be shared under any circumstance). Now the ServerOAuth has the access token, so it redirects to a fake url that should trigger an error on the A360Sync desktop app webbrowser control and bingo: it can store the access token. As this handles only the user data, it's ok that the desktop app can see the access token (its access is limited to his/her data and there is no reason to hack his own data).
One concern: non-repudiation. As the access token is a permission to our app access the end-user data, if the same end-user uses this access token to modify its data, on the records, the data was performed by the application (as the 3-legged OAuth is a permission between Autodesk, developer/app & the end-user).
The source code is available on Github, but it should not be used on production just yet (still a work in progress), but I would love some feedback and will be improving it over the next few week.