How does an application work when it authenticates using a 3rd party, like Facebook?
I have a scenario where there is an online subscription management system. They have an API to authenticate a user that requires one to pass a callback URL.
I believe this only works if there is a web server out there that receives and manages the call back and that it won’t work with a desktop application.
However I have seen apps doing this with FB.
For OAuth you can use a custom URL scheme to send data to your desktop application: Redirect URLs for Native Apps - OAuth 2.0 Simplified
This article on oauth.com talks about mobile device compatibility, but it can be done on Mac, Windows, and Linux as well.
1 Like
For desktop apps, you can use a DesktopHTMLViewer control to implement an OAuth2 authorization code grant process entirely in the app. The “trick” is to use the control’s CancelLoad event handler to handle the callback and get the assigned authorization code.
I’m using this technique to handle OAuth2 authorization for Xojo-based desktop apps that integrate with NetSuite.
2 Likes
This is pretty cool. Would be nice if you can share this in your blog.
How would you do this from a console app that does not have access to the DesktopHTMLViewer control?
You’d have to run a local web server.
You could develop a desktop app that handles the authentication.
When the authentication code has been obtained, the desktop app could launch the console app, and pass it the authentication code as an argument.
Can you expound on this a little I’m trying to envision what role the local web server would play.
OAuth must happen in the browser. One step has the provider sending the user to a url that you specify. That url will receive a code that you can then exchange for an authorization token. So the local server would act as that return url.
I don’t know your use case. Tim’s idea of using a desktop app for the exchange would suffice too. One technique we’ve used in the past is to generate the “start” link and email it. From the email, the flow is completed and returns to a web server we control, which stores the authorization in a database so the backend can retrieve it later. Honestly, this is an awful setup and I hated implementing it, but there are some services (like QuickBooks and Adobe) that overuse OAuth instead of providing a long-life token suitable for embedding into backend services.
Ahh, I see now where you were going with this. Yes, it very much depends on how long the life is of the token received.
Depends on the service. I’ve seen tokens expire after an hour, with refresh tokens that last 90 days. I’ve seen others with a token that lasts 3 days and a refresh token that expires after 30. Every API will have their own expiration rates.
Perhaps ALOE Express can be used together with console app to implement this functionality?
Apparently this is a topic that I’m not alone in being interested in!
Thanks for all the input. This is a lot more involved than I hoped.
My app has been using an OAuth-based API for years now. I’ve used a few different techniques for this. Initially, I did the HTMLViewer method. But since my app is 7 years old, the HTMLViewer was a bit more buggy then. For example it CEF processes would get left behind on Windows, or the native renderer wouldn’t be good enough at all. So I completely removed HTMLViewer from my app.
The current iteration sends a public key to my web server as part of the setup request. The exchange happens in the user’s browser, the credentials ane encrypted with that public key, and my app polls my own API looking for the credentials. This works well enough, but sometimes users on Windows don’t have a default browser set so it just sits there waiting without opening the url in the browser.
I’m currently switching to a more traditional technique. Users will connect their external accounts to one of my app’s accounts using my website, and my app just finds them and uses them. It’s hard to overstate just how much better I find this user experience. But this design requires much more infrastructure too.
My point in all this is that there are many potential solutions and not any is particularly right, but there are plenty of ways to do it wrong. My advice after years of experience with this is, if you have a website, lean on it as much as possible. OAuth was designed for the browser, and there are good client libraries available if you’re not working with Xojo code. Don’t reinvent the wheel if you don’t have to, because OAuth 2.1 has new security features most articles don’t seem to be aware of.
If you really have to use OAuth in Xojo, Chilkat has a plug-in, though it doesn’t seem to support OAuth 2.1. MBS CURL has some OAuth features, but I’ve never used them.