5. Considerazioni sulla sicurezza

Poiché le richieste all'endpoint di registrazione del client comportano la trasmissione di credenziali in testo in chiaro (nella richiesta e nella risposta HTTP), il server di autorizzazione DEVE richiedere l'uso di un meccanismo di sicurezza del livello di trasporto quando invia richieste all'endpoint di registrazione. Il server DEVE supportare TLS 1.2 [RFC5246] e PUÒ supportare meccanismi di sicurezza del livello di trasporto aggiuntivi che soddisfano i suoi requisiti di sicurezza. Quando si utilizza TLS, il client DEVE eseguire un controllo del certificato del server TLS/SSL, secondo la RFC 6125 [RFC6125]. Le considerazioni sulla sicurezza dell'implementazione possono essere trovate nelle Raccomandazioni per l'uso sicuro di TLS e DTLS [BCP195].

Per i client che utilizzano tipi di concessione basati sul reindirizzamento come "authorization_code" e "implicit", i server di autorizzazione DEVONO richiedere ai client di registrare i loro valori URI di reindirizzamento. Questo può aiutare a mitigare gli attacchi in cui attori canaglia iniettano e impersonano un client validamente registrato e intercettano il suo codice di autorizzazione o token tramite un URI di reindirizzamento non valido o un reindirizzatore aperto. Inoltre, al fine di prevenire il dirottamento dei valori di ritorno del reindirizzamento, i valori URI di reindirizzamento registrati DEVONO essere uno dei seguenti:

