This is great news! Thanks for the feedback on future plans.   Specifically for our situation, the main problem is that the existing OAuth flows are tied (at least during authorization) to an assumption that they are initiated from a web application of some sort (thus the requirement of a redirect URL). Since our utility is command-line only, a client cannot "redirect" to it. To be sure, I'm not an expert on OAuth 2.0, so I'm not entirely certain what flows would be best in our situation... some thoughts: The Device Authorization flow (as I understand it) is interesting to me as I can at least imagine how the authorization would work in a command-line situation (polling an endpoint seems... painful, but can certainly be accomplished). Client Credentials also seems interesting, though it may be dependent on implementation as the documentation I was looking at still included a redirect URL. I think, however, that you could provide any URL (maybe just "https://constantcontact.com"), as it doesn't necessarily return any information you would need when getting the access token. Constant Contact could also provide a simple page to use as the redirect URL in situations such as ours. I'm not sure what "static refresh tokens" means exactly, but if the idea is simply to alter the Server flow such that the refresh token doesn't change each time a new access token is requested, that would certainly also reduce the problem for us as it would be unlikely for a refresh token to become invalid (though I wonder if that is allowed under the OAuth specifications). In such a scenario, I would think a long (or configurable) expiration would be in order to periodically force new refresh tokens to be generated. Probably more useful to you is our use cases: The ideal use case is that a static set of credential information can be stored in secure location (a file, database table, etc.) and is all that is necessary to connect to the API in a repeatable manner. If that connection requires exchanging the credentials for an access token (which certainly seems more secure), that's absolutely fine, but would not require the utility to receive a web request of any sort (e.g. the redirect we see in the Server flow). In this ideal scenario, other than setting up the App on the Constant Contact site (MyApps), no further interaction would be needed to authorize the utility. Acceptable approaches would soften the stance on user interaction during authorization. The utility could either be pre-authorized entirely on the Constant Contact site (and any necessary credentials or tokens manually recorded into its configuration), or it could initiate an authorization request that is entirely completed on the Constant Contact site (again, manual copying of credentials or tokens is fine). It's worth noting that the current Server Flow is close to our needs. The biggest problem with it is the reliance on a web application (the target of the redirect URL) during the authorization flow. Since I don't have an appropriate internal target for this redirect, I'm left giving it a dummy URL and manually watching HTTP traffic in DEV tools, using a third party tool (e.g. Google's OAuth Playground), or developing a purpose-built web application just for the task. A very simple workaround (for us, at least) would be for Constant Contact to simply build functionality on their own site (somewhere in MyApps) that would allow me to move through the flow to the point of receiving a refresh token (basically taking the place of OAuth Playground).   We are moving forward with our work migrating to V3 using the server flow and OAuth Playground. I will, however, be interested to see new developments for alternative authentication methods as the become available (and will modify our implementation if any are appropriate for our uses).   Thanks for taking my feedback into account! ... View more

As an addendum to my response (primarily in hopes it will help others in my situation), I think I may have found an acceptable method to manually generate the refresh token when needed without building a custom web application. Google has an excellent tool for testing with OAuth2 APIs (OAuth 2.0 Playground). It's primarily geared towards Google's own APIs, but can be used with custom settings (click the Cog at the upper left and choose "Custom" under "OAuth endpoints"). You have to add https://developers.google.com/oauthplayground as a valid redirect url on your Application on Constant Contact's side for this to work. Put in the necessary information, go to the left and enter the desired scope(s), then click Authorize. As you step through the tool, eventually you get to where you have a refresh token and access token. At this point, the refresh token can be entered wherever it's needed (in our case, it will have to be recorded in a database table somewhere, since each use generates a new refresh token).   All that said, this makes my second option (document a manual process) reasonable. However, I do still think it would be a much-needed/desired enhancement for Constant Contact to implement the OAuth2 Client Credentials Grant flow. And I can easily imagine use cases where this would be a necessity (imagine a situation where someone not technically minded had to regenerate a refresh token!).    I also dislike the dependence on a third party to help me get the refresh token. I suspect I can trust that Google won't be removing the OAuth playground tool any time soon, but if they do, I'll be back in the same boat I was before I found the solution. As an alternative, I suppose Constant Contact itself could provide an internal redirect URI page to facilitate generating refresh tokens when a reasonable redirect_uri can't be identified (or just create an interface on the app page that let you generate them as needed). Certainly this would be a quicker implementation than building out support for a new flow, though it's really more of a workaround than an actual solution. ... View more

This ensures that you only need to authenticate the account you’ll be connecting to once. After the initial authentication, you’ll just use the refresh token and access token to complete your requests. Yes and no. Certainly this is true as long as everything works correctly. But if the refresh token ever gets out of sync (e.g. I use it to generate an access token, but the response gets lost in transit due to a network problem), I will need to go through the initial steps again to get a new refresh token. An important part of all this is that the system must be maintainable by other developers in the case of my unavailability (the proverbial "if I get hit by a bus" scenario). That means I need to -- at minimum -- document the process of re-authorizing and generating a new refresh token. This leaves me with two options: Automate the re-authorization process (impossible without literally developing a web application to provide the web-based UI server flow expects) Document a manual process (possible, but ugly, since it would require steps like "generate the URL with a dummy redirect_url, turn on developer tools in the browser and capture the HTTP traffic). Or am I missing something? ... View more

I'm running into exactly the same kind of situation. We have a (rather complicated) internal utility that we use to synchronize contacts on specific lists in our account. We've been using the V2 API to do this for years, but I realized recently that Constant Contact is making a push to get rid of the V2 API (you can no longer create new app keys for it). So, I started looking in to V3. First hurdle -- must go to OAuth2.    Our utility is run unattended, after-hours. There is no true UI (though there is a very basic console-based UI for troubleshooting purposes). After digging into the options available, I'm left wondering how in the world to use the server flow without literally building a web application to receive the redirect -- all just to maintain the authorization. I considered hacks -- just make an invalid redirect URL, open a browser, and capture the HTTP traffic in web developer tools, then copy the keys around manually, maybe -- but this is not sustainable. It may get me working initially, but I have to make sure the process is easily documented so that other developers can handle the process if I'm not available.   At this point, I'm going to hold off on trying to adopt V3, and I may contact Constant Contact support directly to push for either limited bearer token (basic) auth or OAuth2 Grant Type Client Credentials (which I need to research). It may not amount to much, but another voice can't hurt. ... View more