> For the complete documentation index, see [llms.txt](https://sonic-ai-works.gitbook.io/sonic-networks-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sonic-ai-works.gitbook.io/sonic-networks-docs/documentation/application-and-website/pwa-auth-providers-and-achievement-assets.md). # PWA, auth providers & achievement assets This page documents installable web behavior, authentication presentation, the same-origin API gateway, wallet security boundaries, PWA assets and dashboard runtime rules. > **MVP status:** product surfaces and contract wiring can exist before every identity/provider/deployment adapter is production-verified. Never infer Live/Verified status from UI availability alone. ## Application ownership ``` apps/web public website / PWA / marketing apps/dashboard authenticated dashboard / Studio / Projects / Credits / Settings apps/api session verification / authority / SaaS / protected mutations / providers ``` The public website does not own dashboard navigation. The dashboard does not reuse the public marketing shell. ## Progressive Web App The public PWA cache is deliberately narrow. Authentication, checkout, wallet, finance, transaction, private Studio and server-authority responses are excluded from service-worker caching. Do not cache: ``` /api/* /api/sonic/* /auth/* /checkout* /dashboard private data transaction/intent responses wallet signatures ``` Browser identity assets include favicon/ICO sizes, Apple Touch icon, Android 192/512 and maskable app icons. Canonical SONIC waveform branding remains the application identity. ## Authentication provider registry Provider availability may be shown through public configuration, but OAuth client secrets, refresh tokens and provider credentials remain server-only. Adding a provider requires: 1. safe public provider metadata; 2. server-side provider adapter/credentials; 3. callback and redirect allowlists; 4. account linking/identity policy; 5. authentication tests and revocation review. Wallet connection is not an OAuth/social authentication substitute. ## Signed session and same-origin API gateway Browser code calls the same-origin application gateway rather than choosing tenant/account headers itself. ``` signed sonic_session ↓ web/dashboard /api/sonic/* gateway ↓ strips public authority-header injection apps/api ↓ verifies signed session server authority resolver ↓ Auth Context / protected operation ``` `SONIC_SESSION_HMAC_SECRET` is server-only and must contain at least 32 random bytes. Canonical production adapters: ``` SONIC_IDENTITY_SERVICE_URL SONIC_IDENTITY_SERVICE_TOKEN SONIC_AUTHORITY_SERVICE_URL SONIC_AUTHORITY_SERVICE_TOKEN ``` The identity service authenticates/session-lifecycle operations. The authority service resolves current account/tenant role/permission and SaaS state. Missing production adapters fail closed; they never fall back to browser role selection. A development adapter may be enabled only outside production with `SONIC_DEV_AUTH_ENABLED=true` and explicit local credentials. ## Public authority-header rule Public clients cannot choose: ``` x-user-id x-tenant-id x-account-id role permissions entitlements verified-wallet state ``` If internal service headers exist, the trusted gateway/service layer owns them after authentication. User-provided copies are stripped, ignored or rejected. ## Authentication context The dashboard bootstraps through: ``` GET /api/v1/auth/context ↓ GET /api/v1/saas/me + GET /api/v1/access/context?path= ``` Auth Context exposes sanitized authority only and intentionally omits raw session IDs, provider/Firebase claims, refresh tokens, signatures and signing material. Context responses use: ```http Cache-Control: private, no-store, max-age=0 Vary: Cookie, Authorization ``` LocalStorage may store benign UI preferences such as theme/sidebar state, but not role/permission/context projections as authorization evidence. ## Wallet entry security Wallet entry and transaction authorization are separate boundaries. ``` Connect wallet → challenge → explicit identity-message signature → server verification → verified wallet-link record later money-moving action → server policy/quote → TransactionIntent → explicit transaction signature → submission → chain/effect verification → settlement → reconciliation ``` Wallet connection does not authenticate the dashboard, grant application roles, authorize SONIC transfers, settle checkout or establish reward entitlement. ## Dashboard shell refinement The authenticated dashboard is light-first and includes: * application-only full-height sidebar; * dashboard header and compact app footer; * role/permission-aware module composition; * System / Light / Dark theme modes with light as default; * persisted non-security UI preferences; * Studio and Projects inside the authenticated shell; * server-derived Auth/SaaS/Access context; * non-fabricated credit/account labels until authoritative data loads; * contextual wallet provider rather than global wallet authority; * same-origin backend gateway for protected operations. The dashboard does not render the public marketing footer/header navigation. ## SONIC coin and achievement assets Token/achievement artwork remains distinct from ordinary application identity. The red SONIC coin is economic presentation art, not authentication, deployment or reward evidence. Trophy presentation is visual; rank, score, funding and eligibility come from authoritative application data. ## Security invariant ``` PWA/browser identity + same-origin gateway + signed session + server authority + wallet verification kept separate + private provider credentials + no cached protected state = valid SONIC browser runtime boundary ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://sonic-ai-works.gitbook.io/sonic-networks-docs/documentation/application-and-website/pwa-auth-providers-and-achievement-assets.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.