Moving off Auth0 or Clerk to an EU-resident identity provider

2026-08-29T00:00:00+00:00

Moving off Auth0 or Clerk to an EU-resident identity provider</h1>
The conversation usually starts when somebody in legal or security asks where your end users' identity data lives, and "we selected the Frankfurt region" turns out not to be the answer they were after.</p>
A US-headquartered provider can be compelled under US law to hand over data it controls, and the location of the disks isn't what decides that. It's a question about control, which an availability-zone dropdown doesn't answer. There's a second question worth putting to any vendor including us: your region setting governs the user store, so what governs the configuration, the admin console, the audit records, the support tooling? Users in Frankfurt and a control surface somewhere else is a common shape, and most vendors will tell you which they have if you ask.</p>

Where the data actually sits</h2>

Our data plane holds end-user identity (user records, sessions, refresh tokens, magic-link attempts, TOTP enrolments) and serves every end-user request without a call through the control-plane backend. That covers sign in, verify, refresh, log out, token exchange and JWKS.</p>

The auth control plane is the configuration source of truth: apps, redirect URIs, signup toggles, mailer config, branding, per-app signing-key records, the operator audit trail. It isn't the system of record for end-user identity.</p>

Since anyone can claim to have separated their services, here is what actually holds the line:</p>

cp_auth_control</code> and cp_auth_data</code> are separate databases, owned by separate Postgres roles.</li>
Where the data plane reads control-plane configuration it connects as a third role, cp_auth_data_reader</code>, which holds column-scoped grants on four named tables and nothing else. Not table-wide, not schema-wide: it can read apps(id, project_id, slug, status, signup_enabled)</code>, for instance, and not the client_secret_hash</code> sitting in the same row.</li>
Where those grants do cover secret material, it's ciphertext. The reader can select an app's wrapped signing key, because signing tokens is the data plane's job, but the key that unwraps it is not in that database.</li>
Connection pools are phantom-typed by plane in Rust, so a store that needs the control-plane pool will not accept the data-plane one. Wiring the wrong pool into the wrong service fails to compile rather than failing at runtime against the wrong database.</li>

