|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
* 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:
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
(The article Redirect URLs for Native Apps on Okta (a competing Authorization Server) lays these things out quite neatly. Ldapwiki: Claimed Https Scheme URI Redirection on JSPWiki is more jumbled, but references RFCs).
That leaves us with ... running a quick webserver on the loopback/localhost address. Our 'redirect_uri' becomes 'https://localhost:1234/myapp'
Now we have to nominate a port to bind to, that is 'guaranteed' to be available at runtime! Fortunately, we can do bit of a scattergun and nominate *multiple* redirect_uri (https://localhost:5678, https://localhost:6789, etc) when registering our Client with the Xero Authentication Server (or we'd be sunk, basically, if another long-lived app decided to bind to the port we'd chosen).
Great, so we find an available port. Now to bind an HttpListener to the port and wait for the User Agent to hand control back to us.
So we either need:
* admin privileges to bind the port without a 'urlacl' reservation; or
* to have previously done something like "netsh http add urlacl url=https://+:1234" (for at least the redirect_uri variants we have chosen to use at runtime) ... which requires either that we set this up when we had elevated privileges when we installed our app (or not ...since we are ClickOnce), or that we obtain such privileges NOW to do the "netsh http add urlacl" work.
In either case, we now need to refactor a part of our app out to a separate process and arrange for it to run as admin ... which we never intended for our user to have to do ... so that they can delegate the right for our app to access their Xero accounts. Thankfully they only have to do this INFREQUENTLY, but they'll need someone with local admin rights standing over their shoulder when they do
modified 15-Sep-20 10:50am.