# =============================================================================
# COMPETENCY RECORD - Cedric Ancellin's demonstrated engineering skills and
# experience. Third-party technologies and vendors are named as the concrete
# skill surface. Professional background / track record.
# =============================================================================

# ============================================================
# IDENTITY & AUTHENTICATION - COMPETENCY RECORD
# ============================================================
# Core Purpose:
#   Demonstrated experience building authentication and identity:
#   an OAuth authorization server, SAML 2.0 SSO, passwordless/
#   passkey auth, OIDC brokering, multiple API-key types, a full
#   session lifecycle, elevated-access controls, and hardening.
# ============================================================

summary: >
  Designed and built the platform's authentication and identity
  system, including acting as an OAuth authorization server that
  issues tokens to third parties, inbound SAML 2.0 SSO, passwordless/
  passkey authentication, OIDC brokering, social OAuth, four
  auto-detected API-key types, a complete session lifecycle, a
  hierarchical multi-tenant access model, gated elevated access,
  and hardening against brute-force and timing attacks.


# ==================================================================
# 1. OAUTH AUTHORIZATION SERVER (PLATFORM AS PROVIDER)
# ==================================================================

oauth_provider:
  description: >
    Built the platform's own OAuth authorization server so
    third-party applications can integrate against it.
  capabilities:
    - "Authorization-code issuance with client-id / redirect-uri validation."
    - "Bearer-token generation (hashed, expiring), and token revocation."
    - "Provider / connection / token persistence and reference client implementations."
  skill_signal: "Implementing the provider side of OAuth (issuing and managing tokens), not merely consuming a third-party OAuth flow."


# ==================================================================
# 2. FEDERATED IDENTITY (SAML / OIDC / SOCIAL / PASSWORDLESS)
# ==================================================================

federation:
  description: >
    Integrated a full spread of federated and modern auth methods.
  methods:
    saml_sso: "Inbound SAML 2.0 SSO via an industry SAML library (SAMLResponse processing, NameID extraction, per-provider configs, session + XSRF mint on success, email-domain rewrite)."
    oidc_brokered: "OIDC / OAuth via a hosted identity broker using a PKCE flow, with cache-stored PKCE state and secrets from a cloud secrets manager."
    social_oauth: "Direct Google and Microsoft OAuth code-verification flows minting platform sessions."
    passwordless: "Passwordless / passkey authentication via a managed passkey provider, at platform and venue scope."
    password: "Email + password with verified hashing."
    social_token: "Social-provider token exchange with graph validation."
    key_login: "Direct key-based login for services and partners."
  enterprise_fit: "Customer MFA and access policy inherited from the customer's own identity provider."


# ==================================================================
# 3. MULTI-TYPE API-KEY AUTHENTICATION
# ==================================================================

api_keys:
  description: >
    Designed an auth model where the key format self-describes its
    type, auto-detected at the request entry point.
  types:
    account: "Enterprise/account-scoped key (e.g., server-side widget proxy traffic)."
    user: "User-scoped key."
    session: "Browser session token with CSRF enforcement."
    login: "Auth-flow-only key for services and partner integrations."
  encoding: "The leading digit encodes the key type; the remainder encodes the record ID (see COMP-02)."


# ==================================================================
# 4. SESSION LIFECYCLE
# ==================================================================

sessions:
  description: >
    Built the full session lifecycle from login through refresh to
    termination.
  lifecycle:
    creation: "Login assembles a full session context (identity, permissions, tenant/venue mappings, access matrix)."
    storage: "Durable session storage with a cache-tier copy (TTL-bounded); cache rebuilds from durable storage on miss."
    loading: "Session context loaded and exposed to business logic on every authenticated request."
    refresh: "Activity timestamp updated per request with a short debounce to avoid write contention/deadlocks."
    termination: "Logout clears durable + cache session state and marks the session closed."
  seamless_reauth: "A session-code path enables re-authentication without spawning duplicate sessions."


# ==================================================================
# 5. MULTI-TENANT ACCESS & ELEVATED ACCESS
# ==================================================================

access_model:
  hierarchy: "System (product platform) → account (tenant) → venue → per-feature access, resolved into the session at login."
  elevated_access:
    - "Super-admin auto-elevation only via verified hosted-identity login, password login can never grant it."
    - "PII visibility remains separately gated even for super-admins (see COMP-07)."
    - "Invite processing auto-provisions membership/venue mappings on first authenticated login."


# ==================================================================
# 6. AUTH HARDENING
# ==================================================================

hardening:
  measures:
    brute_force: "Cache-based escalating lockout (tiered cooldowns with an admin alert at the top tier)."
    timing_attacks: "Dummy hash verification on unknown users to normalize response timing."
    password_reset: "Reset-state accounts are blocked from login and routed to a reset flow."
    csrf: "Rotating XSRF tokens on every response (see COMP-08 for the frontend lifecycle)."
  cross_reference:
    $ref: "https://zc8.com/competencies/07_security_engineering"


# ==================================================================
# 7. DELEGATED VERIFICATION + SELF-MINTED SESSIONS (SEPARATE PLATFORM)
# ==================================================================

delegated_auth:
  description: >
    On a separate platform (see COMP-21), designed an auth model
    that cleanly splits credential verification from session
    management, two concerns, two systems.
  segregation:
    verification_only: "A delegated identity provider (Supabase) verifies OAuth credentials and returns a verified email statelessly; its cookies are NEVER written to the browser."
    self_minted_sessions: "The application mints and owns its own JWTs; the provider's session is discarded immediately after reading the email (throwaway clients with empty set()/remove()) to prevent a competing SSR cookie-refresh cycle."
    provider_agnostic_ui: "UI never listens to provider-specific auth events, so alternate login paths (e.g. a developer bypass) behave identically."
  two_token_model:
    pending_registration: "Proves an email was OAuth-verified before a user record exists, powers a fully stateless invite/registration path. aud=pending_registration, no subject, 1h expiry."
    full_session: "Normal authenticated session, aud=authenticated, subject=user id, 7d expiry."
  wire_identity_discipline:
    - "Identity is never carried in a forgeable custom header (e.g. x-user-id); every authenticated endpoint resolves the caller from a verified JWT (a NestJS guard populating req.user)."
    - "Delegated action ('on behalf of', mods, clan officers) is an explicit, server-verified body field, keeping 'who is calling' distinct from 'who owns the resource.'"
  note: "Contrast with sections 1–6 above (the platform acting as its OWN OAuth authorization server); here the platform is the OAuth consumer but still owns 100% of session state."