Skip to main content

Get Support
Have a question? Let's get you an answer!

How Do I...? Troubleshooting Code & Webhooks Developer Zone

Other Help Resources
Wait, there's more! Check out these Community sourced spaces for additional resources.

Zapier Help Center Hire an Expert

Learning Resources
All of our best learning resources can be found here.

Featured Articles Show & Tell Zapier's products AI Hub Zapier Tools Hub

Share your knowledge
Give back to the Community by sharing your automation wins and helping to answer questions.

Share your success See unanswered questions User Groups

Other Learning Resources
Some of our favorite additional ways to upskill your Zapier knowledge.

Zapier Learn Zapier Blog Zapier Webinars

Product Updates
Check out what is new and upcoming with Zapier with our regular product updates.

Product Updates

Early Access Program
Want to join Early Access? Learn more here.

My company is building a new integration and we typically use Okta via OAuth 2.0 Authorization Grant with PKCE for authentication. I was able to implement this with Zapier, however, I’m running into issues with the PKCE challenge itself. Sometimes, it works perfectly and I can log in, but other times it fails.

I generate this challenge only once in the code, however, when I look at the logs the challenge being used in the initial authorize call does not match the challenge being compared to in the getAccessToken call, which obviously results in a failed authentication. It appears that it’s executing the code that generates the challenge twice and creating a new challenge in between these calls.

I’ve tried to generate the challenge a multitude of ways from keeping it in the authentication file to moving it into the index file with a closure.

Another thing that I’ve found interesting is that so far I haven’t seen it do this when running tests locally. It only seems to happen on the Zapier UI.

Can anyone explain what could be causing this or suggest a solution?

I think what’s going on is that your code is running on many, many stateless server instances when you deploy your integration on Zapier’s platform. If you’re storing something in memory (like the code verifier) you can’t count on it being there after your function returns. It works when you’re testing locally, because… it’s all just running in one node instance. 

To make PKCE work you’d need a way to stick the code verifier into bundle.authData, so it’ll be provided as part of the execution context for the get access token request. I’m double checking to make sure I’m not missing something obvious, but I don’t think we give you a way to do that. 

If client id/client secret is an option for you, that’s what Zapier has direct support for today. There’s been a couple questions on this topic in the last couple weeks. Curious to know what’s driving the PKCE selection for Zapier developers right now? 

@Zane thank you for the explanation, that makes sense. Hmm.. so in looking at the AppSchema, it looks like there is something called beforeApp with this description: 

EXPERIMENTAL: Before the perform method is called on your app, you can modify the execution context

I previously played around with this, but I kept getting errors and stopped using it. Do you think I might be able to use this to store the PKCE info? If so do you have any pointers on using it? The documentation was sparse and I had trouble figuring out what it wanted.

The reason we are using PKCE is because we use Okta for all authentication and our app settings require PKCE for all public clients. I’m not yet sure if its possible to change that for certain situations or at all.

I think beforeApp is probably not going to be useful. I had to do some digging there to learn that was something that got added for internal use for something specific, and it probably should not have found its way into the public facing schema. 

We’re discussing what it would take to augment our OAuth 2 implementation to support PKCE. I feel confident this is something we will add support for, especially if we start seeing more identity providers or provider configurations like yours not supporting client secret. That said, I’m unclear on a timeline. I’ll certainly post an announcement on in this forum when we ship it.  

Terms & Conditions