Quali parti di Oauth 2.0 devono possedere una connessione SSL?Le app client Oauth2 devono avere una connessione SSL?
Il server di autorizzazione è necessario per utilizzare SSL/TLS come per la specification, ad esempio:
Poiché le richieste al risultato autorizzazione endpoint in autenticazione utente e la trasmissione delle credenziali in chiaro (nella risposta HTTP , il server di autorizzazione DEVE richiedere l'uso di TLS come descritto nella Sezione 1.6 quando si inviano richieste all'endpoint di autorizzazione .
Poiché le richieste per il risultato finale di token nella trasmissione di credenziali in chiaro (nella richiesta HTTP e la risposta), il server autorizzazione deve richiedere l'uso di TLS, come descritto nella sezione 1.6 per l'invio di richieste al punto finale del token.
non Quella stessa specifica fa richiede per l'applicazione client, ma pesantemente raccomanda:
L'endpoint reindirizzamento dovrebbe richiedere l'uso di TLS come descritto nella sezione 1.6, quando la risposta richiesta type è "code" o "token", o quando la richiesta di reindirizzamento comporterà la trasmissione delle credenziali sensibili su una rete aperta. Questa specifica fa sì che non imponga l'utilizzo di TLS perché al momento della stesura di questo documento, che richiede ai client di distribuire TLS rappresenta un ostacolo significativo per molti sviluppatori di client . Se TLS non è disponibile, il server di autorizzazione DOVREBBE avvisare il proprietario della risorsa dell'endpoint non sicuro prima del reindirizzamento (ad esempio, visualizza un messaggio durante la richiesta di autorizzazione ).
La mancanza di sicurezza del livello di trasporto può avere un grave impatto sulla sicurezza del client e sulle risorse protette autorizzate per l'accesso a . L'uso della sicurezza a livello di trasporto è particolarmente importante quando il processo di autorizzazione viene utilizzato come forma di autenticazione utente finale delegata dal client (ad esempio, il servizio di accesso di terze parti ).
chiamate al server risorsa contengono il token di accesso e richiedono SSL/TLS:
accedere alle credenziali del token (così come qualsiasi accesso confidenziale gettone attributi) devono essere mantenuti confidenziali durante il trasporto e lo stoccaggio, e condivisi solo tra il server di autorizzazione, i server di risorse il token di accesso è valido per e il client a cui è rilasciato il token di accesso è .Le credenziali dei token di accesso DEVONO essere trasmesse solo utilizzando TLS come descritto nella Sezione 1.6 con l'autenticazione del server come definito da [RFC2818].
Le ragioni dovrebbero essere piuttosto ovvi: in nessuno di questi non viene utilizzato il trasporto sicuro, il token può essere intercettato e la soluzione non è sicura.
La domanda specifica chiama l'applicazione client.
App client: è davvero necessario, purché utilizzi SSL per la comunicazione del server delle risorse?
Suppongo che il client sia un'applicazione Web e si sta parlando della comunicazione tra il browser e il server dopo che è avvenuta l'autenticazione. Suppongo inoltre che tu poni la domanda, perché (nella tua implementazione), questa comunicazione non è autenticata con i token di accesso, ma attraverso altri mezzi.
E lì avete la risposta: quella comunicazione è autenticata in un modo o nell'altro. In quale altro modo il server dovrebbe sapere chi sta effettuando la chiamata? La maggior parte dei siti Web utilizza un cookie di sessione impostato all'inizio della sessione e li utilizza per identificare la sessione e quindi l'utente. Chiunque possa prendere quel cookie di sessione può dirottare la sessione e impersonare l'utente. Se non lo vuoi (e davvero non dovresti volerlo), devi usare SSL/TLS per proteggere la comunicazione tra il browser e il server.
In alcuni casi, la parte browser del client comunica direttamente con il server di risorse; e la parte server serve solo contenuto statico, come HTML, CSS, immagini e, last but not least, JavaScript. Forse il tuo cliente è costruito in questo modo e ti stai chiedendo se il contenuto statico deve essere scaricato su SSL/TLS? Bene, se non lo è, un uomo nel mezzo può inserire il proprio codice JavaScript malvagio, che ti ruba i token di accesso dell'utente. Vuoi proteggere il download di contenuto statico.
Ultimo ma non meno importante, la tua domanda si basa su un'ipotesi nascosta, che ci potrebbero essere validi motivi per non utilizzare SSL/TLS. Spesso le persone dichiarano che il costo del certificato è troppo alto, o la crittografia richiede troppa potenza della CPU, quindi richiede più hardware per eseguire l'applicazione. Non credo che questi costi siano significativi in quasi tutti i casi. Sono molto bassi, rispetto al costo totale di costruzione e gestione della soluzione. Sono anche molto bassi rispetto ai rischi di non utilizzare la crittografia. Non perdere tempo (e denaro) a discuterne, basta usare SSL/TLS fino in fondo.
Quindi la mia estensione alla domanda è che, poiché l'utente è autenticato solo nelle visite successive se entrano utilizzando SSL, è consigliabile forzare semplicemente un sito MVC a richiedere sempre SSL? – pcbliss
@pcbliss Sì. (A PARER MIO) –