Following from the first part, Security, this article will focus on implementing the OAuth workflow on a desktop app. This is required for 3-legged environment where the user needs to enter his/her Autodesk credentials and authorize access to his/her data.
Webcontrol
The first piece we need is a stable and secure webcontrol for our app. The .NET library offers the default control based on the system install of Internet Explorer (IE11, most likely). This control has several downsides: Microsoft is no longer developing IE11 and is focusing on their new version, Edge; the cookies cache is shared within the system, therefore a cookie stored on your app will merge with cookies from other apps or from regular IE11 browsing.
There are a few options out there, based on Firefox and Chrome. For this article, I’ll use CEFSharp, which is based on Chromium, the open source version of Chrome. There are some interesting benefits: it is almost up-to-date with Chrome version; handle cookies for your app only and allow deleting; and supports win32, x64 or AnyCPU (with some extra work).
If your desktop application is based on Revit or Civil 3D, CEFSharp x64 is the best option. If for AutoCAD, you may need a 32 bit compatible, although most professional designers use 64 bit. Of course, some cons: it’s a big library and required additional references.
You can install it via NuGet for WinForm or WPF.
OAuth workflow
To authenticate a user with OAuth, your app will show the Autodesk sign in page. After entering his/her credential, it will redirect to your callback URL. That’s how the app will handle it.
First, as described in the first part, you MUST have a server in the middle that will hold your Forge Client ID and Secret. On that server, create an oauth.aspx page that will, on load, redirect to authorize page.
Now the trick: after entering his/her credentials, Autodesk will redirect to your callback URL with the CODE on the query string. To handle that, let’s create a WebAPI endpoint (or a callback.aspx page) on our cloud app module that will receive that code and POST gettoken to complete the authorization process. As this redirect happens on our app browser, we can watch for load document event so the desktop app knows the cloud app received and handled the authorization. To pass the information from the cloud app module to the desktop app, we can pass it on the page body.
As described in the first part, the cloud app SHOULD NOT pass the access token to the client, but create a database record with that information and send back to the desktop app only an identifier (e.g. a session id).