14 Branding and UX
Note
If family members are prompted to log in frequently, they will stop using the services. Session design, enrollment, and visual consistency are load-bearing.
14.1 Session management
- Authentik session lifetime set long enough that family members rarely see a login prompt
- Refresh tokens keep sessions alive across browser restarts
- The tradeoff between session length and security is different for a family than for an enterprise; convenience wins here
14.2 Passkey-first MFA
- Passkeys (WebAuthn) as the primary MFA method
- Most family members already have passkey-capable devices (iPhone Face ID, Android fingerprint, Windows Hello)
- TOTP as a fallback for devices that don’t support passkeys
- No SMS-based MFA; it’s phishable and adds phone number management overhead
14.3 Implicit consent
- Authentik’s consent flow configured to skip the consent screen for trusted applications
- Family members should not be asked “Do you want to share your email with Immich?” every time they log in
- All applications in the stack are first-party; explicit consent screens add friction without adding value
14.4 Visual branding
- Consistent
dunn.devbranding across Authentik login, all service UIs, and email notifications - Custom Authentik flow backgrounds and logos so the login page looks intentional, not like a random open-source project
- Consistent subdomain naming:
auth.dunn.dev,memory.dunn.dev,files.dunn.dev,forge.dunn.dev, etc.
14.5 The Authentik user dashboard
- Authentik’s user dashboard at
auth.dunn.devserves as the family’s app launcher - All available services listed with icons and links
- Family members bookmark the dashboard; it’s their single entry point
14.6 Enrollment flow
- New family member enrollment: maintainer creates user in Authentik, sends enrollment link
- Enrollment flow: set password, register passkey, done
- No email verification step (the maintainer already knows who they’re enrolling)
- Goal: a new family member goes from enrollment link to using services in under two minutes