Final Desktop App – Overview

Background

Previously we walked through our Desktop App Coding Key Points. We have a good working solution but we will see if we can improve it further for the final sample.

Code Sample Features

We will implement 2 new features:

  • Logins will use a Private URI Scheme rather than a Loopback Interface
  • After login, tokens will be saved to Operating System Secure Storage

Secure Storage of Tokens

When we demonstrate mobile logins, we will store tokens in secure storage after login, so that the user does not need to login every time they start or reactivate the app.

We will follow this same behavior in a desktop app, though of course this is not part of the OAuth standards. You may prefer to just store tokens in memory after login.

Deployment Aspects

One problem with our first sample is that Okta requires us to register every possible URL for the loopback interface, which is tricky from a management viewpoint since we might want to support 100 or more ports.

Another concern is the possibility of Corporate IT Departments somehow preventing end users from running local loopback web servers.

Getting the Code Sample

The final sample is available here, consisting of a UI and API component. It can be downloaded / cloned to your local PC with this command:

  • git clone https://github.com/garyarcher36/authguidance.desktopsample2

Configuration Changes

Setup steps are almost identical to the First Desktop Code Sample, though the desktop app’s configuration is reduced since there are no ports or login completion pages:

In Okta, our Desktop App’s registration now only has a single Redirect URI for our Private URI Scheme:

Private URI Scheme Rollout

Our Desktop App will register the Private URI Scheme as a Per User Setting that does not require administrator actions. In corporate environments we must be vigilant about operations that require Administrator Privileges:

  • Most end users will NOT have administrator access to their local PC
  • Your Desktop App’s rollout may be managed by IT Administrators
  • Administrative setup should be done by your App’s Install Program
  • The Desktop App itself should usually run with normal / low privileges

Registered Private URI Scheme

On Windows, the Private URI Scheme is registered at the below per user registry location under HKEY_CURRENT_USER:

On Mac OS I installed the Default Apps Tool to view the scheme and the app it was registered to, which is also a per user setting:

Build Prerequisites

Our Desktop App will manage operating system secure storage via a lower level NodeJS component called keytar.

Although Javascript technologies are very productive for normal UI coding, it can be harder to integrate lower level components.

On Windows I needed to install the following components globally:

  • npm install –global node-gyp
  • npm install –global –production windows-build-tools

On my Fedora Linux system I needed to ensure that g++ was installed via the first command below, then to install some security libraries:

  • sudo dnf group install “C Development Tools and Libraries” -y
  • sudo yum install libsecret-devel

Preparing Token Storage

We can start running the final desktop sample by executing the following command:

  • npm run buildnative

This will run electron-rebuild to build keytar, which is partly written in C++ code that needs to link with operating system libraries.

Building the Code Sample

We can then build the final desktop sample by executing the following command:

  • npm run build

The first of these commands will be a little slower than previously, since it builds TypeScript code and then packages the app into the dist folder:

Running the Code Sample

We can run the app via npm start or by running it from the File Explorer, and the Desktop App’s behavior is the same as our previous sample:

Login Browser Prompts

After a login the user is prompted to open our desktop app, and this works in all of the main browsers. When the user consents to open the desktop app it is brought to the foreground.

Google Chrome

Safari

Firefox

Internet Explorer

Edge

Login Re-Entrancy

Again it is possible that a busy user clicks Sign In, accidentally closes the browser tab, then needs to recover, and we will aim to prevent this causing errors where possible:

Post Login Display

After login the display looks poor, since the user is left with a blank page or a grayed out login page, and there is no way to customize this:

Having said that, our Loopback Interface Code Sample also had a post login display that looked pretty unnatural.

Token Storage

After login our tokens are stored and recall that our refresh token was configured to last for 12 hours.

During this period a user can close and re-open the app without needing to re-login, so that the first thing the user will see is your app:

Secure Token Storage

After login, our auth state is stored in Per User Secure Storage and you can only access this state by logging on to the PC as the user.

On Windows the keytar component saves our Desktop App’s tokens to the Windows Credentials Manager:

On Mac OS the keytar component saves our Desktop App’s tokens to the Keychain:

Where Are We?

Companies can adopt either the Loopback Interface or a Private URI Scheme, both of which are fine from a security viewpoint.

Next we will look at some code and then provide a summary of Desktop Logins, including Pros and Cons for the 2 technical options.

Next Steps

Leave a Reply

Your email address will not be published.