references/auth-basics.md
## Authentication Overview
Catalyst provides built-in auth and user management. Auth types: Catalyst built-in, Zoho accounts, custom SSO.
---
## SDK Patterns
```javascript
const userMgmt = catalystApp.userManagement();
// Get current user (user-scoped SDK)
const currentUser = await userMgmt.getCurrentUser();
// Returns null for collaborators/admins — only works for registered app users
// Get all users (admin-scoped)
const users = await userMgmt.getAllUsers();
// Get a specific user
const user = await userMgmt.getUserDetails(USER_ID);
// Delete a user
await userMgmt.deleteUser(USER_ID);
// Register a new user (sends invite email)
const signupConfig = {
platform_type: 'web',
zaid: 'YOUR_ZAID'
};
const userConfig = {
email_id: 'newuser@example.com',
first_name: 'New',
last_name: 'User'
};
const newUser = await userMgmt.registerUser(signupConfig, userConfig);
```
---
## Initialization Scopes
| Scope | Init call | Use for |
|-------|-----------|---------|
| **User** (default) | `catalyst.initialize(req)` | `getCurrentUser()`, user-identity |
| **Admin** | `catalyst.initialize(req, { scope: 'admin' })` | DataStore CRUD, Stratus, ZCQL, Cache |
**Pattern for apps needing both auth and data:**
```javascript
// User-scope for identity
const userApp = catalyst.initialize(req);
const currentUser = await userApp.userManagement().getCurrentUser();
// Admin-scope for data
const adminApp = catalyst.initialize(req, { scope: 'admin' });
const dataStore = adminApp.datastore();
```
---
## Web SDK Auth (Client-Side)
### For Legacy Web Client Hosting
```javascript
// Sign up
await catalyst.auth.signUp({
first_name: firstName,
last_name: lastName,
email_id: email,
platform_type: 'web',
redirect_url: window.location.origin + '/app/index.html' // Legacy path
});
// Logout
catalyst.auth.signOut(window.location.origin + '/app/index.html');
```
### For Slate (Modern Frontend Hosting)
```javascript
// Sign up
await catalyst.auth.signUp({
first_name: firstName,
last_name: lastName,
email_id: email,
platform_type: 'web',
redirect_url: window.location.origin + '/' // Root path for Slate
});
// redirect_url must be "/" for Slate (root path)
catalyst.auth.signIn('login-container', {
redirect_url: '/'
});
// Logout
catalyst.auth.signOut(window.location.origin);
// ⚠️ Slate two-origin limitation:
// signOut() only clears the frontend cookie. The Catalyst backend session
// may persist because Slate and the backend run on different origins.
// The SDK provides no cross-domain logout API. Workaround: use a
// sessionStorage flag to return the UI to the login screen, and add an
// honest comment in your code that the backend session is not invalidated.
// Example workaround:
catalyst.auth.signOut(window.location.origin);
sessionStorage.setItem('signed_out', 'true');
// NOTE: backend session persists — no SDK API exists for cross-domain invalidation
```
**IMPORTANT:** Do NOT use `/app/` paths with Slate. Slate serves from root `/`, not `/app/`.
### Check if logged in
```javascript
try {
const result = await catalyst.auth.isUserAuthenticated();
// ⚠️ User is nested under result.content — NOT result directly
// result.content.email_id, result.content.user_id, result.content.first_name
// logged in
} catch (err) {
// not logged in (401)
}
```
**Embedded sign-in widget has no built-in signup flow.** `catalyst.auth.signIn("divId", config)` renders a login iframe only — there is no sign-up button inside it. For signup, build a custom form and call `catalyst.auth.signUp()`.
> ⚠️ **`public_signup` is OFF by default.** After enabling auth via MCP or console, `public_signup` is `false`. Any call to `catalyst.auth.signUp()` will silently fail for new users until you enable it: Console → Authentication → Settings → enable **Allow Public Signup**. There is no MCP tool to change this — must be done in the console.
---
## Finding ZAID Locally
While `catalyst serve` is running, ZAID is readable from the local init script:
```bash
curl http://localhost:3000/__catalyst/sdk/init.js | grep -o 'zaid:"[^"]*"'
```
This only works during local development — use the console for production ZAID: Console → Authentication → App Settings → Application ID.
---
## `credentials: 'include'` for fetch calls
When calling Catalyst functions from a web client, always add `credentials: 'include'`:
```javascript
const res = await fetch('/server/my_api/execute', {
method: 'POST',
credentials: 'include', // ← Required — without this, auth cookies are NOT forwarded
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ key: 'value' })
});
```
`catalyst.server.callAdvancedIO()` handles this automatically.
---
## DataStore App User Permissions
By default, App Users have **Read-only** access. For Insert/Update/Delete:
1. **Console (recommended):** Data Store → {Table} → Permissions → App User → enable all operations
2. **SDK:** Use `catalyst.initialize(req, { scope: 'admin' })` for data operations
---
## First App User — Create One Before Testing Auth
**Every new Catalyst project has zero app users.** The console admin account is a project collaborator, not an app user. `getCurrentUser()` returns `null` for collaborators — auth will appear broken until at least one app user exists.
### Step 1 — Get the App User role_id
Call `CatalystbyZoho_List_All_Roles`. Every project has exactly two auto-created roles. Find the entry with `"is_default": true` — that is the App User role. Copy its `role_id` (it is project-specific and differs per project).
### Step 2 — Add the first app user via MCP
Call `CatalystbyZoho_Add_User` with:
- `platform_type`: `"web"`
- `redirect_url`: your Slate URL (e.g. `https://your-app.onslate.com/`)
- `user_details.email_id`, `user_details.first_name`, `user_details.last_name`
- `user_details.role_id`: value from Step 1 — **required**, omitting it is a validation error
> The user receives an invite email and must click the confirmation link before `isUserAuthenticated()` will return a valid session. Pending-confirmation accounts are rejected at login.
---
## Common Errors
### `getCurrentUser()` returns `null` — collaborator vs app user
Collaborators/project admins are NOT registered app users. `getCurrentUser()` returns `null` for them.
```javascript
const currentUser = await userApp.userManagement().getCurrentUser();
if (!currentUser || !currentUser.user_id) {
// Collaborator/admin — fall back to admin-scope lookup
}
```
### `Authorization` header is `undefined`
The Catalyst gateway strips the `Authorization` header after validation and injects `x-zc-*` internal headers. Do not read `req.headers['authorization']` — it will be `undefined`. The SDK reads `x-zc-*` headers automatically via `catalyst.initialize(req)`.
### Session cookies don't cross Catalyst service domains
Functions (`*.catalystserverless.com`), AppSail (`*.catalystappsail.com`), and Slate (`*.onslate.com`) live on separate domains — a session cookie set by a login function will not authenticate requests to an AppSail or Slate app. Host the auth flow on the same origin as the app, use domain mapping to unify domains, or use server-side token exchange. (See the catalyst-appsail skill for the full domain table.)
### Development environment user limit
The Development environment allows a **maximum of 25 app users**. Plan Production deployment for anything beyond that — after deploying to production, there is no user-count restriction.
### Custom session setup gotchas
- If multiple functions share a session cookie, the signing secret (e.g. `SESSION_SECRET`) must be **identical** across all of them — a mismatched secret in one function invalidates sessions it didn't create.
- For external/portal auth flows, the accounts portal base URL is configured via SDK initialization options (`accountsPortalBaseURL` / `setAccountsPortalBaseURL('https://accounts.zohoportal.com')`) — configure it there rather than relying on ambient environment variables.
### `Authorization: Bearer` intercepted before handler
Catalyst validates `Authorization: Bearer <token>` at the gateway level — even for `authentication: optional` endpoints. Don't use `Authorization: Bearer` for custom app-level secrets.
```
# Use a non-standard header for custom auth:
X-My-App-Token: <secret>
```
### `signOut()` crashes
`catalyst.auth.signOut()` requires a redirect URL argument.
```javascript
// Correct for Slate:
catalyst.auth.signOut(window.location.origin);
// Correct for legacy Web Client:
catalyst.auth.signOut(window.location.origin + '/app/index.html');
```
### `signOut()` appears to work but user can still access protected routes
Slate two-origin: `signOut()` clears frontend cookie only; backend session persists. Use a sessionStorage flag + redirect for UI-side logout. No full cross-domain logout is available in the current SDK.
---
## Embedded Auth on Slate (Non-Legacy Hosting)
### Redirect URL Patterns
For **Slate apps**, authentication redirects must NOT include `/app/` path:
```javascript
// ✅ CORRECT for Slate
// ZAID: Console → Authentication → App Settings → Application ID (no MCP tool returns it)
await catalyst.auth.signUp({
first_name: firstName,
last_name: lastName,
email_id: email,
platform_type: 'web',
// zaid: optional in Slate embedded flow (injected via /__catalyst/sdk/init.js)
// required if you are running outside of catalyst serve or in a legacy setup
zaid: 'YOUR_ZAID',
redirect_url: window.location.origin + '/' // Root path
});
// redirect_url must be "/" for Slate (root path)
catalyst.auth.signIn('login-container', {
redirect_url: '/'
});
/* Required CSS — Catalyst injects an iframe with no default height; it renders invisible without this */
/* #login-container iframe { width: 100% !important; height: 500px !important; border: none !important; } */
```
```javascript
// ❌ INCORRECT for Slate (legacy pattern)
redirect_url: window.location.origin + '/app/index.html' // 404 on Slate
```
### SDK Initialization Order (Critical)
Two scripts are required, in this exact order:
```html
<!-- 1. Main Catalyst CDN bundle — MUST come first; init.js depends on globals it sets -->
<script src="https://static.zohocdn.com/catalyst/sdk/js/4.6.1/catalystWebSDK.js"></script>
<!-- 2. Project-specific init -->
<script src="/__catalyst/sdk/init.js"></script>
```
Without `catalystWebSDK.js`, `init.js` crashes immediately with `Uncaught ReferenceError: I18N is not defined` and `window.catalyst` is never set.
The `/__catalyst/sdk/init.js` script must load BEFORE your app calls `catalyst.auth` methods. Poll for SDK availability:
```javascript
useEffect(() => {
const checkSDK = setInterval(() => {
const sdk = (window as any).catalyst;
if (sdk?.auth?.signIn) {
clearInterval(checkSDK);
sdk.auth.signIn('login-container', {
redirect_url: '/'
});
}
}, 100);
return () => clearInterval(checkSDK);
}, []);
```
### Common Error: PATTERN_NOT_MATCHED
If you see this error after authentication, the SDK is redirecting to a path that doesn't exist in your router. Common causes:
1. **SDK redirecting to `/app/`** → Add `/app/*` catch-all route (see catalyst-slate skill)
2. **`client-package.json` has `redirect_url` without leading `/`** → Change to `"/"`
3. **Console Authentication Type still set to Hosted** → Change to Embedded
references/auth-thirdparty.md
# Third-Party Authentication
Catalyst supports three authentication strategies. Native types (Hosted and Embedded) are fully managed by Catalyst. Third-party auth delegates validation to an external service — Catalyst provides the token bridge.
| Type | Who validates the user | Catalyst handles endpoint security? |
|------|----------------------|--------------------------------------|
| **Hosted** | Catalyst | ✅ Yes |
| **Embedded** | Catalyst | ✅ Yes |
| **Third-party** | Your chosen IdP (Okta, Duo, Auth0, etc.) | ❌ No — you are responsible |
> ⚠️ When using third-party authentication, **Catalyst does not secure your application endpoints**. The security of your app depends entirely on the third-party service you choose.
---
## How Third-Party Auth Works (7-Step Flow)
1. User submits credentials → forwarded to the third-party IdP
2. IdP validates and stores user details in its own database
3. Validated user details returned to your Catalyst client app
4. Client calls your Catalyst **authentication function** with those details
5. Function runs `generateCustomToken()` → returns a custom server token
6. Client passes the token to `catalyst.auth.signinWithJwt()` → generates a JWT
7. User is logged in; JWT stored in browser cookie for the session (valid 1 hour)
> ℹ️ The custom server token must be regenerated on **every login** — it is not reusable across sessions.
---
## Prerequisites
1. **Enable Public Signup** — required before third-party auth can be set up. Console → Authentication → Public Signup → Enable.
2. **Complete the third-party IdP setup first** — Catalyst does not handle the external IdP configuration. Set up your app in the IdP's developer console before touching Catalyst.
3. **Complete the Console wizard** — Console → Cloud Scale → Authentication → Third-party → Set Up → follow the wizard → click **Finish**. This is what activates third-party auth in Catalyst's platform state. MCP `Enable_Authentication` with `auth_type: "third_party"` alone may not be sufficient — if `generateCustomToken()` returns `INTERNAL_SERVER_ERROR` after using MCP, complete the Console wizard to finish activation.
---
## Server-Side: Generate Custom Token (Node.js)
> ⚠️ **Use a Catalyst Function (Advanced I/O), not AppSail.** The official tutorial runs `generateCustomToken()` inside an Advanced I/O function. When called from AppSail on an unauthenticated request (no Catalyst session cookie yet), Catalyst may create the user in User Management but return `INTERNAL_SERVER_ERROR` on the token generation step — because AppSail's `catalyst.initialize(req)` on a cookieless request lacks the execution credentials that a function context provides automatically. If you see users appearing in User Management but `generateCustomToken` still returns 500, this is the cause.
Add a dedicated Advanced I/O function that the client calls after the IdP validates the user:
```javascript
// functions/auth_token/index.js — Advanced I/O function
'use strict';
const catalyst = require('zcatalyst-sdk-node');
const express = require('express');
const app = express();
app.use(express.json());
app.post('/gettoken', async (req, res) => {
try {
const { email_id, first_name, last_name } = req.body; // from IdP
const catalystApp = catalyst.initialize(req); // function context — admin by default
const tokenObj = await catalystApp.userManagement().generateCustomToken({
type: 'web',
user_details: {
email_id, // required
first_name, // required
last_name, // required
org_id: '', // optional
phone_number: '', // optional
country_code: '', // optional
role_name: '' // optional — assigns a role on first signup only
}
});
res.status(200).json(tokenObj);
} catch (error) {
res.status(500).json({ error: error?.message || String(error) });
}
});
module.exports = app;
```
> ℹ️ `org_id` and `role_name` are optional. On **first login** (signup), `role_name` assigns the user a role in Catalyst User Management. The token endpoint URL from Slate must be absolute: `https://<project>.catalystserverless.com/server/<fn>/execute`.
---
## Client-Side: Sign In With JWT (Web SDK)
After receiving the custom token from your function, pass it to `signinWithJwt`:
```html
<!-- Load Web SDK — /__catalyst/sdk/init.js works on ALL Catalyst-hosted frontends including Slate -->
<script src="https://static.zohocdn.com/catalyst/sdk/js/4.6.1/catalystWebSDK.js"></script>
<script src="/__catalyst/sdk/init.js"></script>
<script>
catalyst.auth.signinWithJwt(getCustomTokenCallback);
function getCustomTokenCallback() {
// Token endpoint must be a Catalyst Function (Advanced I/O), not AppSail.
// From Slate, always use the absolute Functions URL:
return fetch('https://<project>.catalystserverless.com/server/<auth_fn>/execute/gettoken', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ /* IdP user details */ })
})
.then(resp => resp.json())
.then(data => {
return {
client_id: 'YOUR_CLIENT_ID',
scopes: 'ZOHOCATALYST.tables.rows.ALL,ZOHOCATALYST.cache.READ',
jwt_token: data.token
};
});
}
</script>
```
> ⚠️ **Always use absolute URLs from Slate.** Slate (`*.onslate.com`) and Functions (`*.catalystserverless.com`) are on separate domains. Relative URLs (`/server/...`) will 404 from Slate — always use the full absolute URL for the token endpoint.
> ℹ️ `/__catalyst/sdk/init.js` is served by Catalyst's platform on all hosted frontends — it works correctly on both Slate (`*.onslate.com`) and legacy web client hosting.
> ⚠️ The `/__catalyst/sdk/init.js` script must load **before** any `catalyst.auth` calls. If using React/Vue, poll for SDK availability before calling `signinWithJwt` (same pattern as embedded login — see `auth-basics.md`).
---
## Social Logins (Google, Facebook, LinkedIn, Microsoft)
Social logins are supported **within native auth types** (Hosted and Embedded) — configured entirely from the Catalyst Console with no custom code.
> ⚠️ If you are using **Third-party Authentication**, social login Console configuration does not apply — you must implement the OAuth flow yourself using the IdP's SDK.
### Console Setup (for Hosted / Embedded auth types only)
1. Get **Client ID** and **Client Secret** from each social provider's developer console
2. Console → Cloud Scale → Authentication → your auth type → Social Logins
3. Click the provider, enter Client ID + Client Secret, click **Enable**
### Provider-specific setup
| Provider | Where to get credentials |
|----------|--------------------------|
| **Google** | [Google Cloud Console](https://console.cloud.google.com) → APIs & Services → Credentials → OAuth 2.0 Client IDs → Web application |
| **Facebook** | [Meta for Developers](https://developers.facebook.com) → My Apps → create app |
| **LinkedIn** | [LinkedIn Developer Portal](https://developer.linkedin.com) → My Apps → create app (requires a LinkedIn Company Page) |
| **Microsoft** | [Azure Portal](https://portal.azure.com) → App registrations |
> ⚠️ **Production reconfiguration required.** Social logins configured in Development use your dev domain. After promoting to Production, you must reconfigure each social login with the production app domain — or all social logins will silently fail in production.
---
## Common Errors
| Error | Cause | Fix |
|-------|-------|-----|
| Third-party auth setup blocked | Public Signup not enabled | Console → Authentication → Public Signup → Enable (mandatory prerequisite) |
| `generateCustomToken()` returns `INTERNAL_SERVER_ERROR` even when user IS created in User Management | Called from AppSail on an unauthenticated request — `catalyst.initialize(req)` with no Catalyst session cookie lacks the execution credentials a Function context provides | Move `generateCustomToken()` to a Catalyst Advanced I/O Function; call that function URL from the client instead of an AppSail route |
| `generateCustomToken()` returns `INTERNAL_SERVER_ERROR` and Console wizard not completed | `Enable_Authentication` MCP call alone may not be sufficient — wizard "Finish" is what activates token generation | Complete the Console wizard: Console → Authentication → Third-party → Set Up → click **Finish** |
| `generateCustomToken()` fails with missing field error | `email_id`, `first_name`, or `last_name` missing from `user_details` | All three are required fields; `org_id`, `phone_number`, `country_code`, `role_name` are optional |
| `signinWithJwt` callback gets 404 on function fetch | Relative URL `/server/<fn>/execute` used from Slate — Slate and Functions are on different domains | Use absolute URL: `https://<project>.catalystserverless.com/server/<fn>/execute/gettoken` |
| `signinWithJwt` callback never fires | `/__catalyst/sdk/init.js` not loaded, or called before SDK is ready | Add the init script; for SPA frameworks, poll for `window.catalyst?.auth?.signinWithJwt` before calling |
| User not appearing in User Management after first login | `generateCustomToken()` was not called on first login (signup path skipped) | The token must be generated on every login — first login triggers the signup and adds user to User Management |
| Social logins silently fail after prod deploy | Social login still configured with dev domain | Reconfigure each social login in the Production environment with the production app domain |
| Social login config option not visible | Using Third-party Authentication type — Console social login config only works with Hosted/Embedded | Switch to Hosted or Embedded auth, or implement the social OAuth flow manually |
references/connections.md
## Overview
Connections manages OAuth2 tokens (and other auth types) for third-party service integrations. It auto-handles token refresh, so you never write refresh logic.
**Built-in Default Services (25+ pre-configured):**
- **Zoho services**: All Zoho products (CRM, Desk, Books, Projects, etc.)
- **Third-party services**: Google, MailChimp, Dropbox, DocuSign, Adobe Sign, GoToMeeting
**Custom Service (manual setup required):**
- Any OAuth2, API Key, or Basic Auth provider not in the default list (e.g., GitHub, Slack, HubSpot, Salesforce, Stripe)
- You provide: Client ID/Secret, Authorization URL, Token URL, scopes
---
## Using a Connection in a Function
```javascript
const connection = catalystApp.connection();
// Get a connector by name (configured in Console → Connections)
const connector = connection.getConnector('ZohoCRM');
// Get a valid access token (auto-refreshes if expired)
const tokenData = await connector.getAccessToken();
const accessToken = tokenData.access_token;
// Use the token to call the external API
const response = await fetch('https://www.zohoapis.com/crm/v3/Deals', {
headers: {
'Authorization': `Zoho-oauthtoken ${accessToken}`,
'Content-Type': 'application/json'
}
});
const data = await response.json();
```
---
## Setup in Console
1. Console → Connections → Create Connection
2. Select service type (Zoho, Google, or Custom OAuth2)
3. Provide Client ID / Client Secret
4. Authorize the connection (OAuth consent flow)
5. Set connection name (used as string arg to `getConnector()`)
---
## Custom OAuth2 Providers
For services not in the built-in list:
1. Choose "Custom OAuth2" connection type
2. Provide Authorization URL, Token URL, Scope
3. Complete the OAuth consent flow
---
## Pricing
Connections is a free feature — no additional cost per token fetch.
## Common Errors
| Error | Cause | Fix |
|-------|-------|-----|
| `Connection not found` | Connection ID wrong or not yet authorized by user | Confirm the connection name in the Connections console and verify the user has completed the OAuth grant |
| `Token refresh failed` | OAuth app credentials rotated or revoked by third-party | Re-authenticate the connection from the Connections console |
| `Scope not authorized` | Required OAuth scope was not included during connection setup | Delete and recreate the connection with the correct scopes |
| `Connection is inactive` | Connection was manually disabled or expired | Re-enable or reconnect from Catalyst Console → Connections |
SKILL.md
---
name: catalyst-authentication
description: "Catalyst Authentication — user login/signup, ZAID, Web SDK auth flows, OAuth token management via Connections, third-party authentication (Okta, Auth0, Duo, custom IdP), social logins (Google, Facebook, LinkedIn, Microsoft), generateCustomToken, signinWithJwt. Trigger on 'authentication', 'login', 'signup', 'getCurrentUser', 'ZAID', 'isUserAuthenticated', 'signOut', 'Connections', 'getAccessToken', 'third-party auth', 'social login', 'Google login', 'signinWithJwt', or 'generateCustomToken'. You MUST load this skill whenever implementing user login or protecting data — ZAID differs between Development and Production and is the #1 cause of auth failures after environment promotion. For Security Rules (function invocation control), route to catalyst-functions."
metadata:
version: "2.1.1"
---
## 🚦 Local auth requires plain `catalyst serve`
Auth works locally only when served through `catalyst serve`. NEVER use the native dev server (`npm run dev`, `vite`, `next dev`, `ng serve`, etc.) for auth development — the Catalyst auth middleware, cookie injection, and `/__catalyst/sdk/init.js` are only available through `catalyst serve`.
## How It Works
1. **Identify flow type** — Hosted login (redirect to Catalyst login page), embedded login (custom UI), or backend `getCurrentUser` check.
2. **Load `references/auth-basics.md`** — for signup/login flows, ZAID gotcha, hosted vs embedded login, and common auth errors.
3. **ZAID warning** — ZAID differs between Development and Production. This is the #1 auth issue in production. Always verify the environment.
4. **Security Rules** — If the query involves controlling who can invoke a function, route to `catalyst-functions` skill and its `references/functions-basics.md` Security Rules section. Security Rules has two parameters: (a) **`methods`** — which HTTP methods (GET/POST/PUT/DELETE/PATCH) are enabled for the function (removing a method blocks that verb entirely), and (b) **`authentication`** — a single binary flag (`optional` = public, `required` = authenticated users only) applied **function-wide, not per-method**. For role-based data access control, route to DataStore Scopes and Permissions (Console → Table → Scopes and Permissions).
5. **OAuth / Connections** — Load `references/connections.md` for external API OAuth token management (Zoho or third-party).
6. **Third-party auth / social logins** — If the query involves Okta, Auth0, Duo, custom IdP, Google/Facebook/LinkedIn/Microsoft login, `generateCustomToken`, or `signinWithJwt`, load `references/auth-thirdparty.md`.
## Security Checklist
- **ZAID is environment-specific.** The Development ZAID is different from the Production ZAID. Social logins (Google, Facebook, LinkedIn, Microsoft) configured in Development MUST be reconfigured with the Production ZAID and production app domain before going live — using the wrong ZAID causes all social logins to silently fail in production.
- **DataStore permissions are separate from function-level auth.** Requiring authentication in Security Rules only controls who can call the function. App User table permissions (Console → Table → Scopes and Permissions) separately control which DataStore operations authenticated users can perform.
## Triggers
Use this skill for: "authentication", "user management", "login", "signup", `getCurrentUser`, "ZAID", `registerUser`, `isUserAuthenticated`, `signOut`, "cross-domain logout", "hosted login", "embedded login", "Connections", "OAuth token", `getConnector`, `getAccessToken`, "Security Rules", "App User", "credentials include", "auth redirect", "third-party auth", "third-party authentication", "social login", "Google login", "Facebook login", "LinkedIn login", "Microsoft login", `signinWithJwt`, `generateCustomToken`, "Okta", "Auth0", "Duo", "custom IdP".
## References
| Reference | Load when the query is about… |
|-----------|-------------------------------|
| `references/auth-basics.md` | User signup/login, getCurrentUser, Web SDK auth flows, ZAID gotcha, hosted vs embedded login, common auth errors |
| `references/auth-thirdparty.md` | Third-party auth services (Okta, Auth0, Duo), social logins (Google/Facebook/LinkedIn/Microsoft), `generateCustomToken`, `signinWithJwt`, token flow, console setup |
| `catalyst-functions` skill | Security Rules — function invocation control (`methods`, `authentication: optional/required`) |
| `references/connections.md` | OAuth token management for external APIs — getConnector, getAccessToken, Zoho and third-party service connections |