Authentication for non-user-interactive integrations

[Rez]

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)

Mail Chimp

ShipStation

Zendesk

Google (multiple API suites)

LightSpeed eCom

Shopify

SalesForce

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.

[John__B]

Hello NateP57,

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.

While we don’t have any updates on an alternate flow for unattended/non-interactive API integrations at this time, we are still investigating several options for future updates to help accommodate these types of integrations while also maintaining account security.

Please let us know if you have any other questions!

Regards,

[Courtney_E]

Hello NateP57,

Thank you for reaching out to Constant Contact API Developer Support. 

There is currently no way to bypass the initial Authorization Request screen and redirect, which can only be accessed/authorized via a browser window, but you should only need to authorize an account once. 

However, with the recent update to our new authorization management service, we did recently release the capability to generate V3 keys that offer a Long Lived Refresh Token (which can be configured within your key’s settings), where you can use the same refresh token continuously to generate new Access Tokens.

Update Your Applications to Use the New Authorization Service

https://v3.developer.constantcontact.com/api_guide/auth_update_apps.html

While we generally recommend using rotating refresh tokens (as they're more secure), using a long lived refresh token should alleviate many of the situations that we've seen reported where a refresh token becomes invalid, and then requires a new authorization request.

Currently, the Long Lived Refresh Tokens are only compatible with our OAuth2 Authorization Code Flow, and must be used at least once every 180 days in order to remain valid.

OAuth2 Authorization Code Flow

https://v3.developer.constantcontact.com/api_guide/server_flow.html

Please have a look and let us know if you have any other questions!

[MarketerL5795]

Looking at upgrading from your V2 to V3 API for an integration and I'm surprised you don't have a Client Credentials Grant. Any idea when/if this will be available?

[John__B]

Hello MarketerL5795,

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.

A Client Credentials flow is one of several options we’re investigating for future updates to help accommodate non-interactive integrations. While I’m unable to provide an ETA or specifics for future updates at this time, we’ll be sure to notify our users about these types of updates when they occur. You can keep an eye on our documentation for these types of announcements:

https://v3.developer.constantcontact.com/api_guide/release_notes.html

Please let us know if you have any other questions!

Regards,