Built Tuurio ID because I got tired of implementing login systems again and again
Hey Indie Hackers 👋
After more than 15 years of programming I finally started building my own SaaS products.
One of them is Tuurio ID, a simple identity and authentication service for developers building SaaS apps.
The idea came from a frustration: every time I started a new project I had to implement login and identity management again. Usually decided to go with Firebase but was never really satisfied and happy. As I rely heavily on authentication and identity with another SaaS product of mine for clubs and kitas I decided to build a reusable identity platform instead.
I’m currently at the stage where I’m trying to get the first real users and feedback.
I would really appreciate honest feedback from other founders and developers:
• Is the value proposition clear?
• What features would you expect from an identity service?
You can check it out here:
Nice direction. Identity infrastructure solves a real pain for SaaS builders.
Since this sits directly in the authentication layer of other apps, the security model will define adoption more than features.
A few areas developers will want clarity on:
• How are user credentials stored? Are passwords hashed with a strong algorithm and salted by default?
• Are sessions and tokens short lived and signed with rotating keys?
• How is tenant isolation enforced if multiple SaaS apps use the same identity platform?
Another important point is blast radius. If Tuurio ID goes down or is compromised, every connected SaaS is affected.
Developers will look for:
• Clear token validation model
• Secure API authentication
• Rate limiting and brute force protection
• Audit logs for login activity
Publishing a short architecture and security overview will increase trust with technical founders considering switching from Firebase or Auth0.
As a security team building Nautillo Pro, we often test authentication services because they sit at the core of SaaS attack surfaces.
Hey, thanks for the solid feedback! As a security team, your perspective is exactly what we need to ensure developer trust. To address your points directly:
Hashing & Storage: Our current implementation uses Argon2id(configured with 64MB RAM-hardness) as the default password encoder. This makes brute-force or GPU-based cracking attempts physically and economically unfeasible.
Tenant Isolation: Isolation is enforced deep in the stack via a
TenantFilterAspect. It utilizes Hibernate filters at the database level to ensure that every SQL query is implicitly scoped to the specifictenant_id. Cross-tenant data access is architecturally prevented at the persistence layer.Blast Radius & Uptime: Our JWTs are RS256 signed using a tenant-specific JWK source. We provide a public JWKS endpoint so that SaaS applications can validate tokens cryptographically offline. This means even during a minor provider hiccup, your app remains functional because session validation happens locally in your own backend.
Protection: We have integrated Redis-based rate limiting for all authentication endpoints to block credential stuffing and brute-force attacks at the door. Furthermore, every authentication event is captured in tamper-proof audit logs for full compliance transparency.
We are currently drafting a detailed security whitepaper to document these layers further.
Also curious: when you evaluate auth services at Nautillo Pro, what are the top 2–3 red flags that immediately kill adoption?
Appreciate the detailed breakdown. Argon2id with strong memory hardness and Redis based rate limiting are solid choices for protecting authentication flows.
Enforcing tenant isolation through database level filters is important. Many platforms rely only on application logic, which creates risk later.
To your question about red flags, the most common ones we see when evaluating identity platforms are:
• Tokens that are not scoped properly or have overly long lifetimes
• Weak tenant isolation where cross tenant queries are possible through API misuse
• Missing audit visibility around login events and token issuance
When identity sits at the core of a SaaS stack, small mistakes propagate everywhere.
We often simulate external attack paths against authentication layers because they define the entry point for most SaaS breaches. Nautillo Pro offers a free version if you ever want to run a controlled external simulation against your platform.
A bit more context on what I'm trying to build with Tuurio ID:
Most authentication tools focus mainly on login.
My focus is more on B2B SaaS scenarios where you have multiple organizations/tenants, white-label identity per customer, and requirements around auditability and compliance.
So the goal is less a login widget and more a structured identity layer for multi-tenant SaaS platforms.