PKCE does not work but is obligatory while using sdk v0.16.x

rafal.gawlik · September 22, 2022, 8:00pm

Zoom Apps Configuration

using in-app-auth (both authorize and onAuthorize scopes enabled)
additionaly using user:read and to obtain basic user informations
vue.js client side

Description
While using sdk v0.16.x, it’s obligatory to provide codeChallenge param to ‘authorize’ func. However, the PKCE flow does not seem to work.
I have fallowed steps described here: Zoom OAuth 2.0 Proof Key for Code Exchange (PKCE) Flow and used code samples from example app to generate code_challange and code_verifier but the result of performing POST to https://zoom.us/oauth/token was:

{
    "reason": "Invalid authorization code [CODE_HERE]",
    "error": "invalid_grant"
}

I have also tested the flow outside zoom client by performing following requests with same result:

GET /oauth/authorize to obtain the code

https://zoom.us/oauth/authorize?response_type=code&client_id=MY_APP_CLIENT_ID&redirect_uri=https://MY_APP_URL&code_challenge=HcxU-fpCfAuq012N945d7oQm_I7EU6-hZLRZ4oBQjbw

POST /oauth/token

curl --location --request POST 'https://zoom.us/oauth/token?code=AUTH_CODE_HERE&grant_type=authorization_code&redirect_uri=https://MY_APP_URL&code_verifier=889425d5c91ea2f482be0056801e9d5175ababcb0bff613a00481ffecede6f4310bbdce794968f1cfb4a11d250a8517bbbf6905c3a0314500735630cbc6aea1e' \
--header 'Authorization: Basic AUTH_TOKEN_HERE' \

code_challenge and code_verifier added intentionally so that can be verified
Above should be enough to reproduce the issue.

Additionally i have tested with the same requets but without PKCE and it worked perfertly fine.

Are there any particural app settings that need to be enabled to make the PKCE work?

Also, should PKCE be obligatory already? Looking at Announcements i’m a bit lost about the current status

xschen · September 22, 2022, 9:30pm

When you test outside of the zoom client, you need to supply a code_challenge_method parameter or else it will default to plain. If you add a code_challenge_method=S256 to your step 1 request, then your step 2 request should work. Otherwise in your step 2, your code_verifier needs to be the same as the code_challenge in step 1 since the challenge method defaults to plain.

rafal.gawlik · September 23, 2022, 8:52am

@xschen thank you! That helped me a lot!

Looks like while in zoom-client it also uses ‘plain’ by defualt so code_verifier and code_challenge need to be ęqual as well.
Additionally when using s256, code_challenge should not be base64 encoded.

It’s defenetely worth updating this post: Zoom OAuth 2.0 Proof Key for Code Exchange (PKCE) Flow and example app to match defaults. Hopefull someone from zoom will take care of it

xschen · September 23, 2022, 12:05pm

Glad that helped! Can you show me how you’ve been doing it with the in-client route? I actually haven’t been able to get it working myself regardless if the challenge method is plain or S256 (the default should be S256 according to an earlier post). No matter which method I choose, I always end up getting the same invalid grant error you referenced earlier. I’ve been wondering if it’s because if the user has already been authorized outside of the zoom client, going through the authorization process in client then just won’t work.

rafal.gawlik · September 23, 2022, 12:39pm

Actually i’m currenlty extreamly confused…

We are using two separate apps - one for testing/playing around and second is our production app that is already published. It is working fine for the testing app but fails for the production one. On windows it opens app authorization page (that should not be the case since the app was already authorized while adding to my apps) and then proceeds to app but the code generated there is invalid and i’m back on the invalid code/grant issue . On osx it’s stuck in authorize app page loop.

The way it works for testing app is by simply calling zoomsdk.authorize with same code_challange as the code_verifier in token request later. We are also making sure that redirect_uri passed to onAuthorize along the code is passed to our API and used when obtaining token. Given both production and testing app shared same configuration this looks more like some Zoom-side issues with auth flow.

Also, till yesterday we were using sdk v0.12.0 in which it was possible to trigget .authorize without PKCE and all was fine but suddenly, it stopped working - the onAuthorized event in not triggered anymore. When i realized we are behind by few versions i have udpated it to v0.16.5 from npm package and now we here.

rafal.gawlik · September 23, 2022, 3:17pm

@xschen small update here. I think i found the reason why our production had this authorization infinite loop on osx/invalid code/grant on widnows issue. We were missing FE url on the OAuth allow list. (we are using backend proxy as home url). Looks like the url that the app is on when zoomsdk.authorize is triggered must be listed as OAuth allow list. Maybe that will help you somehow

xschen · September 23, 2022, 4:37pm

Yeah the issue is just odd on my end. My ultimate goal is to try and get the email of the logged in user. I was thinking I can go through the in-client authentication quietly behind the scenes when a user launches the app (shouldn’t prompt the user to authorize again since they’ve already installed the app from outside the client), get an access token, and then hit the /user/me endpoint to grab the user email. It’s also strange that your code_verifier and code_challenge is working when they’re the same since it explicitly states here: Authentication that in-client oauth only supports S256.

Anyways, I just tried setting the code_verifier and code_challenge to the same value and still no luck with the in-client flow. My code is relatively simple:

zoomSdk.authorize({
    state: someRandomState,
    codeChallenge: myCodeChallenge
}).then((ret) => {
    console.log(ret);
}).catch((e) => {
    console.log(e);
})

