Problem
An appointment app ran on a business application backend with website users who had no direct record permissions. Customers needed a real account experience, but the portal had no branded login or account area.
Business Context
The service business publishes a branded appointment flow. Customers must sign up, confirm, sign in and see their own information — without ever being able to read another customer's records.
Constraints
- Use platform authentication and signup APIs — no custom password storage.
- No user enumeration: sign-in and signup must not reveal whether an account exists.
- Owner-scoped data: an applicant can see their own summary only — never passport numbers, only masked or review-status fields.
- Website users have no direct record permissions, so the portal must expose only safe, scoped endpoints.
Analysis
The account boundary is ownership. The safe surface is a small, owner-scoped API: profile get/update plus a reusable applicant summary that strips sensitive fields. Everything else stays behind the standard role model.
Architecture
Public pages for sign-in/signup and My Account, matching the existing appointment visual design. A dedicated account API owns profile updates and the safe applicant summary, calling shared portal logic for things like registered mobile.
Solution
Branded `/appointment-login` with sign-in and signup tabs, email-confirmation feedback, a login-required `/my-account` page, and an owner-scoped account API.
Technology
- business application backend
- website login / signup APIs
- owner-scoped portal API
- automated test suite
Implementation
The account API and pages were built, then covered with automated tests: guest rejection, owner-scoped applicant summaries, and profile updates. No custom password storage, no user enumeration.
Challenges
Website users without direct record permissions need a deliberately small API surface; verification on a live server was still pending because the local checkout has no full runtime environment.
Outcome
Customers get a branded sign-in/signup and account experience, and every data call is owner-scoped and test-covered. The application is ready to be verified on a full runtime test site.
Lessons
Portal security is a surface-design problem: expose a tiny, scoped API instead of widening permissions. Tests for guest rejection and ownership make the boundary real.
Future Improvements
Outgoing signup email verification on a live site, and the account API test suite run against a full bench.