I want to get an API key from my account and tie it to a wordpress plugin which can then be installed on any wordpress website.
The API key requires a redirectURI -- this URI is custom for every wordpress install:
while I could generate that url and walk my users through generating their own API key with a custom redirect URL specific to their website, this is a _mess_. I am confident that any instruction I could provide will at best be a hassle and at worst confuse all but technically savvy users.
I desire to make my plugin usable by novice users looking to add constant contact support to their website.
How can I setup a cross-domain API key without the need for custom-tailored redirect URIs?
Looks like three-legged authentication is the answer as opposed to OAuth 2.0 through the CtCt wrapper
I'll post again if I have more questions or find out something interesting :)
Definitely let us know if you have questions. I've been working through some OAuth2 scenarios as well, and three-legged authentication does seem to be the best way to handle"novice-proofing" your OAuth2 authentication.
Sorry for the bump. This came up on google.
Please explain how a 3 legged Oauth2 helped you? I am running into this problem developing an addon for a CMS.
I am very very very new to thos Oauth stuff, so please explain in detail. Is there another way?
All clients will have different URLs.
Unfortunately, in this set up there are only two potential answers:
2. Use a shared server model. In this model, you would have the redirect URI hosted on a central server that knows the URIs of all your clients. This could then receive the callback URI calls, process them and communicate back to the unique websites of each of your individual clients. Indentification of the individual clients can be done as a query parameter for the redirect URI, such as: redirect_uri=https://example.com?local_doman%26http://individualcustomer.example.com
We recommend the 2nd for both security and predictability of browsers. It does require some additional communications on your side, but it is the best way to manage the authentication in a secure manner. Notice that we added an optional query parameter to the redirect URI that is the local domain of the client you're authenticating. It could just as easily be an ID number or anything you want to uniquely identify each client. Query parameters are not validated for security purposes and can be dynamically generated per call. The only requirement is that the exact same optional query parameters are passed on both stages of the call (request access and access token exchange).