The control-plane backend stays off the data path. An operator viewing users in the dashboard has their browser call the data plane's admin API directly, cross-origin, with a short-lived project-scoped token that the control plane exists to mint.</li>
</ul>
That column-scoped grant is a direct read of the control-plane database, so the split isn't a claim that the two databases never touch. What it buys is that the control-plane service is never in the request path and never holds end-user records.</p>
Operator identity is the other thing to be clear about. Your team's admin accounts, their sessions and their MFA enrolments all live in the control plane. The claim on this page is about end-user identity specifically.</p>
On the hosted plan today both planes run in our infrastructure, so the split is about system-of-record and blast radius rather than about your users' data never reaching our network. The data plane is the piece built to be deployed onto your own infrastructure, which is something we set up with you rather than a download.</p>
Our own deployment sends mail through a relay we run, on Postgres and Redis we run, rather than through third-party APIs for either. The site you're reading loads no third-party CDN, font or analytics script, which you can check from your devtools right now.</p>
The migration is mostly OIDC</h2>
We're an OpenID Connect provider: discovery, JWKS, authorization code flow with PKCE, confidential and public clients. One limit to know before you plan around it: a public client can only register loopback redirect URIs today, so a standalone browser SPA on a real domain isn't one yet. Browser integrations go through the Next.js SDK's server routes instead.</p>
/v1/auth/{project}/apps/{app}/.well-known/openid-configuration</span></span>
/v1/auth/{project}/apps/{app}/.well-known/jwks.json</span></span>
/v1/auth/{project}/apps/{app}/authorize</span></span>
/v1/auth/{project}/apps/{app}/token</span></span>
/v1/auth/{project}/apps/{app}/userinfo</span></span></code></pre>
If your app reaches Auth0 through a generic OIDC client, the issuer URL and a client ID and secret are the minimum protocol-level changes, but claim mapping, scopes, logout behaviour and anything built against a vendor management API won't come across for free. Stock Auth.js v5 completes the whole flow against us, discovery through session, with no platform-specific code in your app.</p>
Clerk is a different shape of job because its drop-in React components are the integration. We ship a Next.js App Router SDK with the equivalent pieces (AuthProvider</code>, SignIn</code>, SignUp</code>, SignedIn</code>, SignedOut</code>, useUser</code>), plus a headless entry point for your own UI and a server module for route handlers and middleware. Budget it as a port.</p>
Password hashes can't come across at all, because there's nowhere to put them: our users table has no password column, by design</a>. Existing accounts import by email and go passwordless on their next sign-in. Decide that before the cutover, and tell your users sign-in has changed before they find out at the login screen.</p>
The one thing we don't do</h2>
Social login. No "Sign in with Google", and it isn't a gap we're working through: it's a decision recorded in an architecture decision record, and reversing it would take another one rather than a sprint. The reasoning is here</a>. If you run a consumer product where one-click signup drives conversion, that alone should disqualify us.</p>
What's next</h2>
Web is what we support today, and native apps are the next thing we're taking on. Custom-scheme redirects carry storage and credential questions we want to answer properly rather than quickly, so they're a deliberate next step instead of an oversight. Dynamic client registration is on the same list; for now an operator configures clients, which at the team sizes we're working with hasn't been anyone's bottleneck.</p>
Worth knowing before you plan a cutover: none of this has to be a big bang. There's a bulk import on the admin API, 500 users per batch, idempotent on project and email so you can re-run it without duplicating anyone. It preserves the provider and provider user ID each account came from, so an account imported from Auth0 still knows it was an Auth0 account. Paste a batch into the dashboard or curl it. Most teams run both systems side by side and move cohorts across at whatever pace they want, rather than picking a weekend and hoping.</p>
On certifications</h2>
Worth saying plainly, since it tends to come up early in a security review: as of August 2026 we hold no certifications and no audit is under way. Not ISO 27001, not SOC 2. At our size those follow the first customers who require them, and we'd rather tell you that than imply a posture we haven't earned. If it's a hard gate for you, say so early and we'll talk about what it would take.</p>
If you're a European B2B product, an internal tool, or selling into public-sector or regulated buyers, the trade is that you give up social login and get an identity provider whose answer to "where does the data live" is structural instead of regional. Google sign-in is the one thing that isn't coming. Everything else is a date, so it's worth asking where we are on it.</p>
Timonier</a> is EU-resident authentication with a self-hostable data plane. Start with the Next.js quickstart</a>, or email hello@timonier.eu about the data plane on your own infrastructure.</em></p>

Passwordless sign-in without a password table

2026-08-29T00:00:00+00:00

Passwordless sign-in without a password table</h1>

Here is every column in our users</code> table:</p>

id                        uuid        </span>primary key</span></span>
project_id                uuid        </span>not null</span></span>
email                     citext      </span>not null</span></span>
name                      text</span></span>
created_at                </span>timestamptz not null</span></span>
updated_at                </span>timestamptz not null</span></span>
last_sign_in_at           </span>timestamptz</span></span>
banned_at                 </span>timestamptz</span></span>
external_provider         </span>text</span></span>
external_provider_user_id </span>text</span></span>
unique</span> (project_id, email)</span></span></code></pre>
No password_hash</code>, no salt</code>, no password_reset_token</code>, no failed_login_count</code>. Argon2 shows up in exactly one place and it's hashing OIDC client secrets, which are machine credentials and a different problem.</p>
Dropping the column is the easy part.</p>
One request, two credentials</h2>
A sign-in request generates two forms of the same credential: a token of 32 random bytes, base64url, which goes into the emailed link, and a six-digit code for when that link opens in the wrong browser on someone's phone. Both are hashed before storage.</p>
They have to die together. Two forms of one credential, not two credentials. Store them independently and you've built a system where an intercepted link still works after the user has already signed in with the code.</p>
The token is stored as a keyed BLAKE3 hash, with a ten-minute TTL. Configure it outside one to thirty minutes and the process refuses to boot rather than clamping quietly. Hashing something with a ten-minute life looks like theatre until you notice that ten minutes is the expiry and not the retention: expired rows sit there until cleanup runs, so a snapshot taken at an awkward moment holds live credentials for everyone who was mid-sign-in. The likelier exposure was never the database anyway. It's a log line, an error report with the row attached, a support tool that renders a table.</p>
Keys are per-credential-class and the process won't boot unless all six are byte-distinct: the master key, the magic-link key, the refresh-token key, the authorization-code key, the hosted-login key and the recovery-code key. That check is there because reusing one key across classes is what happens during a rushed deployment and is invisible afterwards.</p>
Single-use, enforced twice</h2>
In Redis it's one Lua script: fetch the presented form, compare its hash against the stored one, and on a match DEL</code> both the token key and the code key in the same body, so redeeming either kills the other.</p>
The companion write is also a single Lua body rather than MULTI</code>/EXEC</code>, and the reason is specific to that operation: it's a conditional two-key set whose EXISTS</code> predicates aren't all-or-nothing across a multiplexed connection, so a partial outcome leaves one form live and the other missing.</p>
Postgres carries the second guard, a conditional update inside the completion transaction:</p>
update</span> end_user_sign_in_attempts</span></span>
   set status =</span> 'complete'</span></span>
 where</span> id </span>=</span> $</span>1</span></span>
   and status =</span> 'needs_first_factor'</span></span></code></pre>
