Qual è il punto del segreto del client in OAuth2 se non è necessario utilizzarlo?

Esistono numerosi tipi di sovvenzioni supportati da OAuth 2.0 e consentono all'applicazione client di interagire con un server di risorse per conto del proprietario della risorsa in modi diversi.

Ci sono implicazioni sulla sicurezza nell'usare una sovvenzione implicit , che è il tipo che non richiede un segreto client. In particolare, in questo flusso di autorizzazione, il client (poiché non vi è alcun segreto client) dipende interamente dal proprietario della risorsa (l'utente con il browser, in generale) per ottenere, presentare e conservare il token di accesso. Ciò aumenta significativamente la barra richiesta per proteggere il token (non si può davvero avere un'applicazione che si basa su questo tipo di sovvenzione che non è completamente protetta da TLS / HTTPS) e c'è il rischio aggiuntivo che il token venga rubato e usato impropriamente senza l'applicazione del client conoscenza. A causa di questi rischi aggiuntivi, RFC raccomanda espressamente che non si basino su concessioni implicite a meno che non sia necessario.

Se la tua applicazione ha la capacità di proteggere adeguatamente un segreto del client, si consiglia di utilizzare invece il tipo di sovvenzione authorization code . Ciò consente al flusso di autorizzazione di essere gestito tramite l'applicazione e rimuove il requisito per il proprietario della risorsa di gestire il processo di autorizzazione esternamente e in modo opaco al client. Ciò significa che il cliente può proteggere anche i token di accesso e non deve fare affidamento sugli utenti per tenerli al sicuro.

Quindi, il segreto del cliente non è un'opzione estranea. È parte integrante dell'opzione preferita. Il tipo di sovvenzione implict che non richiede un segreto client è semplicemente l'ultima risorsa per le applicazioni client che non hanno la possibilità di implementare un'opzione migliore.

Non ho letto le specifiche così sto facendo delle supposizioni qui ma potrebbe permetterti di supportare i client di base e differenziarti a seconda che il client ti invii un client_secret oppure no. Ad esempio, è possibile imporre una regola di scadenza più rigida sul token di richiesta che si invia al client se non ti invia un client_secret.

I segreti privati come il client_secret OAuth funzionano solo se puoi fidarti dell'altra parte nella catena per mantenere la segretezza di tali informazioni. Quindi questa regola significa che se il client non è in grado di mantenere la segretezza, dovrebbe renderlo chiaro al server non fornendo il client_secret. La conseguenza di questa regola è che se un client ti invia un client_secret, significa che deve essere in grado di garantire la segretezza e puoi fidarti di farlo. Dal punto di vista del server, significa che sai se il cliente può mantenere la segretezza e quindi adattare di conseguenza la politica di sicurezza. Non devi farlo, ma puoi.