Desktop Logins Summary


Previously we went over Private URI Scheme Coding Key Points and we will finish up with a summary of Desktop Logins.

My preference is to use Private URI Schemes for my company, though others may prefer the Loopback Interface option.

Desktop App Requirements

Let’s reiterate our Desktop OAuth Requirements and their status:

  • Easy deployment / management in Corporate Environments
  • Best Login Usability for End Users
  • Short Lived Access Tokens with Silent Token Renewal
  • Our solution must Pass Security Reviews
  • Avoid writing any Complex Security Code

Issues Solved

Private URI Schemes require only a single Redirect URI to be registered in Okta, and we don’t require any infrastructure on End User PCs.

Post login usability has a few minor issues, but we have done the best we can, and User Login is Easy – usually just a button click or two:

  • Browser features such as Password Autofill work nicely
  • Private URI Schemes look integrated and activate our app after login
  • We will live with the blank browser page after login

We had to write some slightly complex code, but we kept our concerns nicely separated so our code is in good shape and easy to change.

Okta and AppAuth-JS Integration

Overall I really like both of these components, but there are a couple of areas where they do not play well together:

  • When using the loopback interface in Okta you have to register every concrete redirect URL, which makes manageability difficult
  • AppAuth-JS does not return an id token so our Desktop UI cannot read User Info locally or do an Okta logout

Private / Loopback Pros and Cons

The below table lists my thoughts on pros and cons for the 2 types of desktop login, and companies can choose the option they prefer:

Factor Loopback Interface Private URI Schemes
Security Weaknesses None – and runs with low privilege None – and runs with low privilege
IT Permissions Should work under any Corporate IT Policy but you never know No risk of IT departments blocking logins
Instancing You can run multiple instances of our app if required You need to restrict your app to a single instance
Post Login Browser Display Can be customized but difficult to  avoid a confusing user experience Not customizable and user will see a blank page
Post Login Activation Desktop app stays in background Desktop app is notified by OS and brought to the foreground
Code Complexity More difficult than we’d like due to re-entrancy More difficult than we’d like due to re-entrancy
Electron Developer Setup Easy to debug logins More difficult to debug logins

Where Are We?

There were more issues with Desktop Apps than expected, but I’m satisfied that we’ve done a solid job and built Production Ready Solutions.

Next we will move onto Mobile Apps where In App Browsers will simplify some aspects of code, but there will be new challenges.

Next Steps

  • Next we will begin our first Mobile Code Sample
  • For a list of all blog posts see the Index Page

Leave a Reply

Your email address will not be published.