# Pattern: Backend-for-Frontend

Status: seed
Readiness target: RL2 private beta
Primary owners: product repos, NetKingdom
Genesis family: Application/API security

## Problem

Different UI clients often need different API shapes, but exposing broad
backend APIs directly to browsers or mobile clients increases token and
data exposure.

## Context

Use this pattern for web frontends, mobile clients, admin consoles,
tenant portals, and agent-facing UI surfaces.

## Forces

- UI clients need tailored data and workflow APIs.
- Backend services may expose fields or operations that clients should
  not see.
- Tokens and sessions need client-appropriate handling.
- Authorization decisions still need tenant and object context.

## Solution

Create a client-specific backend layer that mediates session handling,
data shaping, authorization calls, and downstream API access for one
frontend class.

## Verification

- The BFF exposes only client-appropriate operations and fields.
- Downstream calls include trusted user, tenant, and authorization
  context.
- Sensitive backend tokens are not exposed to clients.
- Session and CSRF controls match the client type.

## Related Patterns

- API Gateway as Security Boundary.
- Object-Level Authorization Check.
- Tenant Context Propagation.
- Schema-First API Security.