rows_affected()</code> of 0 means somebody got there first, so the transaction rolls back and returns AlreadyComplete</code>. What matters is that there's no SELECT</code> to check the status before the UPDATE</code>; read-then-check-then-write leaves a window exactly wide enough for a double-click on a slow connection. TOTP replay and recovery-code consume use the same conditional shape. Refresh rotation does read the row first, because reuse detection has to know that a presented token was already spent; the conditional update sits behind that as the race backstop.</p>
Six digits is twenty bits</h2>
A six-digit code carries about 20 bits of entropy, which on its own is guessable. It survives because five attempts per sign-in attempt is the cap and the sixth submission moves the whole attempt to failed</code>, so the code you were attacking stops existing.</p>
Rate-limit counters in Redis sit around that:</p>
Limit</th> Keyed on</th></tr></thead>

Send rate, per minute and per hour</td> app + email address</td></tr>
Send rate, per hour</td> app + client IP</td></tr>
Second-factor attempts, per attempt</td> the sign-in attempt</td></tr>
Second-factor attempts, per user</td> user + app</td></tr>
</tbody></table>
The email buckets key on the address so flooding one mailbox stays bounded regardless of how many IPs you have, and the IP bucket keys on the client address so enumerating many addresses from one host stays bounded regardless of how many mailboxes you try. Neither covers both attacks alone.</p>
Every step of a sign-in runs whether or not the account exists. The three rate-limit counters are charged before anything is looked up, both credentials are generated and hashed before we know whether there's a user to send them to, and the attempt row and the Redis write happen either way. Only at the end does the mailer get a Deliver</code> or a Skip</code>, and both spawn and return without being awaited. Skipping the work for unknown addresses makes the response measurably faster for them, which is an enumeration oracle, and it's what you get by writing the function the obvious way with an early return on "user not found". Two tests assert that the known and unknown branches produce an identical sequence of calls.</p>
A bypass between two endpoints</h2>
Sign-in and sign-up are separate endpoints and TOTP is a second factor on sign-in, so the obvious implementation gates the second factor on the sign-in endpoint.</p>
But /sign-up</code> upserts on (project_id, email)</code>. A user who already exists and has TOTP enrolled can go through sign-up, get a magic link for the same account, and land in a session without being asked for a second factor. No exploit involved, just a documented public endpoint.</p>
The gate has to key off the resolved user instead of the endpoint the request arrived on. Ours returns totp_confirmed</code> from inside the same open transaction that resolves the user, and branches there, so both endpoints pass through one decision. What made it easy to miss is that the endpoint-based version behaves correctly under the tests you write per endpoint. Sign in with 2FA and you're prompted, without and you're not, enrol and disable and re-enrol all behave. You only see it if you go looking at the seam.</p>
What you still have to build</h2>
Four things, none of which the missing password column saves you from:</p>

