Meeting SDK Linux: onAuthenticationReturn ret=11 (AUTHRET_JWTTOKENWRONG) with correct credentials

Meeting SDK
1

Meeting SDK Type and Version
Meeting SDK for Linux, version 7.1.5.4432

Description
I’m getting ret=11 from onAuthenticationReturn when trying to authenticate the Zoom Meeting SDK on Linux.

Setup:

  • App type: General App (User-managed) with Meeting SDK feature enabled
  • “Programmatic join use case” is turned ON
  • Using Development credentials (Client ID and Client Secret verified correct)
  • App is installed to the account
  • JWT generated per official docs: header {"alg":"HS256","typ":"JWT"}, payload {"appKey":"<client_id>","iat":<now>,"exp":<now+7200>,"tokenExp":<now+7200>}, signed with HMAC-SHA256 using Client Secret
  • Server time is correct (verified with date -u)
  • Also tried Production credentials, same result

The SDK initializes successfully (InitSDK returns success), JWT is generated, but SDKAuth always returns ret=11 in the callback.

Client ID: NA1KAcnRRvO3QNODbIDALw

Error?
onAuthenticationReturn returns ret=11 (AUTHRET_JWTTOKENWRONG).

Troubleshooting Routes

  • Client ID and Secret match exactly what’s in the Marketplace
  • Programmatic join is enabled in the app settings
  • JWT exp is within 2 hours (7200 seconds)
  • Server clock is accurate

How To Reproduce

  1. Authentication method: General App (User-managed) with Meeting SDK enabled, JWT generated with Client ID/Secret
  2. Error: ret=11 in onAuthenticationReturn
  3. Client: Linux Meeting SDK 7.1.5.4432

Is there something specific about General apps with Meeting SDK that I’m missing? Or is there a way to get more details on why the JWT is being rejected?

Thanks!

2

@ilearning.classroom1 I’ll PM you for more information

3

I’ve hit ret=11 with “correct” credentials before, and in my experience it’s almost never actually the key or secret — it’s a claim validation issue. Two things worth checking in order:

  1. iat in the future. The auth service is strict about this: if your machine’s clock is even slightly ahead (NTP drift, or rounding time() up), iat lands in the future and the JWT is rejected with AUTHRET_JWTTOKENWRONG. Set iat to now minus 60 seconds instead of exactly now, and double-check with date -u +%s right before generating. This fixed the exact same error for me on a Linux build.

  2. tokenExp vs exp. Make sure tokenExp is less than or equal to exp and both are within 7200s of iat. Some examples put tokenExp beyond exp, which the SDK rejects.

One more sanity check: confirm the Client ID/Secret you’re signing with are from the app where the Meeting SDK feature + “Programmatic join” are actually enabled. With a General App it’s easy to accidentally copy credentials from a different app in the dashboard. If the signature checks out (you can paste the token into a JWT debugger locally and inspect the payload), the problem is practically always the claims, not the signature.