V3 .net Headless Server-to-Server Example

[JoB683]

I want to develop a .net service that will run on a schedule and query my company's campaigns for recently sent emails.  This service will run completely independently of user input.  I don't have our Constant Contact username and password but instead have the api key and access token that my colleague generated for me. Once the service is built and deployed, there will be no user input. Everything I read seems implies that OAuth is required but entering account details is not an option.

It's important to stress that this is my company's account and will not be used in any way by third-parties. The service is (for all intents and purposes) the account owner but does not have login credentials.

Can someone provide code samples as to how to go about this developing this?  

[David_B.]

Hello,

Thank you for reaching out to Constant Contact's API Support.

Unfortunately I don't have any .NET code samples on this, however our OAuth process only requires the account owner connect once. They will get back an Access Token and a Refresh Token. Once you have these, you can programmatically use the refresh token to get a new access token without the need for the account owner to manually log in each time.

If you wish to view our documentation our OAuth, see here:
https://v3.developer.constantcontact.com/api_guide/server_flow.html

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

Regards,
David B.
Tier II API Support Engineer

[GRRA]

I've read through the server flow docs several times and still don't see how you can you can use the refresh token to obtain new access and refresh tokens more than one time. As I understand it, once you use the refresh token to obtain a new one it becomes expired and can no longer be used. That seems to suggest the refresh token needs to be stored on the server so it can be used on the next request. If this is truly the recommended approach, it doesn't sound feasible if you have multiple users making the same request simultaneously. My preference is to keep things stateless and not store the tokens.

It seems awfully shortsighted if this is the only way developers can authenticate server to server. Please let me know if there's something I may be missing related to refreshing the token.

[David_B.]

Hello,

We use current OAuth standards for security purposes. Access tokens are good for up to 24 hours. Refresh tokens don't expire, but will become invalid if they are used or if the initial authorization flow is completed again. If you could use the same refresh token over and over, that kind of defeats the purpose of having a rotating access token.

When you use your refresh token, you get a new access token and a new refresh token as well. You then use the new access token until it expires, and refresh using the refresh token that was given at the same time as the access token you were just using.

Typically in a situation such as yours where you have multiple users making calls for the same Constant Contact account, you would have your server control all of your calls, storing the access and refresh token, and refreshing it when needed.

Please let me know if you have any other questions.

Sincerely,
David B.
Tier II API Support Engineer

[GRRA]

I'm still unclear why you would involve a refresh token in a machine to machine scenario. I already have the client id and secret - neither of which are public because this is running on a server and not in a user's browser. Why can't my application make a request to exchange those for an access token that expires after a period of time? Your system could then verify that access token before processing requests. An example of this can be seen on Auth0's site [1].

Unfortunately, your refresh token process is very inefficient for machine to machine scenarios like this and requires APIs to make several unnecessary requests. If I'm not mistaken, my API will need to request the current access and refresh tokens from my db, then make a request to the CC API only to find out the access token has expired. Now I have to make another request to your API using the refresh token to get another access token and refresh token, then save those tokens to my db again. Finally, I'm ready to make another request to the CC API with the new access token. While this is happening, I have to hope another user doesn't make the same request, since their request would fail as well and would cause them to do this same dance. Problem is it would be unnecessary since another user just fetched a new access token - but I really don't want to block requests while one user is getting a new token.

Did your team consider the approach of exchanging the client id and secret for an access token like Auth0 uses in machine to machine scenarios?

[1]: https://auth0.com/blog/using-m2m-authorization/

[ServiceNation]

Has this been looked at for server to server applications? We do not want to have any user input for our posting of additions or updating. We just need to be able to make a request for authentication using the client id and the client secret and get the access token without having to have a user connect to the account. 

[Courtney_E]

Hello BobV00,

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.

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, it looks like your account may be part of a Partner Group with Constant Contact:

Specifically for Partner accounts, we now offer the new option of acquiring a “Master Token”, which allows you to send API requests on behalf of Partner managed client accounts without needing individual access tokens for each child account.

However, in order to utilize the master token, you will likely need to make significant changes to your application’s existing code, as instead of using the the standard Oauth flows and storing tokens for each child account, you would be using the Partner authorization method to get a Partner API access token (JWT), then using that to call the "pass-through" Partner endpoint.

If you decide to go this route, please let us know the API key that you will be using for your application (by emailing us securely at webservices@constantcontact.com along with the URL link to this post for reference) so that we can grant it the correct permissions.

Technology Partner Registration

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

Technology Partner Authentication and Authorization

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

API Reference - POST Send an API request on Behalf of a Client Account

https://developer.constantcontact.com/api_reference/index.html#!/Technology_Partners/partnerAccountO...

Alternately, if you at all anticipate potentially needing to be able to connect your integration with with an account that is not directly under your partnership, and/or don’t want to have to fully re-code your application, the other option would be to utilize the Redirect URI within your application’s flow so that each client can connect their own account and grant permission, rather than you having to get each account’s login credentials. Essentially, each connected account would need to grant access and your application would need to store each of these token sets for making calls to each connected account.

When a user goes to connect their Constant Contact account to your integration and clicks “Allow” on the Authorization Request screen to grant your app access to their data, they are sent to the website URL that you specify as your Redirect URI. After the account owner is successfully authenticated and authorizes your application, Constant Contact redirects the account owner to your chosen redirect_uri and appends the Authorization Code to the URL, allowing your application to capture it and exchange it for your initial token set.

Get the Token from the Redirect URL

https://v3.developer.constantcontact.com/api_guide/auth_overview.html#get-the-token-from-the-redirec...

Create an Authorization Request URL

https://v3.developer.constantcontact.com/api_guide/server_flow.html#step-1-create-an-authorization-r...

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