TOTP secrets are real secrets at rest. Ours are AES-GCM encrypted with the user's ID as additional authenticated data, so a ciphertext copied onto another user's row fails to unwrap instead of quietly working.</li>
Recovery codes are ten 160-bit values hashed under their own key, single-use through the same conditional update as everything else.</li>
A 30-second TOTP window with one step of skew either side leaves a code valid for 90 seconds, so you record the last step used and reject anything not strictly newer.</li>
Sessions still expire and still get stolen. Short-lived access token, rotating refresh token, and reuse detection that revokes the session when an already-used token comes back.</li>
</ul>
Timonier</a> is EU-resident authentication with a self-hostable data plane. The Next.js quickstart</a> gets a real user signed in.</em></p>


White or black? Deriving readable label text from any brand colour
2026-08-29T00:00:00+00:00
White or black? Deriving readable label text from any brand colour</h1>
Operators using our hosted sign-in page can set a brand colour. The validator checked that the value was six hex digits, which is all it was ever asked to check, and the page rendered color:#fff</code> over background:var(--cp-brand)</code>.</p>
Set your brand colour to #ffd700</code> and the label on the primary button ships at 1.40:1 against its fill. WCAG AA asks for 4.5:1 on normal-sized text. Our e2e fixture uses #3366cc</code>, which lands at 5.4:1, so every screenshot we had ever taken passed.</p>
We looked at rejecting light colours at authoring time and at darkening the fill until the label passed. Both are worse than the bug. The first turns a format validator into a policy engine that has to explain itself in a form error, and the second silently repaints a customer's brand. Keeping the fill and deriving the ink from it turns out to be provably correct anyway, so neither is necessary.</p>
The derivation</h2>
Compute the fill's relative luminance L</code>, then take the higher-contrast of pure white and pure black:</p>
contrast(white, L) = 1.05 / (L + 0.05)</span></span>
contrast(black, L) = (L + 0.05) / 0.05</span></span></code></pre>
One falls as L</code> rises and the other climbs, so the worst case for taking the better of the two is where they cross:</p>
1.05 / (L + 0.05) = (L + 0.05) / 0.05</span></span>
(L + 0.05)²       = 1.05 × 0.05</span></span>
 L + 0.05         = √0.0525 ≈ 0.22913</span></span></code></pre>
Both ratios come out at 4.5826:1 there, which clears AA for every valid sRGB fill under the WCAG formula. #ffd700</code> gets black at 14.97:1, #3366cc</code> gets white at 5.37:1.</p>
The part that surprised me is how little slack that leaves. Pure black looks harsh next to a soft brand fill and the obvious move is to reach for the neutral already in your token file, which for us is #111827</code>. Run it through the same algebra and the worst case drops to about 4.13:1. It only fails across a band of mid-luminance fills, so a team whose own brand sits outside that band will never see it, and neither will their fixtures. There is a comment in our source saying not to substitute a softer ink, with the number, because somebody was going to try.</p>
fn</span> channel_to_linear</span>(c</span>:</span> u8</span>)</span> -></span> f64</span> {</span></span>
    let</span> c</span> =</span> f64</span>::</span>from</span>(c)</span> /</span> 255.0</span>;</span></span>
    if</span> c</span> <=</span> 0.04045</span> {</span></span>
        c</span> /</span> 12.92</span></span>
    }</span> else</span> {</span></span>
        ((c</span> +</span> 0.055</span>)</span> /</span> 1.055</span>)</span>.</span>powf</span>(</span>2.4</span>)</span></span>
    }</span></span>
}</span></span>
</span>
fn</span> relative_luminance</span>(hex</span>: &</span>str</span>)</span> -></span> f64</span> {</span></span>
    let</span> byte</span> = |</span>range</span>:</span> std</span>::</span>ops</span>::</span>Range</span><</span>usize</span>></span>|</span> {</span></span>
        hex</span>.</span>get</span>(range)</span></span>
            .</span>and_then</span>(</span>|</span>s</span>|</span> u8</span>::</span>from_str_radix</span>(s,</span> 16</span>)</span>.</span>ok</span>())</span></span>
            .</span>unwrap_or</span>(</span>0</span>)</span></span>
    };</span></span>
    0.2126</span> *</span> channel_to_linear</span>(</span>byte</span>(</span>1</span>..</span>3</span>))</span></span>
        +</span> 0.7152</span> *</span> channel_to_linear</span>(</span>byte</span>(</span>3</span>..</span>5</span>))</span></span>
        +</span> 0.0722</span> *</span> channel_to_linear</span>(</span>byte</span>(</span>5</span>..</span>7</span>))</span></span>
}</span></span>
</span>
fn</span> ink_for_fill</span>(hex</span>: &</span>str</span>)</span> -> &</span>'</span>static str</span> {</span></span>
    let</span> l</span> =</span> relative_luminance</span>(hex);</span></span>
    if</span> 1.05</span> /</span> (l</span> +</span> 0.05</span>)</span> >=</span> (l</span> +</span> 0.05</span>)</span> /</span> 0.05</span> {</span></span>
        "#ffffff"</span></span>
    }</span> else</span> {</span></span>
        "#000000"</span></span>
    }</span></span>
}</span></span></code></pre>
The sRGB breakpoint is 0.04045</code>. Plenty of copies of this snippet use 0.03928</code>, which was the older value; no 8-bit channel falls between the two so it changes no output. The unwrap_or(0)</code> is there so the function can't panic, not as a safety property. What makes it safe is that the caller only ever passes a BrandColor</code> that has already been validated.</p>
The focus ring</h2>
Fixing the button surfaced something worse. The focus indicator on the email and code inputs was derived from the brand colour too, sitting on top of outline: none</code>. At the light end of the range a credential field had no visible focus ring at all, which means a keyboard user typing their sign-in code could not see where they were.</p>
That one is not solvable by choosing between two constants, because the ring sits on the card background rather than on the brand fill, so the luminance argument above doesn't reach it. It got a floor keyed to our own text token instead, measuring between 13:1 and 17.7:1 against the card and the page background in both light and dark. The brand tint survives as the input's border colour and a soft halo. It is decoration now and never the only signal.</p>
BrandColor</code> was never the problem, incidentally. It validates format, which is all it should know about. The renderer took that correct value and paired it with a hardcoded #fff</code> that happened to work for the colours in our fixtures.</p>
This is one of the fixes behind Timonier</a>'s hosted sign-in page, which operators can brand with their own logo and colour. Whatever colour they pick, the label on it holds WCAG AA.</em></p>


