I'm interested if Salesforce plans on supporting the IETF BCP 212 (a.k.a. RFC 8252): https://tools.ietf.org/html/bcp212 It appears that Salesforce should support this best practice in order to increase security for mobile and desktop applications.

The best practice document recommends using a combination of the following techniques for mobile and desktop apps where the OAuth secret cannot be kept secure:

• Use the authorization code flow for native apps instead of the implicit grant flow (or user-agent flow as Salesforce calls it)
• Use the PKCE technique (https://tools.ietf.org/html/rfc7636) to prevent authorization code interception by other native apps
• Use external web browser for added security instead of embedded browsers for a better user experience that is more secure
• Instructs the native app to receiving the authorization code response by listening on local loopback address (i.e. http://127.0.0.1) or a registered custom scheme (i.e. myapp://oauth/salesforce or https://com.myapp.www/oauth/salesforce).

It looks like the Salesforce API is very close to supporting this. The current docs for "Web Server OAuth Authentication Flow" support code_challenge and code_verifier (PKCE), and it seems that the API allows me to ask for the refresh_token scope as long as I use PKCE, which is great.

The only problem I'm running into is that the settings page for my Connected App disallows the local loopback address (http://127.0.0.1) from being used because it's not https://.

The IETF BCP 212 notes in https://tools.ietf.org/html/bcp212#section-8.3
"Loopback interface redirect URIs use the "http" scheme (i.e., without Transport Layer Security (TLS)). This is acceptable for loopback interface redirect URIs as the HTTP request never leaves the device."

From what I can tell, Salesforce would be fully compatible with IETF BCP (aka RFC 8252) if an exception is made to allow redirect_uri to be http:// for the loopback IP (127.0.0.1).

Thanks for considering, I'm interested to hear if there will be official support and documentation for using this Best Current Practice.

It's also worth noting the BCP also un-recommends using the implicit grant flow for native apps: https://tools.ietf.org/html/bcp212#section-8.2

It's also worth noting that Google supports all the required parts for BCP 212, including the native/mobile app listening on 127.0.0.1:
https://developers.google.com/identity/protocols/OAuth2InstalledApp#creatingcred

As does the popular AppAuth set of auth libraries:
https://github.com/openid/AppAuth-iOS
https://github.com/openid/AppAuth-Android
https://github.com/openid/AppAuth-JS/blob/master/README.md

As a workaround for now, on a desktop app I'm using a custom scheme (myapp://oauth/salesforce), which Salesforce allows and works, but that method leaves a blank page open in the user's browser after they auth, which is confusing (https://na30.salesforce.com/_ui/identity/oauth/ui/AuthorizationPage). If we can use an non-TLS loopback address (http://127.0.0.1/oauth/salesforce) we can provide a better user experience by having control over the authorization page.