Implement real auth endpoints with DTOs and validation

[DenizAltunkapan]

Replace placeholder responses in all auth routes (login/registration/logout/profile) with full implementations using request/response DTOs, validation (e.g., @Valid), and delegation to AuthService for business logic.

[shiocalvin]

hi @DenizAltunkapan can this issue be assigned to me. from what I gather you need controller level validation of dtos but the actual implementation to respective service for logic.

[DenizAltunkapan]

@shiocalvin i assigned you

[shiocalvin]

Hi @DenizAltunkapan
While working on this feature, I realized that moving away from Spring Cloud Gateway for handling authentication flows might be the better long-term approach. The current implementation requires local controllers rather than routing traffic to a separate auth service, which makes a standard Spring setup more suitable for this use case.

Additionally, I noticed that we are still using the native Spring Cloud Gateway, which is now deprecated. If performance is a concern, we can consider Spring WebFlux as a reactive alternative.

Would you prefer that I proceed with migrating to a pure Spring-based implementation, or should we maintain the current Spring Cloud Gateway setup?

[DenizAltunkapan]

@shiocalvin
Hi,
first of all: thank you for taking such a detailed look into this.
Nobody has ever gone that deep into the architecture of the project before, and I really appreciate the attention and the feedback you’re giving here.

Regarding the direction of the authentication flow, feel free to explore the solution space as you think is best — but personally, I really like the idea of moving towards a pure Spring WebFlux–based API Auth Gateway.

The WebFlux approach would allow us to build a lightweight, non-blocking gateway that handles authentication centrally (JWT/session validation) and then forwards requests to the downstream services. Since WebFlux operates in a reactive, event-loop–based model, it can handle high concurrency very efficiently and avoids the overhead of the deprecated Spring Cloud Gateway setup.
The services behind the gateway can continue running on normal Spring MVC, while the gateway itself remains fast, minimal, and focused only on auth and routing — which fits our architecture much better.

So if you’re up for it, feel free to proceed in that direction. I’m definitely open to improvements here and trust your judgment.

Thanks again for the great input! 🙌