Shared auth across standalone app modules #28

New issue

Open

opened 2026-04-27 15:20:27 +00:00 by padreug · 0 comments

padreug commented

2026-04-27 15:20:27 +00:00

Owner

Problem

Each standalone app (Castle, Sortir/Eventos) requires a separate login because they're on different subdomains with isolated localStorage. Users must authenticate on each app independently.

Moved from aiolabs/atio-home#1.

Current workaround

Standalone apps accept ?token=<access_token> in the URL. The main app can link to sortir.ariege.io?token=xxx to relay the session. Not production-grade (token in browser history/logs).

Approaches considered

1. Route-based modules (near-term, recommended)

Serve standalone apps as routes under the main app domain instead of separate subdomains:

app.ariege.io/sortir instead of sortir.ariege.io
app.ariege.io/castle instead of castle.ariege.io
app.ariege.io/eventos instead of eventos.atitlan.io

Pros: Same origin = same localStorage = shared auth. No backend changes. No CORS issues.
Cons: Need to ensure standalone app routes don't conflict with main app routes. PWA manifest/service worker scope needs configuration per path prefix. Build pipeline needs to output to subdirectories.

2. Cookie-based auth (`Domain=.ariege.io`)

LNbits sets HttpOnly cookie with Domain=.ariege.io on login. All subdomains share the session automatically.

Pros: Clean, standard web pattern. Works with existing subdomain setup.
Cons: Requires LNbits backend changes. CORS configuration needed. Different domains per deployment (ariege.io vs atitlan.io vs aiolabs.dev).

3. Nostr-based auth (long-term)

Since every user has a Nostr keypair, standalone apps could authenticate via NIP-98 (signed HTTP auth) or a challenge-response flow. The private key is stored in the main app; standalone apps request signing via postMessage or a shared worker.

Pros: Aligns with Nostr-native goal. No cookies/tokens needed. Works across any domain.
Cons: No established PWA pattern for this yet. Key storage/sharing across origins is the hard part.

Recommendation

Start with approach 1 (route-based) for near-term. It's the simplest and doesn't require backend changes. The standalone apps already build to separate dist directories — just need nginx to serve them under path prefixes on the main app domain.

aiolabs/atio-home#1 (original issue, to be closed)
aiolabs/webapp#26 (adopt standalone UI patterns in AIO app — related, as the AIO app itself may eventually absorb these modules)

## Problem Each standalone app (Castle, Sortir/Eventos) requires a separate login because they're on different subdomains with isolated localStorage. Users must authenticate on each app independently. Moved from aiolabs/atio-home#1. ## Current workaround Standalone apps accept `?token=<access_token>` in the URL. The main app can link to `sortir.ariege.io?token=xxx` to relay the session. Not production-grade (token in browser history/logs). ## Approaches considered ### 1. Route-based modules (near-term, recommended) Serve standalone apps as routes under the main app domain instead of separate subdomains: - `app.ariege.io/sortir` instead of `sortir.ariege.io` - `app.ariege.io/castle` instead of `castle.ariege.io` - `app.ariege.io/eventos` instead of `eventos.atitlan.io` **Pros:** Same origin = same localStorage = shared auth. No backend changes. No CORS issues. **Cons:** Need to ensure standalone app routes don't conflict with main app routes. PWA manifest/service worker scope needs configuration per path prefix. Build pipeline needs to output to subdirectories. ### 2. Cookie-based auth (`Domain=.ariege.io`) LNbits sets `HttpOnly` cookie with `Domain=.ariege.io` on login. All subdomains share the session automatically. **Pros:** Clean, standard web pattern. Works with existing subdomain setup. **Cons:** Requires LNbits backend changes. CORS configuration needed. Different domains per deployment (ariege.io vs atitlan.io vs aiolabs.dev). ### 3. Nostr-based auth (long-term) Since every user has a Nostr keypair, standalone apps could authenticate via NIP-98 (signed HTTP auth) or a challenge-response flow. The private key is stored in the main app; standalone apps request signing via postMessage or a shared worker. **Pros:** Aligns with Nostr-native goal. No cookies/tokens needed. Works across any domain. **Cons:** No established PWA pattern for this yet. Key storage/sharing across origins is the hard part. ## Recommendation Start with approach 1 (route-based) for near-term. It's the simplest and doesn't require backend changes. The standalone apps already build to separate dist directories — just need nginx to serve them under path prefixes on the main app domain. ## Related - aiolabs/atio-home#1 (original issue, to be closed) - aiolabs/webapp#26 (adopt standalone UI patterns in AIO app — related, as the AIO app itself may eventually absorb these modules)

padreug referenced this issue from aiolabs/atio-home

2026-04-27 15:20:49 +00:00

Cross-subdomain auth: shared login session across standalone apps #1

padreug referenced this issue

2026-05-13 09:51:09 +00:00

Cross-cutting "teams" concept: targeted tasks, scoped budgets, and shared rosters #55

padreug added the

app:webapp

enhancement

labels

2026-05-17 21:24:13 +00:00