auth doc

docs/DEVELOPER-GUIDE.md

@@ -962,6 +962,46 @@ User sees application (authenticated)
 
 ---
 
+### Accessing Authenticated User Information
+
+The auth sidecar handles all authentication before requests reach your application. Your app never sees unauthenticated traffic — the sidecar returns 401 or redirects to the IdP first.
+
+After successful authentication, the sidecar forwards the request to your application with user identity injected as HTTP headers:
+
+| Header | Description | Available in |
+|--------|-------------|-------------|
+| `X-Auth-User` | Username or display name | Token, OIDC, MCP |
+| `X-Auth-Email` | User email address | OIDC |
+| `X-Auth-Subject` | OIDC `sub` claim (stable user ID) | OIDC, MCP |
+| `X-Auth-Groups` | Comma-separated group memberships | OIDC (if scope includes `groups`) |
+| `X-Auth-Token` | The validated access token | All modes |
+
+**Your application reads these headers — no auth library needed:**
+
+```javascript
+// Express.js example
+app.get('/profile', (req, res) => {
+  const user = req.headers['x-auth-user'];
+  const email = req.headers['x-auth-email'];
+  res.json({ user, email });
+});
+```
+
+```python
+# Flask example
+@app.route('/profile')
+def profile():
+    user = request.headers.get('X-Auth-User')
+    email = request.headers.get('X-Auth-Email')
+    return jsonify(user=user, email=email)
+```
+
+**Why this is safe**: The Kyverno-generated NetworkPolicy restricts ingress to the sidecar port only. Traffic cannot bypass the sidecar to reach the application port directly, so the `X-Auth-*` headers can be trusted unconditionally.
+
+**Key principle**: Your application is zero-trust-unaware by design. It reads headers and renders UI. All authentication complexity lives in the sidecar and Kyverno policy.
+
+---
+
 ### Authentication Configuration Reference
 
 #### Helm Values Schema

docs/REFERENCE.md

@@ -1516,7 +1516,23 @@ Forward to Application (localhost:3000)
 Application processes request
 ```
 
-**See**: [Developer Guide - Enabling Authentication](DEVELOPER-GUIDE.md#enabling-authentication-for-applications) for usage examples.
+#### Forwarded Headers
+
+After successful authentication, the sidecar injects user identity as HTTP headers before forwarding the request to the application container:
+
+| Header | Description | Auth Modes |
+|--------|-------------|------------|
+| `X-Auth-User` | Username or display name | Token, OIDC, MCP |
+| `X-Auth-Email` | User email address | OIDC |
+| `X-Auth-Subject` | OIDC `sub` claim (stable user ID) | OIDC, MCP |
+| `X-Auth-Groups` | Comma-separated group memberships | OIDC (if `groups` scope) |
+| `X-Auth-Token` | The validated access token | All modes |
+
+These headers are trustworthy because the auto-generated `NetworkPolicy` restricts pod ingress to the sidecar port only — external traffic cannot reach the application container directly, so headers cannot be spoofed.
+
+Applications should read these headers to obtain authenticated user information (e.g. for display, authorisation decisions, or audit logging) instead of implementing their own authentication.
+
+**See**: [Developer Guide - Accessing Authenticated User Information](DEVELOPER-GUIDE.md#accessing-authenticated-user-information) for code examples.
 
 ---