Web accounts & sign-in

The in-app side of sign-in — the screens and flows, session handling, and per-user data ownership enforced in the data layer.

What we build

The sign-in providers your users expect, session handling that is secure by default, and per-user ownership enforced where the data lives rather than in the interface — so one customer can never see another's records. The identity provider and token side lives in authentication & identity integration; this service is the in-app experience.

What you get

• Email magic-link sign-in working end to end
• Sessions expiring and refreshing per the agreed policy, covered by a test
• Every non-public route rejecting signed-out requests, covered by a test
• A test proving one user cannot read or write another user's records

How the work unfolds

1. Integrate email magic-link sign-in
2. Integrate Google sign-in
3. Integrate Apple sign-in
4. Wire sessions and per-user ownership

What shapes the price

Before you see a number, our scoping conversation asks:

• Should people be able to sign in with Google? Each social provider is its own integration and console setup. If authentication & identity integration is on the plan, the provider set is decided there — mirror its answers instead of asking the client again.
• Should people be able to sign in with Apple? Sign in with Apple needs an Apple Developer account and its own key setup. If authentication & identity integration is on the plan, the provider set is decided there — mirror its answers instead of asking the client again.

How an engagement starts

This work builds on Web app foundations & setup, so scope, boundaries and constraints are agreed before anything is built.