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.