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
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 we will begin our first Mobile Code Sample
- For a list of all blog posts see the Index Page