Using zoom.us/oauth/authorize and zoom.us/oauth/token
Description
Simple question: Is there any way to use the PKCE flow to get an access token for a user, without having to use the client secret to create the Authorization header?
I’m working on a desktop app that will be distributed, and I don’t want to store the client secret if I can help it. LinkedIn’s auth flow can do this, and many online resources seem to suggest it should be possible. Some even suggest it’s the primary end of PKCE. Authenticating with OAuth 2.0 for Native Clients - LinkedIn | Microsoft Learn
If I’m barking up the wrong tree entirely, let me know. I’m definitely a newbie to OAuth and Zoom APIs in general.
Simple answer: NO.
You must have a client ID and secret to authenticate through the marketplace and obtain a token in return. Without getting your token for authority, Zoom APIs are not going to talk to you.
If you are using a desktop app, I suggest you create a login service on another server to authorise the person and pass through the tokens.
However, it is not as simple as that, and there are different situations.
So what sort of interaction are you expecting from Zoom?
What data will you be using?
We’re expecting users of our desktop app to authorize it to access their cloud recordings and some simple profile information. We followed the steps for User Authorization provided here. Being a desktop app, I think we’re technically considered a “public client” in OAuth 2.0 terms.
Maybe this should be an entirely different question, but our security team was surprised to see that Zoom requires a client secret regardless, and took that to mean that Zoom expects us to treat our app as a confidential client. I think if we could make Zoom require PKCE for auth, we’d end up just as secure as any other public client auth flow, but I don’t see anything indicating that’s possible. So we’d need to follow your login service suggestion, for example.
Are you or anyone at Zoom able to confirm whether we should operate under that assumption, or if Zoom has explicit expectations for how public clients ought to authorize/retrieve data on a user’s behalf?
OK, most of my apps run within ZOOM meeting SDK, the fact they are running in the meeting sdk means that they have authority from the connection by the marketplace to the user from within the zoom app. The scope of these calls refers to the meeting in which they are in and so no further need for identification.
What I call the 'SYSTEM api; (As I call it) are when you are doing a request to ZOOM Api server for data. This call can come from anywhere, zoom app, browser, external server. I can use these calls to in my apps. I can use them in my server-server apps.
All those calls require the Oauth process and token to validate the user or admin being represented by the API call. Zoom has not context to these calls without the token. I think of it as a user and security token.
And for security of that token , it expires after an hour and you use the refresh token to get a new token and continue.
