2

I want to use OpenID Connect for my native windows and Linux desktop applications to authenticate my users.

As stated in "OAuth 2.0 for Native Apps" Section 7.3 I want to open a local TCP port to redirect from the Authentication Server to get the Authorization Code. I think there is no other option to use for native apps which work both for Windows and Linux.

So the flow would be like:

  • Native app starts and shows login button
  • When login button is pressed
  • native apps opens a ephemeral, local port
  • browser opens with login page of authentication provider (sending along the client id and secret, redirect URI and scope openid, response_type=code)
  • After successful authentication of user in browser
  • the authenication provider redirects to the redirect URI, which is the local open port
  • the local port should display something like "close browser now and go back to app" to user
  • Native application gets code from redirect and closes port
  • Native application asks the token endpoint to get the identity token using the code
  • validate the identity token using the signature
  • will be able to get the details of the user out of that identity token

My question now is do I need PKCE? I found this article which states it does not bring any extra safety apart from making sure that when another app on the same device has registered the same Private-Use URI Scheme Redirect.

Is my plan in any other way flawed or needs further improvements? I understand that the client id and secret can be seen as "public" because they ship with the software and could be reverse engineered. But my software will not be available on public web pages (hopefully) and only be given to trusted customers (which will all have different client id and secrets).

Community
  • 1
  • 1
jcrosel
  • 349
  • 2
  • 5
  • 13

2 Answers2

3

OAuth and native applications brings some complexity. This is because native apps runs natively while OAuth rely on browser to complete the flow. First, I welcome you to look at some other questions and answers where technologies related to native applications were discussed.

From protocol perspective, PKCE has made mandatory. This is being discussed under a new RFC (draft-ietf-oauth-security-topics-12) which will become available soon. With PKCE, you avoid loosing authorization code to a malicious application thats runs in end user's machine.

Reason for this is that, from authorization server, it only rely on client id and redirect URL to identify the correct client. So if authorization response get intercepted, then any party can obtain tokens. PKCE avoid this by introducing a secure random secret that's get generated at runtime. This is not stored and only communicated as it is in token request, which is SSL protected. Hence, PKCE reduce threat vector for stealing tokens.

For native applications, registration of custom url scheme is the perfect way to obtain authorisation response. And as specs point out, combine it with PKCE.

Community
  • 1
  • 1
Kavindu Dodanduwa
  • 12,193
  • 3
  • 33
  • 46
  • 1
    Thanks for your answer! In my specific case I would need to implement it into the existing C++ Qt application using [QtNetworkAuth](https://doc.qt.io/qt-5/qtnetworkauth-index.html) which should run both on Windows and Linux. I therefore thought that it might be easier to use the loopback and register the port exclusively before redirecting to the IdP, therefore no other application can perform MitM. I do not see the attack surface when using the loopback variant, can you explain it to me? As I saw PKCE was made mandatory (also for loopback) and also implicit flow is now deprecated for SPAs. – jcrosel May 07 '19 at 14:07
  • PKCE is a counter measurement for MitM. So even another app tries to capture data transmit on loopback, it won't be able to obtain tokens. Token request is protected by a runtime secret generated from your original application. And yes, implicit flow is depreciated as per the highlighted specification. – Kavindu Dodanduwa May 08 '19 at 03:12
  • The difference here for me is that the URI scheme allows other applications to register for it and get the code to obtain tokens, therefore PKCE makes perfect sense for me in that case. But when the application exclusively opens a port on the local machine, no other application can gain the code. To ensure the port is not registered before my application, I would register before redirecting to the IdP and otherwise show error in my application. – jcrosel May 08 '19 at 09:27
  • @jcrosel well, your approach can work. But I have doubt how this will work with redirect URL registration. The authorization servers require your application to be registered prior to using a protocol (ex:- OAuth or OpenID Connect). In this registration, redirect URL is a key element. So if you are dynamically using the PORT, then the mentioned registration can be problematic. Anyway, PKCE is already implemented by major OAuth libraries. So you do not have to worry a lot about the implementation. – Kavindu Dodanduwa May 09 '19 at 03:33
2

I struggled a bit to understand desktop flows also. I'd recommend private uri schemes as the best solution - I have some cross platform write ups starting here that might give you some ideas: https://authguidance.com/2018/01/11/desktop-apps-overview/

Feel free to ping me any follow up questions, Gary

Gary Archer
  • 22,534
  • 2
  • 12
  • 24
  • I didn't know that native apps can use URI schemes for OAuth, since the RFC states that "Traditional apps typically use a loopback redirect" and "UWP apps can use private-use URI scheme redirects". Did you register private URI schemes for Windows and Linux on a native desktop app? Your example SPA cross platform app (https://authguidance.com/2017/09/26/basicspa-oauthworkflow/) uses the loopback port method – jcrosel May 07 '19 at 06:59
  • So to summarise, for a Native Desktop App you can either use a Loopback Port or a Private URI scheme - either is a good choice (both use PKCE, as recommended above). GitHub Desktop is a good example of a native app that uses a private URI scheme (Dominick Baier pointed it out to me a while back and I preferred this option). At my last company we did a couple of OAuth secured Electron Desktop apps and I wrote quite a bit of stuff about it - here is a post with some screenshots on Private URI schemes:(https://authguidance.com/2018/01/26/final-desktop-sample-overview/) – Gary Archer May 08 '19 at 21:47