Authentication and access control

Authentication identifies a user or service; authorization determines what that identity may do. Ethen’s root layout can conditionally enable Clerk, and the repository contains Supabase-oriented server modules, but no global middleware or complete enterprise role model was verified.

This guide explains how to review the current identity boundary without assuming universal route protection, SSO, SAML, SCIM, MFA enforcement, or complete organization membership. Administrators should validate sensitive routes and stored resources in the deployed environment.

Authentication

app/layout.tsx loads ClerkProvider only when NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY is configured. That behavior makes authentication optional at the root. Sign-in and sign-up routes exist, but their presence does not prove that every product route or API rejects unauthenticated requests.

Review authentication at the route that performs the sensitive operation. Confirm how the server obtains the identity, what happens when the identity is absent, and whether development or fallback behavior changes the result. Client-visible state should not be treated as the authorization source for server data.

The Clerk-to-Supabase identity bridge remains incomplete. If a route reads or writes Supabase data, verify how the authenticated subject maps to the project, user, or record owner. Avoid relying on email strings or client-provided IDs when a trusted subject identifier is available.

Route-by-route authentication review

Create a route inventory for pages and APIs that read customer data, change configuration, invoke providers, or expose operational records. For each route, record whether it is public by design, requires a user session, accepts an API key, or depends on another service identity.

Then inspect the server boundary. A page can hide a control while leaving its action callable, and a client-side redirect can improve navigation without protecting the API. The server must reject an unauthenticated request before reading or changing protected data.

Authentication failure should be distinguishable from backend setup failure. If Clerk is not configured, the application may operate in a different readiness state than when a user’s session has expired. If Supabase is not configured, an authenticated user can still be unable to reach durable data. Preserve those separate diagnoses in troubleshooting and monitoring.

API and human identity

Human sessions and API credentials should be reviewed separately. A signed-in user may create or use an API key that continues to work after the browser session ends. Conversely, a valid user session may not authorize a server API that expects a project-scoped key.

Document which identity is authoritative at each route and how that identity is revoked. Avoid treating the visible user name as proof of the caller used by a server-to-server operation.

Sessions

A session represents an authenticated interaction, while platform-wide session policy remains undefined. Cookie lifetime, refresh behavior, revocation, idle timeout, concurrent sessions, device management, and step-up authentication require further review.

Administrators should distinguish the identity-provider session from product-specific sessions such as chat, voice, workflow, or run records. Ending a product session may not sign the user out, and signing out may not delete product history.

For a sensitive deployment, document how sessions begin, how they end, which routes depend on them, and how compromised sessions are revoked. Do not promise an immediate global logout unless the identity and application behavior has been tested across the relevant products.

Session risk decisions

Decide whether sensitive actions require a recent authentication event, a continuously valid identity-provider session, or an additional product confirmation. No universal step-up policy is implemented, so high-risk routes should not be described as protected by step-up authentication.

Revocation testing should cover more than closing a browser tab. Sign out, invalidate the identity-provider session where supported, and attempt the server action again. Check other devices and existing API keys separately because those credentials can outlive the browser session.

Product histories and generated records may persist after session termination. Session revocation controls future authenticated interaction; it is not a data deletion process.

Roles

A complete role matrix is not established. Some products expose approval, operator, admin, reviewer, or owner concepts, but those labels do not prove a single platform-wide authorization system.

When a route needs a permission decision, define the smallest action being protected: view a project, change a provider credential, approve a proposal, inspect an audit entry, or modify a policy. Map that action to the actual identity and storage rule used by the route.

Avoid inventing enterprise roles or implying that an “admin” label grants the same authority everywhere. SSO, SAML, SCIM, directory groups, and automatic role provisioning are not verified. If an organization needs those controls, keep the page and deployment in review until the identity architecture is approved.

Permission map

A practical permission map lists actions down the rows and trusted identities across the columns. Useful rows include viewing project data, invoking a provider, changing a credential, editing policy, approving a proposal, reading logs, and viewing billing or usage. Mark each cell as allowed, denied, or unresolved based on the actual route behavior.

