Our site uses forms to collect emails of interested parties and eventually desires to place them into a CC list.
After creating an approved app with an API Key and Redirect Url, I'm following the OAuth2.0 Server Flow (https://v3.developer.constantcontact.com/api_guide/server_flow.html) I'm curious:
This flow seems to assume our UI will be authenticating, which isn't applicable. Precisely: I'm receiving form UX code from "https://api.cc.email/v3/idfed" instead of something non-interactive. We simply want to deploy this component sometime in the future (perhaps days) on a server and have it insert contacts into a particular CC list.
It seems like CC is missing an example of this. I'm happy to follow the OAuth2 flow, but we won't have a browser/user in this flow in our architecture; it's just our server-side component. We desire to use CC from our own servers via a shared-secret mechanism. Questions:
1: Is there another pre-deployment interactive step I need to get an authorization code?
2: Also, it seems like authorization codes expire. Do we have to constantly refresh authorization with the renewal code, even if our site is not actively collecting emails?
3: Overall, this seems like OAuth2 is not the correct security solution for B2B style API usage here. What is Constant Contact's recommended solution for this architecture?
Digging around after writing the original post, I think I'm piecing it together, but CC isn't very clear on the documentation:
1 - Manually sign into CC with and create an approved application.
2 - Create your server architecture using the V3 API - that allows one to inject an access token into the logic at deploy/startup/run time.
3 - Use something (?) to follow the OAuth2 flow to acquire an authorization code and then access & refresh tokens. Note: The CC API help pages can sign into OAuth2 but do not seem to store the refresh token. (See Local Storage for the v3.developer.constantcontact.com domain in your browser tools).
4 - Create an async mechanism to refresh this token periodically, regardless of usage. This seems to be within 2 hours(?)
Step 3 seem especially problematic: What tool does CC recommend to quickly get a visible access token and refresh token, if it must be manually done?
I understand CC may be stepping up the security by removing fixed keys and using the OAuth2 protocol, but they need to make the expected workflow of how B2B integrations must clearer.
Can someone validate that I have this correct?
Thank you for reaching out to Constant Contact's API Support.
You have the information correct. At this time our oAuth2 flow does require user interaction once to type in the username/password of the Constant Contact account that you are sending your email addresses to, and to click the Allow button. Once this is done you will only be dealing with the Access Token and Refresh Token which does not require user interaction.
The Access Token can expire in one of two ways. It will expire after two hours if it is not being used, or it will expire after 24 hours even if it is being used.
Generally we recommend to use a local database to store your Access Token and Refresh Token so you can access these whenever you need them. Also many of our developers have found using a form of timer to refresh the tokens has been useful instead of waiting for an error code.
An example of the timer would be to set one timer for 24 hours and another timer for two hours. The two hour timer resets every time an API call is made. If either timer reaches its end then your program goes through Step 5 in the oAuth flow which is the step to refresh and get new Access/Refresh Tokens.
There have been several requests for an oAuth flow that does not require any user interaction for server to server applications. This is something we are reviewing, but we have not made any decisions on yet.
Thank you for the considered response. This places a more complicated design burden on B2B applications, which we are evaluating. Since the form-based processing does nothing to actually improve security (it merely adds a more-complicated browser-component requirement), please consider a signed-key exchange mechanism (of the same data) instead, following some like this IETF draft proposal:
which could be used within the Steps 3-4 of your OAuth2 flow