Registrazione OAuth2 del client: redirect_uri dovrebbe essere univoco tra i client?

Non c'è davvero un buon modo per garantire in modo sicuro che un client sia quello che dice di essere, quindi non ha davvero senso cercare di rendere ogni URI di reindirizzamento univoco per un singolo client. L'unico motivo per cui si registrano gli URI è quello di impedire che lo scenario di reindirizzamento aperto menzionato nella documentazione, che renderebbe banale da dire, configurare un client malevolo a cui si effettua il reindirizzamento dopo l'autenticazione, consentendogli di mascherarsi come client benigno. Non risolve problemi come l'avvelenamento del DNS o le modifiche del file host.

Poiché non c'è modo di garantire che un client sia lo stesso richiedente dell'ultima volta che ha fatto una richiesta, a causa della natura stateless dei server HTTP, ciò significa che a lungo termine è necessario emettere un nonce ogni volta che il client desidera connettersi tramite un certo canale laterale sicuro e autorizzare la richiesta in questo modo. Per i clienti privati, ciò potrebbe anche essere impossibile, perché qualcuno potrebbe capire come farlo mediante il reverse engineering dell'applicazione che lo fa. Per i clienti pubblici, ciò sarebbe fattibile, ma aggiungerebbe ulteriore complessità e un piccolo ritardo per ogni richiesta.

Non esiste uno scenario che renda un vincolo univoco per il cliente più sicuro di quello che non ha una regola del genere, perché qualsiasi modo che potrebbe essere usato per bypassarne uno potrebbe anche essere usato per ignorare l'altro, aggiunge semplicemente uno strato di oscurità. Non sarebbe nemmeno banalmente rallentato un determinato aggressore nel caso di un cliente privato, e i client pubblici sono comunque protetti con altri mezzi (incluso un client secret , un tipo di password che solo quel client dovrebbe sapere).

Si noti che l'applicazione dell'unicità causa effettivamente una serie di problemi.

L'esempio più semplice è che stai limitando chi può usare https://localhost:8080/ su un singolo client. Qualsiasi altro cliente che tenta di utilizzare https://localhost:<port>/ dovrebbe giocare a un gioco di ipotesi con le porte per trovare un URI disponibile.

Inoltre, stai creando una forma di rivendicazione di un dominio facendo questo. A meno che tu non stia utilizzando qualcosa come ACME per far sì che i clienti posseggano effettivamente gli URI che stanno registrando, tu Stai permettendo a un cliente di rivendicare un URI che non possiede. Un client incurante (o malevolo) potrebbe registrarsi per URI come https://www.whitehouse.gov/oauth_redirect . Se reale % co_de arriva per registrare un URI, quel valore non è più disponibile e non c'è modo di togliere quell'URI dall'altra parte.

Tale collisione non è necessariamente un evento accidentale probabile tra diverse istituzioni, ma whitehouse.gov potrebbe registrare più client. Qui trovi altri problemi: se whitehouse.gov vuole passare da un client a un altro senza modificare un URI di reindirizzamento, non è in grado di farlo.

Vorrei anche esprimere una leggera preoccupazione generale sull'ipotesi che vedere un dato URI di reindirizzamento significhi definitivamente che il servizio sta interagendo con un cliente specifico. Nessuna assunzione del genere può o deve essere fatta.

Gli URI di reindirizzamento non devono essere, né dovrebbero essere, globalmente unici. Dovrebbero essere unici all'interno del profilo di un cliente. Gli URI di reindirizzamento non corrispondono necessariamente a un indirizzo fisico reale. Hanno semplicemente bisogno di essere capiti dal cliente e verificati dal server.

Gli ID cliente dovrebbero tuttavia essere globalmente unici.

Quando un client richiede un'autorizzazione, deve fornire il suo ID client e reindirizzare l'URI.

Se creo un'applicazione per browser client, il mio URI di reindirizzamento dello sviluppo sarà probabilmente qualcosa come link , non dovrebbe importare se qualcun altro ha usato lo stesso URI di reindirizzamento.