Our new Password Reset template includes:
→ Magic link authentication
→ Reset workflows
→ Request tracking
→ Ready-to-use automations
1 Like
While implementing the Password Reset template in a real production project, I wanted to investigate whether a single Authentication Builder Application (Login, Forgot Password and Reset Password) could be reused by multiple Builder Applications within the same workspace.
This idea was partly inspired by discussions in the community and earlier architectural guidance suggesting that a central authentication application could be a good approach. I therefore decided to build and test this architecture before adopting it in production.
During these experiments, I observed behaviour that differed from my expectations. Rather than immediately assuming this is a bug or a limitation, I documented the entire investigation: the assumptions, test setup, experiments, observations and conclusions.
I’m sharing the attached PDF in the hope that the template author, the Baserow team and other community members can help validate the findings, point out anything I may have overlooked, or explain whether the observed behaviour is expected by design.
If my assumptions are incorrect, I’d be happy to learn the recommended architecture. My goal is simply to understand the best production approach for applications that share a Users table across multiple Builder Applications.
RFC_Baserow_Central_Authentication_Investigation_v2.zip (22.7 KB)
@frederikdc as the author of this template, could you please take a look at this feedback? 
Hi,
It’s indeed not possible to authenticate over multiple applications, even if the user source is referring to the same table. This is because each application is published in it’s own domain.