# Meeting SDK Linux: onAuthenticationReturn ret=11 (AUTHRET\_JWTTOKENWRONG) with correct credentials

**URL:** <https://devforum.zoom.us/t/meeting-sdk-linux-onauthenticationreturn-ret-11-authret-jwttokenwrong-with-correct-credentials/147113>\
**Category:** Meeting SDK\
**Created:** [October 12, 2026, 2:29am UTC](https://devforum.zoom.us/t/meeting-sdk-linux-onauthenticationreturn-ret-11-authret-jwttokenwrong-with-correct-credentials/147113 "2026-10-12T02:29:19Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ilearning.classroom1](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/ilearning.classroom1/32/60224_2.png) [@ilearning.classroom1](https://devforum.zoom.us/u/ilearning.classroom1)\
**Post date:** [October 12, 2026, 2:29am UTC](https://devforum.zoom.us/t/meeting-sdk-linux-onauthenticationreturn-ret-11-authret-jwttokenwrong-with-correct-credentials/147113/1 "2026-10-12T02:29:19Z")

</div>

**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!

---

<div class="post-metadata">

**Author:** ![chunsiong.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/chunsiong.zoom/32/35488_2.png) [@chunsiong.zoom](https://devforum.zoom.us/u/chunsiong.zoom)\
**Post date:** [October 12, 2026, 3:51am UTC](https://devforum.zoom.us/t/meeting-sdk-linux-onauthenticationreturn-ret-11-authret-jwttokenwrong-with-correct-credentials/147113/2 "2026-10-12T03:51:33Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Daniel44](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/daniel44/32/77267_2.png) [@Daniel44](https://devforum.zoom.us/u/Daniel44)\
**Post date:** [October 12, 2026, 5:58pm UTC](https://devforum.zoom.us/t/meeting-sdk-linux-onauthenticationreturn-ret-11-authret-jwttokenwrong-with-correct-credentials/147113/3 "2026-10-12T17:58:45Z")

</div>

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.