Continuando la discussione da OIDC login via Discourse iOS app occasionally fails with csrf_detected on callback:
Ciao a tutti,
Questa è un’osservazione di follow-up collegata al mio thread precedente sui fallimenti di accesso OIDC avviati dai browser in-app di iOS. Quella discussione si è concentrata sui fallimenti deterministici di csrf_detected causati dall’isolamento dei cookie di WKWebView, che ora sono ben compresi e previsti.
Questo argomento collegato riguarda la chiarezza per gli operatori, non un bug.
Osservazione
Mentre indagavo su una serie di fallimenti di accesso OIDC, ho notato che la stessa superficie di errore in Discourse:
/auth/oidc/callback → /auth/failure?message=csrf_detected
può corrispondere a cause principali molteplici e fondamentalmente diverse, a seconda di ciò che l’IdP (Identity Provider) ha restituito.
Dalla sola interfaccia utente dell’applicazione, questi casi sono indistinguibili. La differenza è visibile solo ispezionando Admin → Logs → env / params.
Esempi visti in pratica (Azure / Entra ID)
Oltre alla perdita di cookie del browser in-app, ho osservato callback in cui Entra ID restituisce esplicitamente errori strutturati come:
L’utente ha rifiutato il consenso
error=consent_required
error_description=AADSTS65004: User declined to consent to access the app
L’utente ha annullato l’accesso
error=access_denied
error_subcode=cancel
In entrambi i casi:
- Azure ha identificato correttamente l’utente
- L’utente ha scelto esplicitamente di non procedere (rifiuto / annullamento)
- Discourse riceve il callback
- Il flusso si risolve infine in
/auth/failure?message=csrf_detected
Dal punto di vista di Discourse, questo è un comportamento corretto e sicuro: lo stato non può essere convalidato o completato, ma la ragione sottostante è molto diversa da un cookie di sessione mancante.
Perché è importante per gli operatori
Senza controllare l’env/params nei log, un amministratore che vede ripetuti fallimenti di csrf_detected può ragionevolmente supporre:
- cookie non funzionanti
- errata configurazione di SameSite
- problemi del browser mobile
- instabilità dell’IdP
…quando in realtà, alcuni di questi fallimenti sono semplicemente utenti che scelgono di non acconsentire o annullano il prompt di Microsoft.
Questa distinzione diventa chiara solo se si sa già di dover ispezionare il payload grezzo del log.
Suggerimento (solo documentazione / UX)
Non sto suggerendo alcun cambiamento comportamentale a OmniAuth o alla gestione di CSRF.
Potrebbe essere utile se la documentazione o le guide alla risoluzione dei problemi notassero esplicitamente che:
csrf_detectedpuò essere l’errore finale per molteplici esiti dell’IdP a monte- inclusi azioni esplicite dell’utente come annullamento o rifiuto del consenso
- e che gli amministratori dovrebbero ispezionare Admin → Logs → env / params per distinguere questi casi
Ciò renderebbe più facile per gli operatori:
- diagnosticare correttamente i fallimenti di accesso
- evitare modifiche di configurazione non necessarie
- e fornire agli utenti indicazioni accurate (“hai annullato / hai rifiutato il consenso” rispetto a “il tuo browser ha bloccato i cookie”).
Contesto
Per chiarezza: questo è separato dal problema confermato del browser in-app di iOS discusso nell’argomento collegato. In quel caso, l’IdP non raggiunge mai il punto del consenso dell’utente, mentre qui l’IdP riporta esplicitamente l’intento dell’utente.
Entrambi appaiono simili a livello di interfaccia utente a meno che non vengano esaminati i log.
Grazie per la lettura - pubblico questo principalmente come punto di chiarezza documentale/punto di dati per altri che gestiscono OIDC in ambienti con molti studenti, dove questi casi si verificano frequentemente.
Sono disponibile a fornire esempi anonimizzati se utile.