At this developer page...
…is this statement...
"Basic Authentication is still supported and can be used in new integrations, but we will be announcing the end of support for Basic Authentication soon. We strongly encourage developers to switch their apps to use OAuth 2.0."
I guess my request is continued support for Basic Authorization. OAuth does not fit my situation well.
Thanks for the feedback and I will definitely pass this on. It is unlikely we will continue to support Basic Authentication in the long term as OAuth 2.0 is just as easy to implement as Basic and is more secure (no passwords being stored and access to a specific token can be turned off by a customer at any time). Is there a specific scenario you have where you don't believe that it will be possible for OAuth 2.0 to be used that you could share with us?
Hi, Dave! Thanks for the encouragement and information.
The application for my friend is a guest-book kiosk (1930s typewriter parlor-punk) written in LiveCode. The first phase simply generated uploadable files. The kiosk is on the local LAN behind a firewall and file access is by user name and password. The kiosk does have internet access.
The second phase (about to be installed) uses a clear-text config file which does include my friend's Constant Contact user name and password. I'm not completely happy with that, but file access is password protected. It uses BASIC authentication to make contact changes. The application does not serve web pages.
This application will probably have only one istallation and all actors are trusted, however, there is talk of franchises and the future.
It seems a third phase is needed to implement OAuth 2.0.
I see several possibilities, different directions:
1. I can work with my friend and create a bearer token "by hand" using a web browser or a web tool. That token can be put into the config file. Presumably that token can be canceled, if stolen. Perhaps there is a secure web page at Constant Contact that can aid in this--put in the API Key and client secret, and get back a bearer token and a user name.
2. I can add a web interface to the app which is used within the LAN for setup including the creation of the bearer token in a more traditional way. The token can be stored in a file encrypted using an application secret. This opens the opportunity (translation: I'm creating even more work for myself--this is all free for a firend) for editing configuration information through the web interface and it and the bearer token can be saved in an encrypted preference file. And (more work) a stat page and other information might be made available for my friend. In contrast with other methods, this requires the creation of a server either within the app or used by the app.
5. The app takes on all roles of resource owner, user agent and client. This would require following redirects and parsing the form at the Constant Contact authentication server. The config file is not influenced by this and would stay the same for now.
My thoughts on how OAuth 2.0 might fit in with a simple application no doubt illustrate my ignorance of OAuth and confusion of how it might apply to my app. That should be interpreted as questions.
Pretty sure you're not that ignorant at all about how OAuth 2.0 works. You're completely right, if you're going to include OAuth 2.0 there has to be two things:
1. A way to open up a web page for getting the authorization page from Constant Contact (usually this isn't a hard part due to all the possible ways to load this up in modern languages)
2. Server page to receive the callback URL
There's really two ways to set up this flow though and that's where it can get a little confusing or hard for new OAuth users.
Server Flow - This flow uses the callback URL to send the information back to a server. The data is stored locally on the server. This makes the most sense for web apps and websites that have a server that all data is run from.
The best part about the Client Flow option is that the callback URL can be set up universally for all of your integrations you ever do and reused. So it doesn't end up being throw-away work for you or specific to any one client. It also doesn't actually show up to the person configuring the integration so you don't need to make a great looking page (though you should account for error messages and display an error message if a #error fragment is returned). If you're looking for more information on how to set up the Client OAuth 2.0 flow, I would suggest emailing myself (you should have my contact information from this morning) or our support team (firstname.lastname@example.org).
You also hit on another option, which is to just manually get an OAuth access token and insert it into a config file manually. It will still have all the benefits of OAuth and you won't have to design any sort of interfaces for your friend or much extra work.
This post has been moved to