oauth2 openid connect javascript (electron) desktop application

Question

What is the correct oauth2 flow for a desktop application? Besides a desktop application I have a SPA Web GUI which does use the Implicit flow. There it does not matters if the client Redirects after 3600s to the IdP to issue a new Access token.

But the desktop application needs to be running 24/7 or could be running 24/7. So it needs to automatically refresh the access token via a refresh_token. But since the implicit flow does not provide refresh tokens it is probably the wrong flow for a desktop app, isn't it?

I guess I need the auth code flow, which does provide a refresh_token. But authentication requests needs a redirect_uri. Let's say I want to use Google as my openid provider. With google it looks like I can't register client credentials with a custom URI scheme (https://developers.google.com/identity/protocols/OpenIDConnect). What does work is to register for example http://localhost:9300, which theoretically could be handled by the app.

A

Whats the correct oauth2 flow for a desktop app to receive a refresh_token?

B

Can I catch the redirect_uri via a custom URI scheme without using the implicit flow (Google IdP)? It is way easier to listen for a custom uri scheme than listening on a local tcp port.

C

This is more a general question. Usually desktop apps are public apps, so I should not include client_secret right? So the only flow which would be left is the implicit flow. But how can I renew access tokens according to specs without bother the desktop user every 3600s? In my case I could publish the app locally so not public, but how is it for a public app?

Wooton

Answer 1

A - Authorization Code Grant

B - Not sure here, You can register a Custom URI Scheme

C - Not enough information provided. Are you using the AppAuth libraries? If so you SHOULD use PKCE and then additional security measures for the refresh token should not be necessary, on the assumption that the client never sends the refresh token with anyone other than the IDP over a secure connection.

Does this help?

Node

Answer 2

A: Yes use the code grant

B: yes use a custom scheme. In your case you should use the reverse of your client ID. e.g. com.googleusercontent.apps.123 is the reverse DNS notation of the client ID. Register your client as "Other" in the Google developer console.

C: Yes, it should not include the client secret. That is why you don't need to send the secret for native clients ("Other") when exchanging the code for a refresh token. Just leave that field blank and it'll work.

As suggested by jwilleke, please use an AppAuth library if it is available for your use case as it'll also handle some of the security issues (PKCE).

Dinka

Yes it does work reversed, I was confused with the documentation from google since they mentioned it for native apps iOS, Android and Windows and it was not clear to me that this also could be used for desktop apps (For other: just create google oauth credentials for type: "Other" and revserse your client_id as redirect_uri) – Wooton

Answer 3

For native apps (Desktop), you can follow OAuth 2.0 for Native Apps. But this is still under review and you can refer the latest draft from provided link.

With this flow, you can use authorisation code flow to obtain both access token and a refresh token. Refresh tokens should solve the UX related issue when it comes to extended app usage (24/7 and beyond).

According to this working document, there are strict guidelines on client authentication. Section 8.5 discuss about them. As it says client credentials are not recommended

For this reason, and those stated in Section 5.3.1 of [RFC6819], it is NOT RECOMMENDED for authorization servers to require client authentication of public native apps clients using a shared secret

Also as nvnagr has mentioned in his answer, PKCE [RFC7636] is a must to have for native public clients.

Kendo

thanks guys, I integrated the whole thing and its working, but definitely have to migrate to PKCE [RFC7636], maybe via AppAuth – Wooton

@Wooton great :) mark the most appropriate answer as correct and up vote answers helped you. That way others can also tackle the same problem – Kendo

Sure, I'm still checking RFC6819 and AppAuth. – Wooton

Is there a best practice storing a refresh token securely? OS keyring? – Wooton

@Wooton probably encrypted to avoid someone from stealing them. But that will bring up another set of questions, key for encryption and protecting the key of encryption (chicken and egg problem). – Kendo

yeah encryption made in a native app by the app itself is easy hackable. Either don't encrypt it or put it into the os keyring. – Wooton