Why we don't do "Sign in with Google"
2026-08-29T00:00:00+00:00
Why we don't do "Sign in with Google"</h1>
Evaluators ask about social login early and the answer is no. It's ruled out by an architecture decision record rather than parked in a backlog, and since that costs us deals it seems worth explaining.</p>
Worth clearing up an ambiguity first, since two opposite things get called "supporting Google". We are an identity provider. Your app redirects to us, we host the sign-in page, mint an authorization code, issue an id_token</code>, publish discovery and JWKS, and a stock OIDC client works against us with no platform-specific code; we drive Auth.js v5 through the whole flow in our test suite. The direction we don't go is the other one, where the user clicks a button, we bounce them to Google, and we take Google's word for who they are.</p>
Federation puts a US company on the sign-in path</h2>
Our hard constraint is that no US-headquartered third party sits on the runtime path for end-user identity. Picking a Frankfurt region doesn't satisfy it, since the constraint is about who controls the service.</p>
Google, GitHub/Microsoft, Apple and Facebook are all US-headquartered. Federate sign-in to any of them and on every authentication the user's browser gets redirected to a US company, which learns that this person is signing into your product, from this address, now. It happens before we see the user at all, so there's no setting on our side that changes it.</p>
Some teams need the feature and can't ship without it. If you run a consumer app where a real share of signups abandon at the email step, one-click social is worth money you shouldn't give up for our architectural preferences, and you should use somebody else. The bet is that for B2B products, internal tools, and anything sold to European buyers with a DPO involved, the same feature that lifts consumer conversion is the one that complicates a procurement review.</p>
The smaller reason</h2>
Social login isn't a feature you add once. Every provider is an OAuth app registration, a client secret on a rotation schedule, and its own behaviour around scopes and token shapes and email verification. The verification semantics are the genuinely annoying part, because "this address is verified" means different things at different providers and the differences aren't collected anywhere.</p>
Account linking is the part I'd actually worry about. Someone signs up as alice@example.com</code> by email; months later she clicks "Sign in with GitHub" and GitHub asserts alice@example.com</code>. Link on that assertion and any weakness in the provider's verification becomes an account-takeover path on your platform. Refuse to link and she's locked out of her own data. Every vendor offering social login has picked an answer, and the answers are all fine, but it's a surface that grows with each provider you add and we don't have it. There's one credential path here: an emailed link and code, with TOTP on top if you want it.</p>
The door is not nailed shut</h2>
Federating to an EU-headquartered IdP is conceivable, and it removes the jurisdiction objection without touching the rest of the review: sub-processor status, what the assertion actually proves, how linking gets handled. A generic OIDC relying-party mode pointed at a customer's own Keycloak is conceivable too.</p>
Both would need their own decision record and a customer asking for a specific one. Building the abstraction first, on the theory that somebody will eventually want it, is how you end up maintaining a federation layer with one user and four security advisories.</p>
Timonier</a> is EU-resident authentication with a self-hostable data plane. There's a Next.js quickstart</a> if you want to see the flow.</em></p>

