Cloudflare Access

A cosa serve

Cloudflare Access protegge le route Admin dei domini Frontend e API e fornisce all'API un'assertion di identità verificabile.

sequenceDiagram
    participant U as Utente o service token
    participant A as Cloudflare Access
    participant API as API Worker
    participant P as Policy applicativa
    U->>A: richiesta a una route Admin
    A->>A: valuta policy e sessione
    A->>API: inoltra assertion firmata
    API->>API: verifica firma, issuer e audience
    API->>P: risolve identità e permessi
    P-->>U: risposta autorizzata o errore chiuso

Componenti che lo usano

La shell Admin, tutte le /admin/** dell'API, l'autenticazione browser umana e le letture automatizzate consentite tramite service token.

Dati e artefatti scambiati

Access inoltra una JWT assertion con claim di identità. L'API normalizza subject, tipo umano/service, email opzionale e display name, poi scarta l'evidenza grezza. Le credenziali del service token restano nel client protetto.

Autenticazione e autorizzazione

Access autentica. L'API autorizza tramite una mappa route-permesso e un AuthContext provider-neutral. Un umano owner può ricevere tutti i permessi; le service identity ricevono solo la lista configurata e non possono ottenere review editoriale o approvazione deployment produzione.

Cosa possiede il provider

Cloudflare possiede applicazione Access, policy, sessione, identity-provider integration, firma JWT e challenge.

Cosa possiede Architecture Coffee

L'API possiede verifica issuer/audience, normalizzazione identità, permessi, mapping delle route, CORS esatto e decisione finale. La disponibilità UI non concede autorità.

Operazioni automatiche, manuali e protette

La challenge e verifica JWT avvengono a ogni richiesta protetta. Creazione, modifica o rollback di applicazioni/policy Access sono operazioni manuali e separatamente autorizzate; il repository non le applica.

Fallimenti e comportamento fail-closed

Assertion mancante o invalida produce 401; provider/configurazione non autorevole produce 503; permesso assente produce 403. Non esiste fallback a token Admin legacy o autenticazione locale in produzione.

Verifiche operative

challenge senza sessione;
accesso umano autorizzato;
richiesta service token consentita e una negata;
firma, issuer e audience;
CORS con origine Frontend esatta e credenziali;
conferma che service identity non approvi o pubblichi.