Un sito web remoto protetto da TLS (ad es., https://client.example.com/oauth_redirect)
Un sito web ospitato sulla macchina locale utilizzando un URI HTTP (ad es., http://localhost:8080/oauth_redirect)
Un URL specifico dell'applicazione non HTTP disponibile solo per l'applicazione client (ad es., exampleapp://oauth_redirect)

I client pubblici POSSONO registrarsi con un server di autorizzazione utilizzando questo protocollo, se la policy del server di autorizzazione lo consente. I client pubblici utilizzano un valore "none" per il campo metadati "token_endpoint_auth_method" e sono generalmente utilizzati con il tipo di concessione "implicit". Spesso questi client saranno applicazioni nel browser di breve durata che richiedono l'accesso alle risorse di un utente e l'accesso è legato alla sessione attiva di un utente sul server di autorizzazione. Poiché tali client spesso non hanno una memoria a lungo termine, è possibile che debbano registrarsi nuovamente ogni volta che l'applicazione browser viene caricata. Per evitare la conseguente proliferazione di identificatori client morti, un server di autorizzazione PUÒ decidere di far scadere le registrazioni per i client esistenti che soddisfano determinati criteri dopo che è trascorso un periodo di tempo. In alternativa, tali client potrebbero essere registrati sul server da cui viene servito il codice dell'applicazione nel browser e la configurazione del client potrebbe essere inviata al browser insieme al codice.

Poiché diversi tipi di concessione OAuth 2.0 hanno proprietà di sicurezza e utilizzo diverse, un server di autorizzazione PUÒ richiedere registrazioni separate per un software per supportare più tipi di concessione. Ad esempio, un server di autorizzazione potrebbe richiedere che tutti i client che utilizzano il tipo di concessione "authorization_code" utilizzino un segreto client per il "token_endpoint_auth_method" ma qualsiasi client che utilizza il tipo di concessione "implicit" non utilizzi alcuna autenticazione all'endpoint del token. In una tale situazione, un server PUÒ impedire ai client di registrarsi contemporaneamente per i tipi di concessione "authorization_code" e "implicit". Allo stesso modo, il tipo di concessione "authorization_code" viene utilizzato per rappresentare l'accesso per conto di un utente finale, ma il tipo di concessione "client_credentials" rappresenta l'accesso per conto del client stesso. Per motivi di sicurezza, un server di autorizzazione potrebbe richiedere l'uso di ambiti diversi per questi diversi casi d'uso e, di conseguenza, PUÒ impedire che questi due tipi di concessione vengano registrati insieme dallo stesso client. In tutti questi casi, il server di autorizzazione risponderebbe con una risposta di errore "invalid_client_metadata".

A meno che non sia utilizzato come claim in una dichiarazione software, il server di autorizzazione DEVE trattare tutti i metadati del client come auto-asseriti. Ad esempio, un client canaglia potrebbe utilizzare il nome e il logo di un client legittimo che sta cercando di impersonare. Inoltre, un client canaglia potrebbe tentare di utilizzare l'identificatore software o la versione software di un client legittimo per tentare di associarsi sul server di autorizzazione con istanze del client legittimo. Per contrastare ciò, un server di autorizzazione DEVE adottare misure appropriate per mitigare questo rischio esaminando l'intera richiesta di registrazione e la configurazione del client. Ad esempio, un server di autorizzazione potrebbe emettere un avviso se il dominio/sito del logo non corrisponde al dominio/sito degli URI di reindirizzamento. Un server di autorizzazione potrebbe anche rifiutare le richieste di registrazione da un identificatore software noto che richiede URI di reindirizzamento diversi o un URI client diverso. Un server di autorizzazione può anche presentare messaggi di avviso agli utenti finali sui client registrati dinamicamente in tutti i casi, specialmente se tali client sono stati registrati di recente o non sono stati considerati affidabili da alcun utente sul server di autorizzazione in precedenza.

In una situazione in cui il server di autorizzazione supporta la registrazione a client aperta, deve essere estremamente attento con qualsiasi URL fornito dal client che verrà visualizzato all'utente (ad es., "logo_uri", "tos_uri", "client_uri", e "policy_uri"). Ad esempio, un client canaglia potrebbe specificare una richiesta di registrazione con un riferimento a un download drive-by nel "policy_uri", invogliando l'utente a fare clic su di esso durante l'autorizzazione. Il server di autorizzazione DOVREBBE verificare se "logo_uri", "tos_uri", "client_uri", e "policy_uri" hanno lo stesso host e schema di quelli definiti nell'array di "redirect_uris" e che tutti questi URI si risolvano in pagine web valide. Poiché questi valori URI che sono destinati a essere visualizzati all'utente nella pagina di autorizzazione, il server di autorizzazione DOVREBBE proteggere l'utente da contenuti dannosi ospitati agli URL ove possibile. Ad esempio, prima di presentare gli URL all'utente nella pagina di autorizzazione, il server di autorizzazione potrebbe scaricare il contenuto ospitato agli URL, controllare il contenuto con uno scanner malware e un filtro blacklist, determinare se c'è o meno contenuto misto sicuro e non sicuro all'URL e altre possibili mitigazioni lato server. Si noti che il contenuto in questi URL può cambiare in qualsiasi momento e il server di autorizzazione non può fornire completa fiducia nella sicurezza degli URL, ma queste pratiche potrebbero aiutare. Per mitigare ulteriormente questo tipo di minaccia, il server di autorizzazione può anche avvisare l'utente che i link URL sono stati forniti da una terza parte, dovrebbero essere trattati con cautela e non sono ospitati dal server di autorizzazione stesso. Ad esempio, invece di fornire i link direttamente in un'ancora HTML, il server di autorizzazione può indirizzare l'utente a una pagina di avviso interstiziale prima di consentire all'utente di continuare verso l'URL di destinazione.

I client POSSONO utilizzare sia l'oggetto JSON diretto che la dichiarazione software codificata JWT per presentare i metadati del client al server di autorizzazione come parte della richiesta di registrazione. Una dichiarazione software è protetta crittograficamente e rappresenta i claim fatti dall'emittente della dichiarazione, mentre l'oggetto JSON rappresenta i claim auto-asseriti fatti direttamente dal client o dallo sviluppatore. Se la dichiarazione software è valida e firmata da un'autorità accettabile (come l'editore dell'API software), i valori dei metadati del client all'interno della dichiarazione software DEVONO avere la precedenza su quei valori di metadati presentati nell'oggetto JSON semplice, che potrebbero essere stati intercettati e modificati.

Come tutti i valori dei metadati, la dichiarazione software è un elemento auto-asserito dal client, anche se i suoi contenuti sono stati firmati digitalmente o MACati dall'emittente della dichiarazione software. In quanto tale, la presentazione della dichiarazione software non è sufficiente nella maggior parte dei casi per identificare completamente un pezzo di software client. Un token di accesso iniziale, al contrario, non contiene necessariamente informazioni su un particolare pezzo di software client ma rappresenta invece l'autorizzazione a utilizzare l'endpoint di registrazione. Un server di autorizzazione DEVE considerare la richiesta di registrazione completa, inclusa la dichiarazione software, il token di accesso iniziale e i valori dei metadati del client JSON, quando decide se onorare una determinata richiesta di registrazione.

Se un server di autorizzazione riceve una richiesta di registrazione per un client che non è destinato ad avere più istanze registrate contemporaneamente e il server di autorizzazione può dedurre una duplicazione della registrazione (ad es., utilizza gli stessi valori "software_id" e "software_version" di un altro client esistente), il server DOVREBBE trattare la nuova registrazione come sospetta e rifiutare la registrazione. È possibile che il nuovo client stia cercando di impersonare il client esistente per ingannare gli utenti e farsi autorizzare, o che la registrazione originale non sia più valida. I dettagli della gestione di questa situazione sono specifici per la distribuzione del server di autorizzazione e al di fuori dell'ambito di questa specifica.

Poiché un identificatore client è un valore pubblico che può essere utilizzato per impersonare un client all'endpoint di autorizzazione, un server di autorizzazione che decide di emettere lo stesso identificatore client a più istanze di un client registrato deve essere molto particolare riguardo alle circostanze in cui ciò si verifica. Ad esempio, il server di autorizzazione può limitare un determinato identificatore client ai client che utilizzano lo stesso flusso basato su reindirizzamento e gli stessi URI di reindirizzamento. Un server di autorizzazione NON DOVREBBE emettere lo stesso segreto client a più istanze di un client registrato, anche se viene emesso lo stesso identificatore client, altrimenti il segreto client potrebbe essere trapelato, consentendo a impostori malintenzionati di impersonare un client riservato.