Perché non viene incoraggiata PKCE per le app a pagina singola?

Le SPA non beneficerebbero di PKCE. PKCE risolve un problema diverso da quello che stai descrivendo.

Prima di tutto, per SPAs la best practice corrente deve ancora utilizzare il flusso implicito , non il flusso del codice di autorizzazione. Con il flusso implicito, il token di accesso è incluso nel frammento di hash (#) dell'URI di reindirizzamento anziché in un componente di query (?). Poiché il browser non include mai la porzione di frammento hash di un URI quando fa una richiesta, il token non viene visualizzato nella cronologia , web log ...

Quando si tratta di app native , rfc8252 sezione 6 dice che di seguito:

Public native app clients MUST implement the Proof Key for Code Exchange (PKCE RFC7636])

Nota a margine, si noti che il requisito PKCE è per client nativi pubblici . Ci si potrebbe chiedere come sia possibile che un'app nativa non sia pubblica. La risposta è nella sezione 8.4 :

Except when using a mechanism like Dynamic Client Registration [RFC7591] to provision per-instance secrets, native apps are classified as public clients

Non sono esattamente sicuro di come fare riferimento a questi client poiché non ho mai visto client nativo riservato menzionato ovunque. Forse client nativo non pubblico funziona:)

Per rispondere alla tua domanda: perché il flusso di codice di autorizzazione con PKCE è richiesto per le app native native e non per le SPA?

La logica è la seguente:

1. Uno degli scopi principali di OAuth2 è impedire l'esposizione delle credenziali dell'utente ai client.
2. Affinché le app native soddisfino questo requisito, l'utente non deve immettere le credenziali ovunque l'app nativa abbia accesso. Pertanto è necessario evitare schermate di accesso nativi e visualizzazioni Web.
3. La soluzione è che le app native lanciano un agente utente esterno (vedi rfc8252 appendice B ) dove l'utente si autenticherà con il server di autorizzazione e autorizzerà l'applicazione. Le app native non hanno accesso all'agente utente esterno, quindi le credenziali dell'utente sono sicure.
4. Tuttavia, è stata introdotta una nuova complicazione che non esisteva con ZPS: l'agente utente esterno deve ora comunicare la risposta del server di autorizzazione all'app nativa? La risposta è la comunicazione tra le app (vedi sezione 5 e sezione 7 )
5. Purtroppo, diversi tipi di comunicazioni tra le app possono essere intercettate da app di terze parti dannose! Con il flusso implicito, ciò significa che il token di accesso potrebbe essere rubato da un'app dannosa, il che sarebbe una cosa molto brutta. Questo è uno dei motivi principali per cui il flusso implicito non viene utilizzato per le app native.
6. Tuttavia, anche se viene utilizzato il flusso del codice di autorizzazione, l'app maliziosa di terze parti può ancora intercettare il codice di autorizzazione e utilizzarlo per ottenere un token di accesso poiché non vi è alcun segreto del client. Quindi sembra inutile utilizzare il flusso del codice di autorizzazione invece del flusso implicito per le app native native.
7. È qui che entra in gioco PKCE. PKCE fa in modo che anche se un'app dannosa intercetta un codice di autorizzazione, non sarà in grado di scambiarlo con un token di accesso. Ciò si ottiene richiedendo all'entità che richiede il token di accesso di dimostrare che si tratta della stessa entità che ha richiesto il codice di autorizzazione in primo luogo.

Spero che ora capisca perché:

Le SPA non trarrebbero alcun vantaggio da PKCE poiché con SPAs tutto avviene all'interno del browser. PKCE è utile solo quando c'è comunicazione tra le app.
• Le app native native non devono utilizzare il flusso implicito perché a volte le comunicazioni tra le app possono essere non sicure.
• Le app native native devono utilizzare il flusso del codice di autorizzazione + PKCE

Ecco un buon post sul blog che può fornire maggiori informazioni: link