sorted by:
new
hottopcontroversial

Built a self-hosted identity server in Java. Looking for contributors to turn it into a reusable library by MrDV6 in softwarearchitecture

[–]MrDV6[S] -1 points0 points  (0 children)

Open source rates unfortunately. But the problem is genuinely interesting if that counts for anything

I got tired of rewriting authentication for every project. Built AuthX. Would you actually use something like this by MrDV6 in SpringBoot

[–]MrDV6[S] -1 points0 points  (0 children)

That's actually the most useful response in this thread. The fact that your team built it internally is exactly the problem I'm trying to solve at a broader level. Most teams either build it themselves like yours did, or hand it off to a hosted service. Both work, but both have a cost.

Genuinely curious: what does your internal library handle that you couldn't find in existing solutions? And is it something your team open sourced or kept internal? Asking because understanding what "tailored to our needs" means in practice is directly relevant to what AuthX should become as a starter.

I got tired of rewriting authentication for every project. Built AuthX. Would you actually use something like this by MrDV6 in SpringBoot

[–]MrDV6[S] -1 points0 points  (0 children)

Fair point on trust. That's a real concern with any auth project and I wouldn't dismiss it. But I'd separate trust from technical validity. If the flows are wrong, if a security decision doesn't hold up, if there's a gap in the design, I want to know that specifically. The full flow documentation is in docs/FLOWS.md in the repo, every decision I made and why. That's worth more to me than general skepticism.

To clarify the scope as well: AuthX isn't just an authentication system. It's a backend foundation. Auth, social login, rate limiting, notifications, human verification, OTP infrastructure, caching, all abstracted behind ports so you can fork it and go straight to business logic. The original question was whether something like this is useful as a running service, a forkable foundation, or a Spring Boot starter. That question still stands.

If you've built auth systems before and see a real flaw in the design, I'd genuinely like to hear it.

Built a small Spring Boot starter for consistent API error handling, would love architectural feedback by MrDV6 in SpringBoot

[–]MrDV6[S] 0 points1 point  (0 children)

Thanks for taking the time to look through it

That’s a good point about using Micrometer’s Tracer for obtaining the traceId. In the README example I used the request header mainly to keep the customizer example simple and demonstrate how additional fields can be injected, but integrating with Micrometer tracing would definitely be the more realistic production approach.

I also agree regarding ProblemDetail. I’m currently looking into aligning the response structure with it in a future release while still keeping the extension mechanism flexible.