Point de données supplémentaire provenant des journaux d’accès nginx :
Un échec représentatif (2026-01-25 11:44:10 UTC) montre que la requête de rappel OIDC provient d’un UA de navigateur intégré iOS (Snapchat), et non de l’UA de la vue web de l’application iOS Discourse :
GET /auth/oidc/callback?...state=... 302
UA: Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X) ... Snapchat/13.76.1.0 (like Safari/..., panda)
Referer: https://login.microsoftonline.com/
Immédiatement suivi par :
GET /auth/failure?message=csrf_detected&strategy=oidc
Il semble donc que le flux OAuth soit parfois initié à l’intérieur d’un navigateur intégré iOS (Snapchat/autre),
puis que le transfert se produise (j’ai également vu des journaux contenant auth_redirect=discourse://auth_redirect),
et que le cookie de session/l’état ne survivent pas de manière cohérente.
Paramètre actuel : SiteSetting.same_site_cookies = "Lax".
Question : le flux d’authentification de l’application mobile de Discourse est-il censé être fiable lorsque la connexion est initiée à partir de navigateurs intégrés iOS qui effectuent ensuite un lien profond vers l’application Discourse ?
Le passage de same_site_cookies à « None » serait-il la mitigation recommandée, ou existe-t-il une meilleure approche ?