Closed lancelotdaemion closed 4 months ago
OAuth is built precisely for this sort of situation. You need only one OAuth application on our side. You could use your existing Vision2
application, provided you update the description and change the URLs to point to your actual web application.
Logging into the customer's account to create an OAuth application for them is absolutely not the way it should be done.
Instead, you would use your single OAuth application Client ID and Secret to initiate the OAuth flow for each customer. So, to adjust the steps you listed above, it would look like this:
--- steps.txt 2024-04-11 09:25:39
+++ steps_corrected.txt 2024-04-11 09:26:34
@@ -1,5 +1,5 @@
-1. Create a new OAuth app for them (https://api.planningcenteronline.com/)
-2. Activate them on our side with OAuth using the provided client id and secret.
+1. Use your own Vision2 application.
+2. Activate them on our side with OAuth using the the Vision2 client id and secret.
3. This shells out to you to get an access code.
4. Then we pass the code, client id, and secret to PCO to get an access token.
5. After that any requests are authenticated using the access and refresh tokens.
Oh, I wanted to add one thing: it can be confusing that an OAuth application is owned by an organization. The organization that owns and manages the OAuth application (Vision2) can just represent your company -- not a specific church. So you could call that organization Vision2 as well. It has no effect on the OAuth flow and will not be shown to the customer when they authorize your application.
I hope that helps!
Wouldn't each customer have their own client id and secret? Once we have an access token how does rest calls know which org we're talking to?
Wouldn't each customer have their own client id and secret?
Nope! The Client ID and Secret is only used initially for the OAuth flow and to do token refreshes.
Once we have an access token how does rest calls know which org we're talking to?
The access token is connected to that customer's account on our side. So when you pass the token in the Authorization
header, Planning Center knows which customer it belongs to.
I don't know if this helps, but I found this video that gives a good overview of OAuth 2 and it's very similar to the way it's used at Planning Center.
https://www.youtube.com/watch?v=guvhHTyyAUo
We have also improved our documentation so it's a bit more clear that only one OAuth application is necessary and it can work with multiple churches.
Please let me know if we can be of more help!
Thank Tim. I'll be reworking our OAuth process for PCO Monday and resubmitting.
Thank you @lancelotdaemion! And thank you @seven1m for your help here.
We've integrated with PCO for 7 or 8 years using PATs. Now we're hoping to get listed on your Integrations page (https://www.planningcenter.com/integrations) so we've switched over to OAuth.
We're getting rejected because
I'm not sure on what this means. We're multitenant and every org has their own integration. During initial setup for the customer we:
a single Vision2 application that drives the OAuth interaction for all churches that use the integration
It is a single application, just multitenant. Help?