Authentication models

Your users need an identity to use features that modify data, like chatting, commenting, reacting, and voting. (Reading is anonymous.) There are three ways to provide one — this page covers each and when to use it.

Your app’s API key is a separate identity, always present; this page is about the end user’s.

The three models

1 · We host your users

The simplest start. You have no user system of your own and don’t want to build one. We give you the user database — you register each user with their email or a display name, and we store them. Drop-in widgets mean no backend of your own. Your data is yours: export it anytime, no lock-in.

2 · You mint the identity

You already manage your own users. Your server makes one call to mint a token for a signed-in user. From then on, anyone using our widgets and components acts as exactly the identity you handed us. Your server stays the source of truth.

3 · Your identity provider

You use a third-party login — Auth0, Amazon Cognito, Firebase, Okta, Google, or any OIDC provider. Point us at it once, and the token your users already carry just works. No second login, no token-minting code.

In one line each

• We host your users — you don’t have a login system; we are it. Register users, we store them, widgets do the rest.
• You mint the identity — you have a login system; your server mints a user token for each user with a single call.
• Your identity provider — you use an off-the-shelf provider; configure it once and existing logins pass straight through.

How to choose

Answer one question: where do your users’ identities live today?

Your situation	Use	Effort
No user system yet	We host your users	Register a user, then join.
Your own login/user database	You mint the identity	One server call, then join.
Auth0 / Cognito / Firebase / Okta / Google / OIDC	Your identity provider	One config call, then join.

Note

Not sure yet? Start with we host your users — it needs no backend at all, and you can move to your own identity or a provider later without changing how rooms work. All three can run side by side in one app.

Read-only viewers

If part of your audience only needs to watch the conversation — a public liveblog or a watch-along feed — they can read room events with your application key alone, no user token required. Reads work anonymously; posting, reacting, and reporting need one of the three models above.

Pick your recipe

• Authentication using TalkLabs → — we host your users; register them and join a room.
• Authentication using my identities → — mint a token from your own backend, then join.
• Authentication using an identity provider → — wire up Auth0, Cognito, Firebase, Okta, or Google once.
• Join a room → · Listen for events →
• API reference → — every current endpoint with request examples and a live console.