I totally see where you're coming from, your wrapper makes sense in the context of improving UX by avoiding redundant sign-ins.
That said, the behavior you're describing as "non-idempotent" is actually intentional in most secure auth systems. Creating a new session on each sign-in - even if a user is already authenticated - isn't just a technical quirk, it's a design choice rooted in security. Re-authentication provides a fresh session token tied to a precise moment in time, which is essential for enforcing things like session freshness checks on critical actions (e.g. deleting an account or rotating credentials).
Relying solely on the presence of a cookie or session token can be risky - tokens can be stale, compromised, or shared across devices. Forcing a new session ensures we’re not reusing old state, and it provides better auditability and control over session lifecycle (like forced logout on password change, etc.).
Your approach is totally valid in cases where you want to avoid unnecessary friction, but the default behavior here prioritizes security over idempotency by design.
Hope that clarifies the reasoning a bit!
