Google OAuth + Email Allowlist — Access Model
The access model uses Google OAuth combined with a hardcoded email allowlist over: public access (no protection), nickname subdomains as the sole privacy mechanism (a URL is a barrier only until it's discovered), simple passwords (credential management burden, sharing risk), or self-registration (operator loses control of who can read). Nickname subdomains are acceptable as organizational structure — each child's work can live under a readable path or subdomain — but they are not privacy. Anything at a public URL is accessible to anyone who has or discovers the URL. The combination of OAuth (trusted identity provider, no per-user password management) and explicit allowlist (operator decides who can read, not a registration flow) produces a system where the children's work is readable only by people the operator has explicitly approved. This is not a security hardening exercise. It is a privacy posture appropriate to a private family portfolio.
Capture
The portfolio system needs to be accessible to a specific set of trusted people — family members, close friends, people the operator has explicitly decided should be able to see the children's creative work — and inaccessible to everyone else.
Several access models were possible:
- Public access with no authentication
- Nickname subdomains as the access mechanism
- Simple passwords
- Self-registration flow
- Google OAuth with explicit email allowlist
The question this ADR answers: which access model is appropriate for a private family portfolio of children's creative work?
Why
Google OAuth + email allowlist is the right combination for this use case because it addresses the failure modes that matter.
Google OAuth provides: a trusted identity provider that most people the operator wants to grant access already have; no password to manage or rotate on a per-user basis; a familiar, frictionless authentication flow; and reasonable assurance that the person logging in is who they say they are.
An explicit email allowlist provides: operator control over who has access; no self-registration path (access is granted by the operator, not requested by users); a durable record of who was granted access and when; and the ability to revoke access cleanly.
Together, the combination means: you can authenticate as yourself (Google handles this), but you can only read the portfolio if the operator has explicitly added your email address to the allowlist. Neither condition alone is sufficient. Authentication without allowlist means anyone with a Google account could log in. Allowlist without authentication means the list is trivially bypassed.
The result is a system where the operator makes a conscious decision about each person who can see the children's work.
Why-Not
Why not public access with no authentication? The portfolio is private by design (C10-009). Public access defeats the purpose. The children's creative work would be accessible to anyone — search engines, scrapers, data brokers, people the family does not know. This is categorically ruled out.
Why not nickname subdomains as the access mechanism?
Nickname subdomains — where [child-nickname].domain.com routes to the child's portfolio — are useful for organization. They are not privacy. A URL is only private until it is discovered, shared, indexed, or guessed. Subdomains do not authenticate anyone. They do not prevent discovery. They are not access control. Using them as the primary privacy mechanism would give a false sense of protection.
Why not simple passwords? Simple passwords require the operator to manage and rotate credentials for each person with access. Passwords get shared. Shared passwords get shared again. A password that was given to grandma gets forwarded to a cousin. The operator has no visibility into who actually has the credentials. Revocation requires everyone to change their password. The administrative overhead scales badly with the number of trusted people.
Why not self-registration? Self-registration inverts the control model. Instead of the operator deciding who has access, access is granted to anyone who registers. Self-registration requires the operator to then review and revoke registrations, which is harder than maintaining a list. The allowlist model means access is never granted unless the operator explicitly grants it.
Commit
Decision: The access model is Google OAuth plus a hardcoded email allowlist. Authentication is handled by Google; access is granted by explicit allowlist entry. Nickname subdomains may be used for organization but are not the access control mechanism. No self-registration path. The operator controls who can read the portfolio.
Confidence: High.
Timestamp
2026-04-27