zoomSdk.onAuthorized((event) => {
    var code = event.code
    var redirectUri = window.location.href 
    $.ajax({
        type: "POST",
        url: backendUrlForExchangingToken,
        data: {code: code, redirectUri: redirectUri}
    }).done(function(data){
        //completion code
    })
});

I’ve double checked the redirectUri there is in my OAuth allow list and the backend method used for retrieving the token is the same one I use without issue for the out-of-client install. I’ve also tried switching the token exchange call to a POST method with the parameters in the body and still no luck.

rafal.gawlik · September 23, 2022, 5:29pm

Check if in your case window.location.href matches event.redirectUri If not, that could be the issue.

xschen · September 23, 2022, 5:35pm

Ah I take everything back! There was a small bug in my token exchange code, and now it’s working when code_verifier and code_challenge is the same. Still odd that S256 is not enforced though even though the docs say that it should be. Hopefully there’ll be a notice when this eventually gets fixed in an upcoming release. Appreciate the help!

donte.zoom · September 26, 2022, 11:33pm

@xschen ,
Glad to hear you were able to resolve that bug on the token exchange. Can you share an example code_verifier and code_challenge values that are not enforcing S256 ? I am happy to test on my end and report this to engineers.

xschen · September 27, 2022, 4:15pm

@donte.zoom Here’s what I’ve tried and what’s worked so far using the latest sdk from the CDN:

In-client OAuth route:

code_challenge = 9JFq4jw9ItYisLBRSpgIONZcS4DrpHbJQ3qNge0dQw4
code_verifier = arandomstring256
result: invalid grant

code_challenge = 9JFq4jw9ItYisLBRSpgIONZcS4DrpHbJQ3qNge0dQw4
code_verifier = 9JFq4jw9ItYisLBRSpgIONZcS4DrpHbJQ3qNge0dQw4
result: token retrieved

Out of client web-browser OAuth route:

code_challenge_method = S256 provided in URL:

code_challenge = 9JFq4jw9ItYisLBRSpgIONZcS4DrpHbJQ3qNge0dQw4
code_verifier = arandomstring256
result: token retrieved

code_challenge = 9JFq4jw9ItYisLBRSpgIONZcS4DrpHbJQ3qNge0dQw4
code_verifier = 9JFq4jw9ItYisLBRSpgIONZcS4DrpHbJQ3qNge0dQw4
result: invalid grant

No code_challenge_method specified in URL:

code_challenge = 9JFq4jw9ItYisLBRSpgIONZcS4DrpHbJQ3qNge0dQw4
code_verifier = arandomstring256
result: invalid grant

code_challenge = 9JFq4jw9ItYisLBRSpgIONZcS4DrpHbJQ3qNge0dQw4
code_verifier = 9JFq4jw9ItYisLBRSpgIONZcS4DrpHbJQ3qNge0dQw4
result: token retrieved

MaxM · September 27, 2022, 7:45pm

@xschen We have an example of how you can use PKCE with Express on Github that might help here:

github.com

zoom/zoomapps-sample-js/blob/7815c73454e79c3708b8a77e1876a1cf83ca9f74/server/helpers/zoom-api.js#L68-L94


      
          /**
           * Return the url, state and verifier for the Zoom App Install
           * @return {{verifier: string, state: string, url: module:url.URL}}
           */
          export function getInstallURL() {
              const state = rand('base64');
              const verifier = rand('ascii');
          
          
    const digest = crypto
                  .createHash('sha256')
                  .update(verifier)
                  .digest('base64')
                  .toString();
          
          
    const challenge = base64URL(digest);
          
          
    const url = new URL('/oauth/authorize', zoomApp.host);
          
          
    url.searchParams.set('response_type', 'code');
              url.searchParams.set('client_id', zoomApp.clientId);

This file has been truncated. show original

xschen · September 27, 2022, 8:13pm

Thanks for the example @MaxM. It looks like that particular portion of code is showing off how to generate an out-of-client install link where you can specify the code_challenge_method. That aspect of the authorization process has been working for us as well.

The confusion we were having is from the in-client oauth method where according to the docs here Authentication, specifically:

only S256 should be supported, but the opposite seems to be happening where the token exchange is only working when code_verifier = code_challenge.

erik.tedder · October 13, 2022, 5:54pm

I am still seeing this same issue with in-client authentication using the v0.16.5 SDK

Only values possible for the authorize function are state and codeChallenge, as described in the AuthorizeOptions interface, and are noted to use PKCE by default. However, using PKCE and using the code verifier results in an invalid_grant response. Using the code challenge instead gets me the appropriate access token from Zoom.

Any advice here? As @xschen state, it seems there is a disconnect between the documentation and what is actually happening

Topic		Replies	Views
Invalid authorization code with PKCE API and Webhooks	2	841	July 10, 2021
In-client auth - Invalid authorization code Zoom Apps	4	719	October 26, 2022
PKCE - invalid_client API and Webhooks	2	454	January 4, 2022
URGENT ### {“reason”:”Invalid authorization code ***”,”error”:”invalid_grant”} Zoom Apps	4	441	April 23, 2024
Bad request on In-client OAuth server side token request Zoom Apps oauth , pkce-flow , pkce	3	757	July 5, 2022

PKCE does not work but is obligatory while using sdk v0.16.x

Related Topics