Spike: Persistent auth sessions (never re-login on same device) #168

New issue

Closed

opened 2026-06-07 23:49:37 +00:00 by ldraney · 0 comments

ldraney commented

2026-06-07 23:49:37 +00:00

Owner

Type

Spike

Lineage

Standalone — observed during daily use. Spans pal-e-services (Keycloak config) and potentially the Rails app.

Repo

ldraney/landscaping-assistant + ldraney/pal-e-services (Keycloak Terraform)

Question

What configuration changes are needed so that a user who logs in on a device stays logged in indefinitely (or near-indefinitely) without being prompted to re-authenticate?

Areas to investigate:

Keycloak session lifetimes (pal-e-services Terraform):
- SSO Session Idle timeout (default 30 min)
- SSO Session Max lifespan (default 10 hours)
- "Remember Me" feature on the Keycloak client
- Offline tokens (long-lived refresh tokens that survive server restarts)
Rails session cookie (landscaping-assistant):
- Current cookie expiry (likely browser-session — dies on close)
- Persistent cookie with long expiry (e.g. 30 days, 1 year)
- Whether we need silent token refresh when Keycloak session expires but Rails cookie is still alive
turbo-ios / mobile:
- Keychain-stored OAuth tokens persist across app kills
- Refresh token rotation to keep sessions alive without re-prompting
- ASWebAuthenticationSession behavior on token expiry
Security tradeoffs:
- Long sessions vs. forced re-auth for sensitive actions
- Device trust model (is Tailscale network membership sufficient trust?)
- Token revocation if a device is lost

Time-box

3 hours

Deliverables

Decision doc or spike note with recommended Keycloak settings
Identify Rails app changes (cookie config, token refresh middleware)
List pal-e-services Terraform changes needed (realm/client settings)
Security tradeoff summary
turbo-ios implications for Phase 5

Acceptance Criteria

Document current session lifetimes (Keycloak + Rails cookie)
Recommend Keycloak settings for "remember me" / long-lived sessions
Identify Rails app changes needed (cookie config, token refresh)
Document security tradeoffs and recommended mitigations
Identify whether pal-e-services Terraform changes are needed
Note any turbo-ios implications for Phase 5

Constraints

Must not weaken auth for other platform apps sharing the same Keycloak realm (if applicable — check realm isolation)
Solution must work for both web browser and future turbo-ios app

docs/auth-strategy.md — current auth architecture decision
docs/keycloak-setup.md — Keycloak client config
#108 — turbo-ios (Phase 5, will need persistent auth)
#115 — Phase 1 Keycloak login (done)

### Type Spike ### Lineage Standalone — observed during daily use. Spans pal-e-services (Keycloak config) and potentially the Rails app. ### Repo `ldraney/landscaping-assistant` + `ldraney/pal-e-services` (Keycloak Terraform) ### Question What configuration changes are needed so that a user who logs in on a device stays logged in indefinitely (or near-indefinitely) without being prompted to re-authenticate? Areas to investigate: 1. **Keycloak session lifetimes** (pal-e-services Terraform): - SSO Session Idle timeout (default 30 min) - SSO Session Max lifespan (default 10 hours) - "Remember Me" feature on the Keycloak client - Offline tokens (long-lived refresh tokens that survive server restarts) 2. **Rails session cookie** (landscaping-assistant): - Current cookie expiry (likely browser-session — dies on close) - Persistent cookie with long expiry (e.g. 30 days, 1 year) - Whether we need silent token refresh when Keycloak session expires but Rails cookie is still alive 3. **turbo-ios / mobile**: - Keychain-stored OAuth tokens persist across app kills - Refresh token rotation to keep sessions alive without re-prompting - ASWebAuthenticationSession behavior on token expiry 4. **Security tradeoffs**: - Long sessions vs. forced re-auth for sensitive actions - Device trust model (is Tailscale network membership sufficient trust?) - Token revocation if a device is lost ### Time-box 3 hours ### Deliverables - Decision doc or spike note with recommended Keycloak settings - Identify Rails app changes (cookie config, token refresh middleware) - List pal-e-services Terraform changes needed (realm/client settings) - Security tradeoff summary - turbo-ios implications for Phase 5 ### Acceptance Criteria - [ ] Document current session lifetimes (Keycloak + Rails cookie) - [ ] Recommend Keycloak settings for "remember me" / long-lived sessions - [ ] Identify Rails app changes needed (cookie config, token refresh) - [ ] Document security tradeoffs and recommended mitigations - [ ] Identify whether pal-e-services Terraform changes are needed - [ ] Note any turbo-ios implications for Phase 5 ### Constraints - Must not weaken auth for other platform apps sharing the same Keycloak realm (if applicable — check realm isolation) - Solution must work for both web browser and future turbo-ios app ### Related - docs/auth-strategy.md — current auth architecture decision - docs/keycloak-setup.md — Keycloak client config - #108 — turbo-ios (Phase 5, will need persistent auth) - #115 — Phase 1 Keycloak login (done)