This map often reveals that a broad role label hides different implementation paths. A user may be able to open Settings but not change a server-side provider key, or may view usage without being allowed to alter a budget. Keep those distinctions rather than forcing them into an invented enterprise role hierarchy.

When a permission is unresolved, treat it as a deployment blocker for sensitive data instead of granting the broadest role for convenience.

Role changes should be tested with the affected account rather than inferred from the settings display. Confirm that newly denied actions fail at the server and that newly granted access does not expose unrelated projects.

Least privilege

Least privilege means granting only the access required for a task and removing it when the task ends. In Ethen, that principle applies to user routes, provider accounts, database service roles, local runtime endpoints, approval decisions, and external connectors.

Separate credentials by purpose. A Gateway API key should not be reused as a provider credential. A server service role should not be exposed to the browser. A provider key should be limited to the account and capabilities needed for the configured route where the provider supports such restriction.

Product maturity matters. A scaffolded approval surface or sample audit route should not become the only control protecting a high-impact action. Use preview features for evaluation until persistence and enforcement are verified.

Service identities and elevated access

Human roles are only part of the access model. Server routes can use service credentials that bypass ordinary user restrictions, background jobs can act without an interactive session, and provider keys can authorize work outside Ethen.

Inventory those identities separately. Restrict each service credential to the routes and stores it needs, keep it server-side, and review whether the code applies an explicit project or owner filter before using elevated access. A correctly authenticated user can still receive another customer’s data if a service-role query omits ownership.

For provider accounts, prefer separate credentials or projects when the provider supports them. Shared provider access can make attribution and offboarding more difficult.

Access review

Because automated recertification is not established, access review is currently an administrative process. Build the review from actual access paths rather than from an assumed organization hierarchy.

Inspect active identity-provider users, project ownership, settings access, provider accounts, API keys, environment values, local devices, and approval roles. Confirm that former users or temporary operators no longer retain access in any of those systems.

Record the reviewer, scope, date, findings, and remediation. The record can be maintained outside Ethen when the platform lacks a durable access-review workflow. Do not describe that external process as an implemented product feature.

Offboarding sequence

When a user leaves a project or organization, disable the identity-provider account or access path, end active sessions where possible, revoke Ethen API keys owned by that person, remove project access, and review provider or local accounts that may have been configured outside Ethen.

Do not assume that one identity action removes every credential. A BYOK provider key can remain valid after the Ethen user is disabled. A local runtime on a former employee’s device can retain models or files. A shared Supabase service role is not tied to an individual session at all.

Record each completed step and any system that could not be verified. The lack of automated recertification makes this manual evidence important.

Review evidence

The review record should identify the user or service identity, resource, current access, intended access, reviewer, decision, and remediation date. It should also note systems that could not be checked, such as an external provider account or local device.

Do not rely on the sample audit route to supply this record automatically. Until a durable review workflow exists, use the organization’s approved administrative system and link only safe identifiers back to Ethen.

Troubleshooting

If a user reaches a route unexpectedly, test both the page request and the server action behind it. A protected interface can still call an incorrectly authorized API, while a public page can legitimately read non-sensitive information.

For missing access, check whether Clerk is configured, whether the user has a valid identity-provider session, whether the route derives that identity correctly, and whether the backing store recognizes the same owner. Supabase readiness, migrations, and RLS should be checked independently.

Do not weaken authorization to resolve a development error. If ownership or role behavior cannot be verified, stop the production rollout for that route and retain the applicable review flags.

Verify the denial path

A secure test should confirm that an unauthenticated caller, an authenticated caller without ownership, and a caller using another project identifier are all rejected appropriately. Use non-sensitive test records and inspect the server result rather than relying only on navigation behavior.

If a route returns a setup error instead of an authorization result, fix the backend configuration before concluding that access control works. If service-role code is involved, confirm that the owner filter is enforced in application logic or reviewed RLS.

Document unresolved routes and keep them out of sensitive production workflows until the boundary is proven.

If identity mapping differs between Clerk and Supabase, capture the trusted subject from the identity provider and the owner field used by the data query. Resolve the mapping rather than creating duplicate user records or broadening RLS. A temporary development bypass should not reach production.

Retest after every authorization or identity-bridge change.