OAuth 2.0 when a .NET desktop app is the 'client'
-
I would like to submit my reasoning for validation/sympathty. If your head is not already full of OAuth 2.0 the language here might not make sense. Some context is required: * The Resource Server is Xero * The Authorization Server is Xero * The Authorization Server permits registration of Clients which use either the 'Authentication Code Flow' or the 'Authentication Code + PKCE Flow' * The Authorization Server correctly requires Client registrations to supply a 'redirect_uri' * The Authorization Server incorrectly requires Client registrations to supply a 'redirect_uri' only with an https:// prefix :sigh: * The Client is my .NET desktop ClickOnce app * The User Agent (browser) runs on the same machine as the Client, in the same desktop session * the User making the OAuth 2.0 delegation does not otherwise need admin rights to the machine ... and the Dev (not really the subject of an OAuth spec, thank heaven!) just wants to get on and write his business logic. :(( Right, so back to work: :java: To get an access token, we first of all need an authorization code. We get that from the Authorization Server through the 'front channel' ... the User's User Agent (ie. a browser) is given an HTTP redirect to the 'redirect_uri' with the information we need in an HTTP request. And here we run into 'hassle'. IF our Client were an Android, iOS or UWP(?) app, we could have registered for a 'Claimed Https Scheme URI Redirection' ... when the User Agent (browser) visits https://example.com/, it will activate the app and send the URL to us! (so long as we can convince the respective app store WE own example.com ... it's all in the app manifest). But ... that's not us. We're a 'legacy' app on Windows. Well, we could use a 'Custom URI Scheme' and register 'com.example.myapp:/foo' with Windows, which would (after a browser prompt) activate our app and hand the URI over to it (maybe ... it isn't clear if we can do this for ClickOnce apps that are 'installed' in each user's roaming profile). We get the same effect as with the Claimed HTTPS URL approach. But ... that's not us. Xero won't let us use a Custom URI as the 'redirect_uri' anyway :doh: (The article Redirect URLs for Native Apps on Okta (a competing Authorization Server) lays these things out quite neatly. Ldapwiki: Claimed Https Scheme URI R