Penso che quello che stai descrivendo qui sia il flussi “Implicit Flow” di OpenID Connect, che funziona senza alcuna comunicazione server-server e, pertanto, non necessita di un segreto condiviso. Invece, tutte le informazioni vengono trasmesse tramite i reindirizzamenti HTTP e l’ID token viene verificato crittograficamente utilizzando le chiavi pubbliche dal Discovery Document.
Va bene, e penso che sia una richiesta di funzionalità valida. Ma è un sistema molto diverso dal nostro plugin attuale, che utilizza il flusso di codice di autorizzazione. Questo flusso utilizza la comunicazione server-server con un segreto condiviso e, pertanto, non è necessaria alcuna verifica crittografica dell’id_token. Questo è più semplice per certi versi, ma più complesso per altri.
Importante: non possiamo semplicemente cambiare l’implementazione predefinita nel plugin. I siti che utilizzano il flusso di codice di autorizzazione devono continuare a utilizzarlo. IIRC molti provider di identità non supportano nemmeno l’Implicit Flow.
Quindi penso che ci siano due strade da percorrere qui:
-
Aggiungiamo il supporto per l’“implicit flow” nel plugin OIDC, ma rendiamolo una cosa opt-in. Penso sia improbabile che accettiamo una PR che introduca la gemma openid-connect come dipendenza di Discourse core, quindi dovrebbe essere implementata all’interno della nostra strategia attuale.
Il plugin discourse-lti (learning tools integration) potrebbe essere una fonte utile di ispirazione, perché il protocollo LTI si basa sull’implicit flow OIDC. La logica di decodifica dell’id_token è qui
o in alternativa
-
Costruisci l’implicit flow come un plugin completamente nuovo. In questo caso, saresti libero di fare quello che vuoi in termini di implementazione (ma dovresti anche mantenerlo tu stesso)