> ## Documentation Index
> Fetch the complete documentation index at: https://docs.textql.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Module 1 · Zero Duplication: Per-Member Auth

> Goal: your existing warehouse security — row access policies, secure views, masking, grants — applies to every TextQL query, with nothing rebuilt and nothing duplicated. (~25 min)

**Goal:** your existing warehouse security — row access policies, secure views, masking, grants — applies to every TextQL query, with **nothing rebuilt and nothing duplicated**.

## 1.1 · Why this is the DBA's favorite module

The objection every DBA raises: *"I already maintain these permissions in Snowflake/Databricks — I am not maintaining a second copy in your tool."* Correct instinct. With **per-member authentication**, each TextQL member queries the warehouse *as themselves* — so the policies you already wrote are the policies that run. One connector, no policy translation, no second copy, and your warehouse audit log shows the real human on every query.

<table><tr><th>Warehouse</th><th>Mechanism</th></tr>
<tr><td>Snowflake</td><td>External OAuth (SSO, no popup), popup OAuth, or token exchange</td></tr>
<tr><td>Databricks</td><td>OAuth / identity federation (Unity Catalog row filters & column masks apply per user)</td></tr></table>

## 1.2 · Turn it on

**Do:** on the connector, select **Per-Member OAuth** and complete the warehouse-side setup (Snowflake: a security integration; Databricks: OAuth app / federation — the [**Connect Your Data**](/workshops/connect-your-data/overview) workshop has the field-by-field forms, and the [**Admin & Governance**](/workshops/admin-governance/overview) workshop covers the credential decision). Each member authenticates once — or silently via SSO token exchange.

## 1.3 · Watch your own policies work

As a member with a restricted warehouse role (pick a real one — a regional analyst, a masked-PII role):

```text Prompt theme={null}
What is [total amount] by [region] for [last quarter]? Then show me exactly which warehouse identity and role this query ran under.
```

<Check>
  **You'll see:** only the rows that member's warehouse role permits — the same result they'd get in a SQL client — because it IS their identity running the query. Protected columns come back masked if your masking policies say so. Nothing was configured in TextQL to make this happen.
</Check>

<Note>
  **The compliance money moment** — Open your **warehouse's** audit/query history: the query shows the actual user, their effective role, the executed SQL, and the objects touched. Your existing compliance tooling sees TextQL queries exactly like any other client's. Show this to your security team before they ask.
</Note>

## 1.4 · When per-member auth doesn't fit

* **The warehouse doesn't support it** (some on-prem / SaaS sources) → role-specific restricted credentials: one connector per persona, each with a narrow warehouse role. Never one broad shared credential across personas with materially different entitlements.
* **External users without warehouse accounts** (embedded, customer-facing) → tenant-bound sessions from a trusted backend + ontology guards (Module 3).
* **You need semantics on top anyway** — per-member auth enforces *access*; it doesn't make "revenue" mean the right thing. Governed definitions still come from the ontology either way.

### ✅ Checkpoint

* [ ] Per-member auth is on for at least one warehouse connector (or you've documented why it can't be)
* [ ] A restricted member's question returned only their permitted rows — verified live
* [ ] You found the query in the warehouse's own audit log under the member's identity