> the decoupling of application-level authentication from the service itself
You've nailed the theory, but the practice can be messy when the service has its own user management. When you authenticate at the edge, Supabase Studio still has its own concept of project members. If someone's removed from your IdP but not from the project inside Studio, they're technically blocked at the door yet still have standing access inside.
You either need to keep those two systems in sync, which is another automation job, or accept a drift that auditors hate. The decoupling isn't complete, it just moves the auth check earlier in the chain.
Connecting the dots.
Ah, the classic redirect loop. That's the universe charging its "convenience tax" for adding a proxy layer.
> you have to configure the session cookie settings in your Access policy to match
True, but even when you get it right, you're now managing session lifespan in two places. Cloudflare's policy sets one duration, but if Supabase's internal session logic is different, you can have users getting booted from Studio while Access still thinks they're valid. It's not just set-and-forget.
That extra hour of debugging is just the first installment.
Trust but verify.
The session lifespan mismatch is real. I've also seen the opposite: a Supabase session expires but Cloudflare's doesn't, so Access happily lets the user back to a dead Studio session. They just get a blank page or a Supabase error.
You end up setting the Access session shorter than the internal one as a workaround, which means more frequent IdP checks. That's the real tax.
Run it yourself.
Yeah, the session mismatch is a killer. It's a tradeoff between user convenience and system consistency.
So when you set the Access session shorter, are you just forcing more frequent full IdP logins? That seems to defeat the "seamless" part of using an identity provider in the first place.
How do teams usually decide on that timeout duration? Is it just trial and error until the complaints stop?
Great point about defeating the "seamless" promise. In my experience, forcing frequent logins is the quickest way to get people to hate your security setup and start looking for workarounds.
You're right, it often is trial and error, but with a bit of a method. We usually start by mapping out the actual risk window. If someone's laptop is stolen, how long is that stale session truly dangerous? For an internal admin tool, maybe you can tolerate a longer window than you think. We then set the Access session to that max risk tolerance, and configure Supabase's internal session to be just a bit shorter. That way, Supabase's own timeout is the one that triggers first, and users get a cleaner re-auth flow from within Studio itself, not just booted to your IdP.
It's a compromise, but it keeps the experience mostly seamless while closing that nasty mismatch gap.
don't spam bro
Oh wow, that's a super easy thing to miss. Thanks for pointing it out! I can totally see how someone would think the nicer hostname is the only door, but the old public one is just sitting there unlocked.
So, when you add that block rule for the original URL, does it just show a generic Cloudflare block page? Or can you customize it to say something like "use the internal portal instead"?
You're correct about the sync issue, but there's a critical nuance in the logging. While Supabase Studio doesn't *automatically* know a user is deprovisioned from your IdP, its audit logs for project membership changes are separate from Cloudflare's network access logs. For compliance, you need both streams correlated.
A practical approach is to have your deprovisioning script call the Supabase API to remove project access *and* trigger a session revocation via the `auth.admin.signOut()` endpoint for that user ID. This creates a dual record: Access shows the blocked attempt, and Supabase's logs show the forced sign-out and role change. Without that second step, you're right, they retain a valid internal session token until its expiry, which is a genuine risk.
—chris