Description
Previously, you used to be able to obtain Zoom’s userId from the access token (V6), however it looks like the structure/contents of the access token has changed (V7) and no longer includes this information. We use the userId and store it on own User object in our database when an access token is granted and when we receive a a Deauthorization Notification we use the userId contained within this to find the matching user:
Is there another way to get a Zoom users Id?
It looks like the fields are renamed in v7, so instead of “userId” and “accountId”, they are called “uid” and “aid”.
I just found out this the hard way, since our app stopped working because of these changes too. I don’t get how this kind of change can just happen like that and break everything? It should either be loudly announced (I can’t even find this in the changelog), or all apps should choose if/when they want to upgrade to the new token version.
How can we protect our apps from breaking when Zoom decides to rename/remove some of these fields again in the future?
Yeah, I got bitten with that one too… Wrote a post on it. Nobody from zoom replied though. On why they changed the names…
Same here… I guess their JWT size was too big and they wanted to reduce it
Hey @martin, @MarkWalsh, @a.sinnige, @miroslav.grozdanovsk, @a.sinnige,
JWT Decoding the access token is not something listed on our docs, hence it could change anytime.
Apologies for the inconvenience and for suggesting this in the past.
To get the userID of a user, use the Get User API. The me context is also helpful when getting information about the user of the access token.
Thanks,
Tommy
If 5 people have posted about this breaking, there’s at least 5x that many who read the post and fix it quietly on their sites. How many users need to be doing this before Zoom finally admits its not “everyone else who is wrong”?
not something listed on our docs, hence it could change anytime
This assertion, while true and certainly Zoom’s prerogative, doesn’t make it okay to silently introduce breaking change keys in production tokens without any announcement at all - if version 7 tokens are not backwards compatible to version 6 tokens, some communication of at least that fact well in advance of the production deploy would be a welcome courtesy.
In summary, please treat your developer community like a community - we are all investing in the success of our common customers, and a bunch of expensive developer hours have been and are being spent on an emergency basis across your community trying to root cause and correct for a rather brutally abrupt and undocumented breaking change.
We don’t use the token for user information but to validate the zoom account id on account creation within our system. Requiring extra permissions for the marketplace app and another network call to check just the account id when registering a system level account seems like overkill. The token formats are in the docs as well.
in the Request Access Token section the example tokens are there and decode to
{
“ver”: “6”,
“clientId”: “<Client_ID>”,
“code”: “”,
“iss”: “urn:zoom:connect:clientid:<Client_ID>”,
“authenticationId”: “<Authentication_ID>”,
“userId”: “<User_ID>”,
“groupNumber”: 0,
“aud”: “https://oauth.zoom.us”,
“accountId”: “<Account_ID>”,
“nbf”: 1580146993,
“exp”: 1580150593,
“tokenType”: “access_token”,
“iat”: 1580146993,
“jti”: “”,
“toleranceId”: 25
}
I agree with the above comment that changes like this should be communicated to the development community so we can prepare. I don’t see anything in that oauth support document that says the token formats are subject to significant changes.
Thanks for your feedback. I agree with your points and will bring this up to the team. 
-Tommy
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.