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).

4

2 回答 2

1

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

于 2019-05-03T18:49:07.323 回答
1

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.

于 2019-05-07T03:57:43.550 回答