Roost
Securing the FinchLabs Platform
Shared identity, sessions, registered application roles, access policy, and administration.
Identity + securityv0.5.1
1. The FinchLabs platform flow
Roost connects the public FinchLabs entry point to shared identity, the authenticated dashboard, and each user's authorized applications.
01 / ENTRY
FinchLabs Front Door
Public entry at finchlabs.com. An unauthenticated visitor reaches the sign-in experience.
02 / IDENTITY
Roost
Authenticates the user, establishes session context, and resolves application access.
03 / LANDING
FinchLabs Dashboard
Canonical landing experience for a signed-in user, showing registered, authorized apps.
04 / APPLICATIONS
Authorized apps
Each protected app validates identity and permissions while managing its own data.
Important distinction: Wingman belongs in the ecosystem directory below, but remains public. It is not presented here as a Roost-protected application.
2. Roost in the FinchLabs ecosystem
The current platform contains several independent applications and services. Roost provides shared identity and application access for the protected applications below. Wingman is intentionally shown because it is part of the FinchLabs ecosystem, but it is still public and has not yet moved under Roost-backed access control.
FlightPath
Progress Takes Flight
Fitness and workout application using Roost identity and normal application roles.
Roost-protectedVerified Access
Kumo
Ideas in Flight
MySQL-backed boards and cards with Roost identity mapped server-side to authorized user spaces.
Roost-protectedMySQL-backed
LogBook
Tracking FinchLabs Development
Private, read-only development history protected by Roost application authorization.
Roost-protectedRead-only UI
Hatchery
Application Proving Ground
Safe proving ground for uncertain shared integration behavior before changes reach higher-value applications.
Roost-protectedProving ground
Wingman
Flying alongside FlightPath
Public FinchLabs API and integration client. It is part of the ecosystem, but Roost enforcement is still pending.
Public todayRoost integration pending
3. Responsibility boundaries
Centralizing identity does not mean centralizing application data. Roost deliberately stays narrow so the security model remains understandable and each product can evolve independently.
| Responsibility | Roost owns | Applications own |
|---|---|---|
| Identity and session | User account, authentication and session context | Trust server-validated identity; do not derive identity from arbitrary query parameters |
| Access | Registered application membership and effective application role | Feature- and data-level checks appropriate to the application |
| Navigation | Authenticated dashboard, authorized app catalog and registered application home URLs | Internal screens, workflows and in-application navigation |
| Domain data | Identity/authorization metadata | Workout history, Kumo boards/cards, LogBook entries and other business content |
| Public experiences | Front Door authentication entry points | Public pages and clients, such as Wingman today, unless explicitly integrated |
4. Verified Access and account lifecycle
Roost v0.5.1 preserves the Verified Access experience: successful email verification enables the account without a separate manual administrator approval step.
1
Register
A new user creates a Roost account with the required credentials.
2
Verify email
The user completes the email-verification step.
3
Account enabled
Verified registration activates the account; manual admin approval is not required.
4
Access apps
Roost evaluates registered application access and role. Verification alone does not grant every app.
Current policy: The password minimum was reduced from 12 to 8 characters in the Verified Access release. Application-level authorization still applies independently of account activation.
5. Canonical navigation and application authorization
Roost v0.5.1 established a clear separation between public sign-in, the authenticated dashboard and individual application destinations.
Landing and redirect behavior
- / with valid token/session context lands at the dashboard.
- / without a valid token leads to the Front Door sign-in experience.
- /dashboard without a valid token redirects to /.
- The canonical destination after authentication is the FinchLabs Dashboard, not a separate Roost admin landing page.
Application access model
- Roost determines which registered applications are active and available to a user.
- Effective application roles are resolved server-side, including user and admin where assigned.
- Registered home_url destinations drive app navigation.
- Every protected application must enforce its own permissions and data boundaries.
6. Security principles and operating boundaries
These are the design and verification principles for Roost-backed applications. They are not a claim that every possible security enhancement is already deployed across every app.
01
Server-side authorization - Use the authenticated Roost user and effective application role, never a client-supplied user ID as authority.
02
Least privilege - Only authorized applications and functions should be available. A valid account alone is not a blanket grant.
03
Keep domain data isolated - Roost owns identity and access. Apps retain their own persistence and enforce data ownership.
04
Protect session operations - Review secure-cookie attributes, CSRF protection, session expiration and login/logout behavior during implementation and release validation.
05
Preserve production state - Avoid replacing deployed users, application-role mappings, configuration or app-owned data without an explicit, backed-up migration.
7. Current platform + next
Separate confirmed production capabilities from proposed, deferred or pending integration work.
Deployed and validated
- Roost v0.5.1, including Verified Access and canonical dashboard routing.
- Centralized identity, session context, app registration and effective application roles.
- Protected Kumo, FlightPath, LogBook and Hatchery experiences.
- Kumo persists board and card data in MySQL with Roost-backed user identity.
- LogBook offers Roost-authorized, read-only access to development history.
Planned or pending
- Wingman currently remains public; Roost-backed enforcement is a future integration.
- Kumo v2.1 Shared Boards requires secure owner/editor/viewer permissions and board-level data checks.
- Continue reviewing administration, auditability and session/CSRF safeguards as future Roost work evolves.
- Preserve Roost as the identity and access layer rather than moving app-owned data into it.