About Rez

Rez · ‎04-06-2021

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.

Rez · ‎03-16-2021

As of now, Constant Contact does not support any non-interactive authentication, period. I've requested that they add it, and asked for clarification as to why they don't already have it, but it's clear that they have no intention of allowing it. The integrations I develop for customers are based on Node.js code in AWS Lambda; if Constant Contact allowed the OAuth2 method "Client Credentials", which was included specifically for m2m/non-interactive processes, it would be straightforward to authenticate via Node.js.

Rez · ‎03-16-2021

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.

Rez · ‎02-25-2021

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!

Rez · ‎01-10-2021

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.

Re: Authentication for non-user-interactive integr...

Re: Server side API logon with Node

Re: Authentication for non-user-interactive integr...

Re: Authentication for non-user-interactive integr...

Authentication for non-user-interactive integratio...