I had a phone and email discussion with Eric Houston about this - while he assured me that I wasn't the only person who had asked about it, I didn't see anything explicitly relevant in the boards.
I develop automated/unattended/non-interactive integrations. These integrations are usually triggered by webhooks in the source system. Example: a new customer record is created in an eCommerce platform; that event triggers a webhook, allowing the customer to be propagated to one or more other systems via secure automated integration brokering. Please note - I am not looking for or asking Constant Contact to create webhooks or trigger events!
Today, virtually every vendor/provider supports this type of integration. They do so by providing one or both of the following authentication protocols:
Basic Auth. Constant Contact has dropped this capability citing security concerns; for user-interactive activities, you’re right, OAuth 2 is more secure. For unattended integrations, Basic Auth continues to be the industry standard, and since API keys and secrets are passed encoded and within headers encrypted via HTTPS, security really centers around keeping API keys and secrets secure, which is and always has been (and always will be) the developer’s responsibility. This protocol consists of encrypted credentials being passed for each API call.
OAuth 2, Grant Type Client Credentials. This grant type was designed to authenticate access outside of user context, which fits the unattended model; however, this OAuth 2 grant type doesn’t appear to be enabled in the Constant Contact V3 API. This protocol consists of encrypted credentials being passed, a token being returned, and the token then being passed for as many API calls as required at the time.
At this time, I have integrations in production to/from many popular/widely used systems, all of which support either Basic Auth, OAuth 2 Client Credentials Grant, or both; some examples are:
Microsoft (the entire Office 365 ecosystem)
Google (multiple API suites)
As I mentioned to Eric, Constant Contact is literally the only platform I've been asked to integrate with that does not offer one or both of these protocols. If Basic Auth is off-putting for whatever reason, then why not support OAuth 2 Client Credentials Grant? It's part of the OAuth 2 spec along with the other flows, and is present in the OAuth 2.1 draft spec as well.
Eric had the impression that this might be addressed in the future, but I wanted to bring it up in this forum as well.
Help me understand why their oAuth 2 "Server Flow" doesn't meet your requirements. I'm starting on implementing it now and don't want to get half way there to discovered I've missed something. Granted, I just need the contact list manipulation APIs.
Constant Contact's "Server Flow" doesn't support unattended non-interactive authentication. It is in many ways similar to their "Client Flow", where multiple exchanges occur, including redirecting to a web page for credentials. For web apps, this is completely normal; for true point-to-point (or m2m) integrations, there is no redirect location, and there is no user entering credentials. Thus, neither "Server Flow" nor "Client Flow" will support such integrations without significant kludging and workarounds.
For context, here's a typical workflow for integrations I develop and support:
An Ecom system has a webhook to detect customer creation. The webhook calls an API in AWS (the call is authenticated). The API calls a Lambda function written in Node.js (just my preference). The Lambda function:
Parses the incoming JSON payload and constructs JSON payloads for downstream systems (Constant Contact, Mail Chimp, etc.).
Pulls credentials from Systems Manager Parameter Store (as secure as it gets).
Calls each downstream API with appropriate payload, recording the result.
Logs the event, including sparse data about the customer and the results of the API calls.
Every data transaction is secured via https, and all credentials are stored securely. At no time does a customer (or me for that matter) interact with the integration, aside from receiving a notification via text or email if they wish.
There are authentication methods specifically designed for this type of operation - the two I mentioned in my post. For OAuth2, the contributors intentionally included the Client Credentials grant type to accommodate m2m authentication.
Hopefully that wasn't too long-winded. Let me know if you have any other questions!
Thanks for the reply. I think for me, the current capabilities will suffice...that is, the client of my application does have to interact to give my app permission to access their account information(via the api). After that setup, I can, via the refreshToken, use the API to interact with CC with no interaction from my client.
I made a post about this use case almost a year and a half ago, they have done nothing. I don't come to this board very often but I always see posts about this.
I've concluded that Constant Contact has decided to not support it, for whatever reason. I've lost two opportunities in the last year due to not being able to provide integration to this company.
I am trying to implement this exact thing and I've run into the same issue. Mine is an internal problem and this is not an issue I've encountered with other products (as you mention). This creates a significant bottleneck in integrating different systems and allow for automation of processes. I would imagine this function is critical for many people.
The number of people and companies impacted by this is not insignificant, for sure. Interestingly enough, Microsoft is just starting a project to deprecate Basic Auth for some of their Office 365 functionality - they have initiated an exhaustive communication campaign to ease the transition process for integrations. They point directly to the Client Credentials OAuth2 grant type as their preferred method for m2m/unattended integrations, which lines right up with the stance of nearly all major cloud vendors.
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.
Thank you for reaching out to Constant Contact API Developer Support. My team is here to assist outside software developers with questions about building into Constant Contact's API.
After you complete the OAuth2 server flow, Constant Contact returns an access token and refresh token. You can use access tokens to make requests using the V3 API. You can use refresh tokens to obtain new access tokens without any user input. 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.
V3 API OAuth2.0 Server Flow
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:
Or am I missing something?