About pdub

pdub · ‎01-02-2020

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: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 which could be used within the Steps 3-4 of your OAuth2 flow https://auth0.com/docs/flows/concepts/auth-code Thanks

pdub · ‎12-31-2019

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?

pdub · ‎12-31-2019

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? Thanks Jim

Re: Backend CC Integration using OAuth2.0

Re: Backend CC Integration using OAuth2.0

Backend CC Integration using OAuth2.0