A sign-in provider holds some of the most sensitive personal information in your product: email addresses, password hashes, phone numbers for multi-factor codes, IP addresses and sign-in history. When an enterprise customer's questionnaire asks where personal information is stored and which companies can access it, the identity provider belongs in the answer alongside your database.
Everything below was checked against each vendor's own pages as at 1 October 2026. Vendors change prices, plans and regions, so check the linked pages again before you rely on them. This is general information, not legal advice.
The essentials in five lines
- Four of the six offer an Australian region for user data: Auth0, Cognito, Supabase Auth and Kinde.
- Firebase Authentication runs only from US data centres, and Clerk does not offer regional data residency.
- An Australian region changes where data rests, not which company controls it.
- At 1,000 to 50,000 monthly users, most of these cost little or nothing, so cost rarely decides the questionnaire answer.
- To keep sign-in onshore with WattleDB today, you run it yourself and issue JWTs that PostgREST verifies.
Who owns each provider, and is there an Australian region?
"Owner" here means the company you contract with and, where it differs, the parent. "Australian region" means the vendor's own documentation says user identity data can be stored in Australia.
| Provider | Who owns it | Australian region for user identity data |
|---|---|---|
| Auth0 | Part of Okta, Inc. since Okta completed the acquisition in May 2021. Okta, Inc. is incorporated in Delaware, US. | Yes. Public cloud tenants can use the AU locality, which controls the region where your data will be hosted. |
| Amazon Cognito | Amazon Web Services, part of Amazon.com, Inc., incorporated in Delaware, US. Australian accounts contract with Amazon Web Services Australia Pty Ltd. | Yes. User pool endpoints exist in Sydney (ap-southeast-2) and Melbourne (ap-southeast-4). |
| Firebase Authentication | Google LLC, part of Alphabet Inc., incorporated in Delaware, US. | No. Google says the Firebase Authentication service "is run only from US data centers". |
| Supabase Auth | Supabase, Inc. (reported as US-incorporated). Its current terms of service name SUPABASE PTE. LTD., a Singapore entity, as the contracting party, and are governed by California law. | Yes, through your project. Auth stores user data in a schema in your project's Postgres database, and projects can be created in Sydney (ap-southeast-2). |
| Clerk | Clerk, Inc., with a San Francisco address. Its terms are governed by Delaware law. | No. Clerk's security page says it does not offer regional data residency or region selection, and data is hosted on US infrastructure. |
| Kinde | Kinde Australia Pty Ltd (ACN 655 096 263). Its terms are governed by New South Wales law. | Yes. Sydney is one of five supported data regions. You choose it at sign-up and cannot change it later. |
Two details matter for a questionnaire. Kinde's sub-processor list names AWS for public cloud hosting, located in the region you select, so a Kinde Sydney tenant sits on AWS in Australia. And the Supabase contracting entity is in Singapore while the company behind the product is in the US, so name both if you are asked for the full chain. We have not traced the shareholders of every entity above; if your customer asks for an ultimate owner, ask the vendor in writing.
What an Australian region changes, and what it doesn't
An Australian region changes where the data rests. That can answer a data residency clause, and it usually cuts sign-in latency for Australian users.
It does not change which company controls the data. The US CLOUD Act added 18 U.S.C. §2713, which requires a provider served with US legal process to preserve or disclose data "within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States." For a provider that is a US company, or part of one, a Sydney region does not remove the data from that rule. Where a non-US contracting entity sits under a US company, or where an Australian vendor hosts on a US-owned cloud, whether US process could reach the data is a question about possession, custody or control for your lawyer, not something a region setting settles. No provider anywhere can promise immunity from every legal process; we cover the Australia–US agreement and its limits in CLOUD Act vs Privacy Act.
On the Australian side, APP 8.1 says that before you disclose personal information to an overseas recipient, you "must take such steps as are reasonable in the circumstances to ensure that the overseas recipient does not breach the APPs (other than APP 1) in relation to the information". Under section 16C you can then be accountable for what that recipient does. If your sign-in provider stores identity data only in the US, as Firebase Authentication and Clerk say they do, those rules are in play for every user record. The OAIC guidelines (paragraph 8.14) also describe when giving data to an overseas cloud provider only for storage, under tight contractual control, may be a "use" rather than a "disclosure". An identity provider usually does more than store: it checks passwords, sends emails and SMS, and logs sign-ins. Check with your adviser which position fits your arrangement.
What it costs at 1,000, 10,000 and 50,000 monthly active users
Prices are in US dollars as listed on each vendor's pricing page as at 1 October 2026, for email and social sign-in only. SMS, enterprise single sign-on and add-ons cost extra. We have not converted to AUD.
| Provider | 1,000 MAU | 10,000 MAU | 50,000 MAU | Basis |
|---|---|---|---|---|
| Auth0 | US$0 | US$0 | US$3,500 | Free plan covers up to 25,000 MAU. The 50,000 figure is B2C Essentials, from the per-user rates behind the pricing page's calculator. |
| Cognito | US$0 | US$0 | US$220 (Lite) or US$600 (Essentials) | 10,000 MAU free each month, then US$0.0055 per MAU (Lite) or US$0.015 per MAU (Essentials). |
| Firebase Authentication | US$0 | US$0 | US$0 | With Identity Platform, no cost up to 50,000 MAU, then US$0.0055 per MAU. Phone sign-in is billed per SMS. |
| Supabase Auth | US$0 or US$25 | US$0 or US$25 | US$0 or US$25 | Not sold on its own. Free includes 50,000 MAU, but free projects are paused after a week of inactivity. Pro starts at US$25 a month with 100,000 MAU. |
| Clerk | US$0 | US$0 | US$0 | Hobby includes 50,000 monthly retained users per app. Pro is US$25 a month (US$20 billed annually) with the same allowance. |
| Kinde | US$0 | US$0 | US$716.25 | Free includes 10,500 MAU. The 50,000 figure is Pro: US$25 plus 39,500 extra MAU at US$0.0175. |
Two counting differences matter. Clerk bills "monthly retained users", a user who returns at least a day after signing up, rather than every user who signs in. Kinde does not count users on paid subscriptions billed through Kinde. At these sizes the bill is small for most of the six, so cost rarely decides the questionnaire answer. Ownership and region usually do.
Keeping sign-in onshore today
WattleDB is managed PostgreSQL from RR Sols Pty Ltd, an Australian company with no foreign parent. Databases run on Binary Lane servers in Sydney, with backups held cross-state in Melbourne. WattleDB does not offer hosted sign-up or sign-in today; hosted Auth is in development. What it does provide now is an auto-generated REST API (PostgREST) that verifies JWTs and applies Row-Level Security, so you can run sign-in yourself and keep user records in your own database.
1. Run sign-in in your app or on your own server. Keep users in your own tables, hash passwords with a current algorithm such as Argon2id or bcrypt, and handle resets and multi-factor codes yourself. If that server runs on a US-owned cloud's Sydney region, the ownership question above applies to it too.
2. Issue a short-lived JWT signed with your database's JWT secret (console, REST API tab). Put the user id in sub, set role to authenticated, and add the claims your policies need. Keep the secret on the server.
import jwt from 'jsonwebtoken'
const token = jwt.sign(
{ sub: user.id, role: 'authenticated', tenant_id: user.tenantId },
process.env.WATTLEDB_JWT_SECRET,
{ expiresIn: '1h' })3. Let Row-Level Security read the claims. PostgREST verifies the token and runs the request as the authenticated role. Your policy reads the claims from the request:
alter table public.projects enable row level security;
create policy tenant_rows on public.projects
for all to authenticated
using (tenant_id = (current_setting('request.jwt.claims', true)::json ->> 'tenant_id')::uuid)
with check (tenant_id = (current_setting('request.jwt.claims', true)::json ->> 'tenant_id')::uuid);4. Query from the client with postgrest-js. The full supabase-js client does not work against WattleDB today; its query builder, @supabase/postgrest-js, does, with the token as a bearer header. The Supabase migration guide walks through the same steps.
The trade-off is real: you own password storage, resets, rate limiting and multi-factor codes. Your email and SMS providers also receive identity data, so list them in your answer.
A short questionnaire checklist
- Name the sign-in provider, the entity you contract with, its country of incorporation and its parent.
- State the region where user identity records are stored, and link the vendor's own page.
- List every sub-processor that touches identity data: hosting, email, SMS and support tools.
- Say whether any of that data is processed outside Australia, and on what APP 8 basis.
- Say whether any company in the chain is US-incorporated or has a US parent.
- Note whether the region can be changed later. Kinde's cannot.
- Describe where tokens are verified, which claims they carry, and that Row-Level Security enforces access in the database.
- Ask each vendor whether you can export users, including password hashes, if you leave.