Request-scoped application identity

Applications use the existing hosted sign-in broker and exact-host session cookies. The shared gateway strips client X-Backify-* headers and exchanges a valid session for a short-lived signed X-Backify-User token. Browser code calls its own backend with ordinary fetch; it does not acquire a workload token.

The server SDK verifies token type backify-user+jwt, RS256 signature, expiry and urn:backify:application:{appId}:environment:{environmentId} audience using the injected gateway trust keys. Missing, forged or cross-environment tokens never become an authenticated user. Host and environment scoping also apply to custom domains.

Use explicit route auth: "public", "user", { role } or { permission }, and derive SQL ownership filters from the verified user context. No provider name, email match or browser role list can authorize access.

End-user tokens and Backify workload tokens have separate purposes. The workload token is scoped to app, environment, release and process role and authenticates server calls to the broker. It never belongs in a browser bundle, cookie, URL or log.

Keep sign-in and provider settings in secure portal configuration; preserve existing platform/portal login. Local development uses a development-only sign-in fixture and per-run signing keys. Verify real callback and magic-link delivery in preview. See authentication, backend and the runtime contract.