I read through Mark-C's post dated 6-28-2012 regarding OAuth 2.0.
Here is my situation. I have a desktop app written in vb.net that currently integrates with CC. This is a retail app that we sell to various organizations. Each customer that we sell this app to may have their own CC account, and if not, we give them the opportunity to sign up for one within our app.
Most of our customers access the internet through a DSL or Cable connection. Some of our larger clients may also have their own web servers that they can go through to get to the web.
The customer will input their CC login name and password into our application and this information is used for authenticating to CC and performing the various tasks. Everything works great!
My question is, what options do I have in terms of using OAuth 2.0? There is no "Call Back Server" available for 90% of our customers and from what I've read this is a requirement of OAuth 2.0.
Normally I woudn't worry too much about this except I read somewhere that sometime soon you are going to disable the whole Login/password authentication method. Once you do I would have no way of authenticating to CC because our application model won't support OAuth 2.0.
I would hate to think that I'm simply SOL and that all of our customers would lose the ability to integrate with CC through our application. Accessing CC is not the primary function of the application but it's a really nice feature to be able to include.
Do I have any other options (short of writing and hosting a web based app., which isn't going to happen) to be able to continue to use CC once you disable the Login/password authentication method?
Cascade Data Solutions Inc.
You should be able to use the OAuth2 Client flow, which doesn't involve a server on your side. It's the same flow that would be followed if someone was authenticating your apps's access to Constant Contact via a mobile phone. They essentially just need to make a call to us, gain their access token, and then that access token is stored on the device that authenticated (in your case, the terminal or computer they used).
The OAuth2 client flow is descirbed in the second half of this page. Let us know if you have any other questions!
API Support Specialist
Hi and thank you for your reply,
The Client Flow section still refers to a redirect_uri as https://somedomain. So instead of a domain (which I don't have), what am I to do with this parameter? Leave it blank? User a folder path instead?
Yes, you would need a redirect uri. We do plan on giving users an access token upon creation of an API Key in the future (before we deprecate support for basic authentication), so since you do have usernames and passwords, you could use those to generate an (unnecessary api key along with and) access token to use OAuth2. This way you wouldn't have to worry about the OAuth2 flow, but you could use access tokens in place of usernames and passwords.
I hope that helps.
API Support Specialist
The Client flow does still require a redirect_uri parameter for security purposes, but the server does not need to either be real or something you own. The Client flow never hits the redirect_uri so the address you provide never needs to resolve. In the Client flow, you intercept the redirect request in your WebView (HTTP client used for .NET) before the request to load the page ever happens. Then, just pull the access_token out of the URI fragment and close the WebView. Many people use a default domain name such as the reserved domains listed in RFC 2606 that are not resolvable through a website. You can also use your company website. The only requirement is that the redirect_uri is passed as part of the request, it is a valid domain format and that it matches the one you have set up for your API key.