cometchat-security
Ground truth: every REST shape here is FETCHED from the live docs —
{DOCS_BASE}/rest-api/auth-tokens,/rest-api/roles,/rest-api/rbac-overview,/rest-api/users,/rest-api/group-members(DOCS_BASE = https://www.cometchat.com/docs; append.mdfor the raw twin). CometChat is NOT an identity provider — it does not do SAML/OIDC for your end users. "SSO with CometChat" means your IdP authenticates the user, then your server mints a CometChat auth token for that user's UID. Verify signatures against the docs; never invent an endpoint.
Use this skill when
Taking a CometChat integration through an enterprise security review: SSO with your IdP, role-based permissions, session revocation, multi-tenant isolation, or "make our chat secure/compliant to ship." Client-side login wiring itself lives in cometchat-<family>-core / -production; this skill owns the server + access-control model those depend on.
The auth model (get this right first)
Three credentials, three homes — mixing them up is the #1 security defect:
| Credential | Who holds it | Purpose |
|---|---|---|
| Auth Key | client, dev only | quick login(uid) in development; can mint a session for ANY user — never ship it |
| Auth token | client, per user | production login with a per-user token — the call is per family (web/Angular/Android/Flutter loginWithAuthToken(token), iOS login(authToken:), React Native login({ authToken })); tied to one UID; revocable |
| REST API Key | server only | mint tokens, manage users/roles; full power — never in a client |
Production login is always auth token, never the Auth Key. Detail + the per-framework client call: cometchat-<family>-production.
SSO / OIDC / SAML — through YOUR IdP
CometChat rides on the identity you already have. The flow is the same whether your IdP is Okta, Auth0, Cognito, Entra ID, Google Workspace, or your own: