[Task](greenhouse): Greenhouse Authentication Provider for Cross-Plugin Token Sharing

[ArtieReus]

Task Description

Conduct a comprehensive security review of the @cloudoperators/greenhouse-auth-provider package that
enables authentication state sharing between the Greenhouse shell application and embedded
micro-frontend plugins (e.g., Heureka). This review should assess the security posture of JWT token
handling, trust boundaries, and cross-plugin authentication in our micro-frontend architecture.

Implementation PR: #1471
Package Location: /packages/greenhouse-auth-provider
Example Integration: /apps/heureka

Sub-tasks

• Review token handling and storage mechanism (in-memory snapshot pattern)
• Validate trust boundary enforcement between shell (trusted) and plugins (untrusted)
• Assess state synchronization pattern for race conditions and timing vulnerabilities
• Evaluate cross-plugin token access and scoping requirements
• Analyze XSS and injection attack surface
• Review standalone mode security implications (currently not implemented)
• Conduct threat modeling session for micro-frontend authentication patterns
• Perform penetration testing of plugin isolation boundaries
• Document secure plugin development guidelines
• Provide recommendations for security improvements (CSP headers, token rotation, audit logging,
  etc.)

Security-Critical Aspects

1. Token Handling & Storage

• JWT tokens passed in-memory via snapshot pattern
• No localStorage/sessionStorage persistence
• Tokens included in AuthState objects: { status: "authenticated", token: string, userId: string, userName: string }

Questions:

• Is in-memory token storage sufficient?
• Should tokens be stored separately from user metadata?

2. Trust Boundary Model

• Shell (Trusted): Owns AuthStore with setAuthState() method
• Plugins (Untrusted): Receive read-only EmbeddedAuth interface with only getSnapshot() method
• Plugins explicitly stripped of setAuthState before receiving auth object

Questions:

• Is the trust boundary adequately enforced at TypeScript type level?
• Could malicious plugins bypass the read-only interface?
• Should we add runtime validation to prevent privilege escalation?

3. State Synchronization Pattern

• Shell remounts plugins when auth state changes
• getSnapshot() returns shallow copy ({ ...state }) on each call

Questions:

• Is shallow copying sufficient for preventing state mutation attacks?

4. Cross-Plugin Token Access

• All embedded plugins receive the same authentication state
• No plugin-specific scoping

Questions:

• What happens if one plugin is compromised?

5. XSS & Injection Attack Surface

• Tokens accessible via useAuth() hook in plugin components
• Plugins run arbitrary JavaScript in same origin as shell

Questions:

• What protections exist against XSS stealing tokens from compromised plugins?
• Should we implement Content Security Policy (CSP) headers?
• How do we mitigate supply chain attack risks in plugin dependencies?

Architecture Summary
┌─────────────────────────────────────┐
│ Greenhouse Shell (Trusted) │
│ - createAuthStore() │
│ - setAuthState({ token, user }) │
│ - Manages login/logout │
└────────────┬────────────────────────┘
│ passes { getSnapshot }
↓
┌─────────────────────────────────────┐
│ Plugin (Heureka, etc.) - Untrusted │
│ │
│ useAuth() → { token, userId } │
│ │
└─────────────────────────────────────┘

Key Security Questions for Review

1. Is the snapshot-based pattern secure for handling JWTs in micro-frontends?
2. Should we add token encryption at rest (even in memory)?
3. Do we need audit logging for authentication state changes?
4. What security headers/policies should we enforce?
5. Is the shallow copy in getSnapshot() sufficient, or should we deep-freeze objects?
6. What threat model should we use for evaluating plugin compromise scenarios?

Related Issues

• Epic [EPIC](greenhouse): Authentication - shared Authentication Context for Shell and Plugins #1397: Authentication - shared Authentication Context for Shell and Plugins
• Implementation PR: chore(greenhouse): add greenhouse-auth-provider package #1471 (merged, 2 approvals, 16 checks passed)

Additional Context

Testing Gaps:

• No penetration testing for token theft scenarios
• No validation of plugin isolation guarantees
• No fuzzing of state synchronization edge cases

Documentation:

• Package README: /packages/greenhouse-auth-provider/README.md
• Shell implementation: createAuthStore.ts - stores auth state and provides snapshot access
• Plugin implementation: AuthProvider.tsx - wraps plugins with read-only auth context
• Auth contract: auth-contract.ts - defines AuthState and EmbeddedAuth interfaces

Labels: security, authentication, architecture-review, greenhouse, micro-frontend
Priority: High (authentication is foundational security control)