Limit</th>	Keyed on</th></tr></thead>
Send rate, per minute and per hour</td>	app + email address</td></tr>
Send rate, per hour</td>	app + client IP</td></tr>
Second-factor attempts, per attempt</td>	the sign-in attempt</td></tr>
Second-factor attempts, per user</td>	user + app</td></tr> </tbody></table> The email buckets key on the address so flooding one mailbox stays bounded regardless of how many IPs you have, and the IP bucket keys on the client address so enumerating many addresses from one host stays bounded regardless of how many mailboxes you try. Neither covers both attacks alone.</p> Every step of a sign-in runs whether or not the account exists. The three rate-limit counters are charged before anything is looked up, both credentials are generated and hashed before we know whether there's a user to send them to, and the attempt row and the Redis write happen either way. Only at the end does the mailer get a `Deliver</code> or a Skip</code>, and both spawn and return without being awaited. Skipping the work for unknown addresses makes the response measurably faster for them, which is an enumeration oracle, and it's what you get by writing the function the obvious way with an early return on "user not found". Two tests assert that the known and unknown branches produce an identical sequence of calls.</p>` A bypass between two endpoints</h2> Sign-in and sign-up are separate endpoints and TOTP is a second factor on sign-in, so the obvious implementation gates the second factor on the sign-in endpoint.</p> But /sign-up</code> upserts on (project_id, email)</code>. A user who already exists and has TOTP enrolled can go through sign-up, get a magic link for the same account, and land in a session without being asked for a second factor. No exploit involved, just a documented public endpoint.</p> The gate has to key off the resolved user instead of the endpoint the request arrived on. Ours returns totp_confirmed</code> from inside the same open transaction that resolves the user, and branches there, so both endpoints pass through one decision. What made it easy to miss is that the endpoint-based version behaves correctly under the tests you write per endpoint. Sign in with 2FA and you're prompted, without and you're not, enrol and disable and re-enrol all behave. You only see it if you go looking at the seam.</p> What you still have to build</h2> Four things, none of which the missing password column saves you from:</p> TOTP secrets are real secrets at rest. Ours are AES-GCM encrypted with the user's ID as additional authenticated data, so a ciphertext copied onto another user's row fails to unwrap instead of quietly working.</li> Recovery codes are ten 160-bit values hashed under their own key, single-use through the same conditional update as everything else.</li> A 30-second TOTP window with one step of skew either side leaves a code valid for 90 seconds, so you record the last step used and reject anything not strictly newer.</li> Sessions still expire and still get stolen. Short-lived access token, rotating refresh token, and reuse detection that revokes the session when an already-used token comes back.</li> </ul> Timonier</a> is EU-resident authentication with a self-hostable data plane. The Next.js quickstart</a> gets a real user signed in.</em></p> White or black? Deriving readable label text from any brand colour 2026-08-29T00:00:00+00:00 White or black? Deriving readable label text from any brand colour</h1> Operators using our hosted sign-in page can set a brand colour. The validator checked that the value was six hex digits, which is all it was ever asked to check, and the page rendered color:#fff</code> over background:var(--cp-brand)</code>.</p> Set your brand colour to #ffd700</code> and the label on the primary button ships at 1.40:1 against its fill. WCAG AA asks for 4.5:1 on normal-sized text. Our e2e fixture uses #3366cc</code>, which lands at 5.4:1, so every screenshot we had ever taken passed.</p> We looked at rejecting light colours at authoring time and at darkening the fill until the label passed. Both are worse than the bug. The first turns a format validator into a policy engine that has to explain itself in a form error, and the second silently repaints a customer's brand. Keeping the fill and deriving the ink from it turns out to be provably correct anyway, so neither is necessary.</p> The derivation</h2> Compute the fill's relative luminance L</code>, then take the higher-contrast of pure white and pure black:</p> contrast(white, L) = 1.05 / (L + 0.05)</span></span> contrast(black, L) = (L + 0.05) / 0.05</span></span></code></pre> One falls as L</code> rises and the other climbs, so the worst case for taking the better of the two is where they cross:</p> 1.05 / (L + 0.05) = (L + 0.05) / 0.05</span></span> (L + 0.05)² = 1.05 × 0.05</span></span> L + 0.05 = √0.0525 ≈ 0.22913</span></span></code></pre> Both ratios come out at 4.5826:1 there, which clears AA for every valid sRGB fill under the WCAG formula. #ffd700</code> gets black at 14.97:1, #3366cc</code> gets white at 5.37:1.</p> The part that surprised me is how little slack that leaves. Pure black looks harsh next to a soft brand fill and the obvious move is to reach for the neutral already in your token file, which for us is #111827</code>. Run it through the same algebra and the worst case drops to about 4.13:1. It only fails across a band of mid-luminance fills, so a team whose own brand sits outside that band will never see it, and neither will their fixtures. There is a comment in our source saying not to substitute a softer ink, with the number, because somebody was going to try.</p> fn</span> channel_to_linear</span>(c</span>:</span> u8</span>)</span> -></span> f64</span> {</span></span> let</span> c</span> =</span> f64</span>::</span>from</span>(c)</span> /</span> 255.0</span>;</span></span> if</span> c</span> <=</span> 0.04045</span> {</span></span> c</span> /</span> 12.92</span></span> }</span> else</span> {</span></span> ((c</span> +</span> 0.055</span>)</span> /</span> 1.055</span>)</span>.</span>powf</span>(</span>2.4</span>)</span></span> }</span></span> }</span></span> </span> fn</span> relative_luminance</span>(hex</span>: &</span>str</span>)</span> -></span> f64</span> {</span></span> let</span> byte</span> = \|</span>range</span>:</span> std</span>::</span>ops</span>::</span>Range</span><</span>usize</span>></span>\|</span> {</span></span> hex</span>.</span>get</span>(range)</span></span> .</span>and_then</span>(</span>\|</span>s</span>\|</span> u8</span>::</span>from_str_radix</span>(s,</span> 16</span>)</span>.</span>ok</span>())</span></span> .</span>unwrap_or</span>(</span>0</span>)</span></span> };</span></span> 0.2126</span> </span> channel_to_linear</span>(</span>byte</span>(</span>1</span>..</span>3</span>))</span></span> +</span> 0.7152</span> </span> channel_to_linear</span>(</span>byte</span>(</span>3</span>..</span>5</span>))</span></span> +</span> 0.0722</span> *</span> channel_to_linear</span>(</span>byte</span>(</span>5</span>..</span>7</span>))</span></span> }</span></span> </span> fn</span> ink_for_fill</span>(hex</span>: &</span>str</span>)</span> -> &</span>'</span>static str</span> {</span></span> let</span> l</span> =</span> relative_luminance</span>(hex);</span></span> if</span> 1.05</span> /</span> (l</span> +</span> 0.05</span>)</span> >=</span> (l</span> +</span> 0.05</span>)</span> /</span> 0.05</span> {</span></span> "#ffffff"</span></span> }</span> else</span> {</span></span> "#000000"</span></span> }</span></span> }</span></span></code></pre> The sRGB breakpoint is 0.04045</code>. Plenty of copies of this snippet use 0.03928</code>, which was the older value; no 8-bit channel falls between the two so it changes no output. The unwrap_or(0)</code> is there so the function can't panic, not as a safety property. What makes it safe is that the caller only ever passes a BrandColor</code> that has already been validated.</p> The focus ring</h2> Fixing the button surfaced something worse. The focus indicator on the email and code inputs was derived from the brand colour too, sitting on top of outline: none</code>. At the light end of the range a credential field had no visible focus ring at all, which means a keyboard user typing their sign-in code could not see where they were.</p> That one is not solvable by choosing between two constants, because the ring sits on the card background rather than on the brand fill, so the luminance argument above doesn't reach it. It got a floor keyed to our own text token instead, measuring between 13:1 and 17.7:1 against the card and the page background in both light and dark. The brand tint survives as the input's border colour and a soft halo. It is decoration now and never the only signal.</p> BrandColor</code> was never the problem, incidentally. It validates format, which is all it should know about. The renderer took that correct value and paired it with a hardcoded #fff</code> that happened to work for the colours in our fixtures.</p> This is one of the fixes behind Timonier</a>'s hosted sign-in page, which operators can brand with their own logo and colour. Whatever colour they pick, the label on it holds WCAG AA.</em></p> Why we don't do "Sign in with Google" 2026-08-29T00:00:00+00:00 Why we don't do "Sign in with Google"</h1> Evaluators ask about social login early and the answer is no. It's ruled out by an architecture decision record rather than parked in a backlog, and since that costs us deals it seems worth explaining.</p> Worth clearing up an ambiguity first, since two opposite things get called "supporting Google". We are an identity provider. Your app redirects to us, we host the sign-in page, mint an authorization code, issue an id_token</code>, publish discovery and JWKS, and a stock OIDC client works against us with no platform-specific code; we drive Auth.js v5 through the whole flow in our test suite. The direction we don't go is the other one, where the user clicks a button, we bounce them to Google, and we take Google's word for who they are.</p> Federation puts a US company on the sign-in path</h2> Our hard constraint is that no US-headquartered third party sits on the runtime path for end-user identity. Picking a Frankfurt region doesn't satisfy it, since the constraint is about who controls the service.</p> Google, GitHub/Microsoft, Apple and Facebook are all US-headquartered. Federate sign-in to any of them and on every authentication the user's browser gets redirected to a US company, which learns that this person is signing into your product, from this address, now. It happens before we see the user at all, so there's no setting on our side that changes it.</p> Some teams need the feature and can't ship without it. If you run a consumer app where a real share of signups abandon at the email step, one-click social is worth money you shouldn't give up for our architectural preferences, and you should use somebody else. The bet is that for B2B products, internal tools, and anything sold to European buyers with a DPO involved, the same feature that lifts consumer conversion is the one that complicates a procurement review.</p> The smaller reason</h2> Social login isn't a feature you add once. Every provider is an OAuth app registration, a client secret on a rotation schedule, and its own behaviour around scopes and token shapes and email verification. The verification semantics are the genuinely annoying part, because "this address is verified" means different things at different providers and the differences aren't collected anywhere.</p> Account linking is the part I'd actually worry about. Someone signs up as alice@example.com</code> by email; months later she clicks "Sign in with GitHub" and GitHub asserts alice@example.com</code>. Link on that assertion and any weakness in the provider's verification becomes an account-takeover path on your platform. Refuse to link and she's locked out of her own data. Every vendor offering social login has picked an answer, and the answers are all fine, but it's a surface that grows with each provider you add and we don't have it. There's one credential path here: an emailed link and code, with TOTP on top if you want it.</p> The door is not nailed shut</h2> Federating to an EU-headquartered IdP is conceivable, and it removes the jurisdiction objection without touching the rest of the review: sub-processor status, what the assertion actually proves, how linking gets handled. A generic OIDC relying-party mode pointed at a customer's own Keycloak is conceivable too.</p> Both would need their own decision record and a customer asking for a specific one. Building the abstraction first, on the theory that somebody will eventually want it, is how you end up maintaining a federation layer with one user and four security advisories.</p> Timonier</a> is EU-resident authentication with a self-hostable data plane. There's a Next.js quickstart</a> if you want to see the flow.</em></p>

- Blog

Moving off Auth0 or Clerk to an EU-resident identity provider

Passwordless sign-in without a password table

White or black? Deriving readable label text from any brand colour

Why we don't do "Sign in with Google"