Using OAuth with the Constant Contact API

Before you get started using Constant Contact’s API, we want to tell you a little bit about how we use OAuth, an authentication protocol that confirms a user’s identity without requiring the storage of customer usernames and passwords. You’ve probably seen OAuth in action: it’s what’s behind the scenes when you log into one service (such as Instagram) using credentials from another service (such as Facebook).

Until OAuth gained popularity, most services required a username and password to access an application and the data behind it. OAuth instead creates an intermediate artifact called a “token” to facilitate that access. That way, a username and password for one service, such as Constant Contact, does not have to be passed on to a second application that interfaces with the first, such as an app that you write. The two services merely exchange an OAuth token that essentially says, “I have validated this user and the user gave permission for your application to leverage their data on their behalf.” If a password is compromised on one application or site, OAuth prevents all of the other sites or applications where the customer uses that password from also being compromised.

OAuth is an increasingly important security standard, and it became a lot easier to use with the introduction of OAuth 2.0, which eliminates the need for developers to use third-party libraries to initiate OAuth transactions. (If you tried OAuth 1.0 and were frustrated by it, I feel your pain.) Constant Contact supports the full OAuth 2.0 standard.

Implementing OAuth

Implementing OAuth is a simple two-step process.

  • In the authentication step, the user is presented with a button that says, “Grant access.” Selecting that button opens up a window to the Constant Contact site, where the user enters his username and password. The user is then asked, “Are you sure you want to give the application access to your data?” If he responds, “Yes,” Constant Contact sends him an authorization code.
  • In the authorization step, the application exchanges the authorization code, which expires after 10 seconds and is immediately exchanged for an access token to the account. This important second step ensures that no third party intercepts the communication and poses as the user. The token, however, can be given a long time to live (ours is 10 years) so that the user does not have to repeatedly log in and apps can communicate smoothly with each other via the API.

The Constant Contact API supports two implementation flows for OAuth:

  • Server Flow is mainly used for token exchange between websites and web applications. It appears as a pop-up window and typically stores tokens on a remote server.
  • Client Flow stores tokens locally on devices for applications that are embedded or run natively on the device, such as a desktop, laptop, or mobile phone. With the explosion in mobile app development, we expect the use of Client Flow to increase.

Passwords belong in only two places: in the user’s brain and with the original application they signed up for. OAuth is a big improvement over the old way of doing things, which involved a lot of passwords being stored on third-party sites. And OAuth 2.0 is a tremendous improvement over OAuth 1.0; it is so much simpler to use. Constant Contact is pleased to support OAuth 2.0 and anything else that makes it easier and safer for your users to leverage their Constant Contact accounts in your apps.

Continue the conversation by sharing your comments here on the blog and by following us on Twitter @CTCT_API.


  1. richm541 says:

    Here’s a nice blog post discussing the various HTTP authentication schemas out there, with a good overview and explanation of OAuth 2.0:

Leave a Comment