OAuth 2.0 con webhooks

Sto implementando un flusso di tipo OAuth2 usando webhook tra due webservices (nessun browser / user-agent coinvolto). Il server di autenticazione concederà l'accesso in base all'URL del webhook al quale deve essere restituito il risultato.

È (attualmente) basato sul flusso "implicito" - gli stessi parametri, passati solo usando corpi di richieste POST invece di query / frammenti e reindirizzamenti.

Quindi la domanda è: quali (se esistono) problemi di sicurezza per il flusso "implicito" di OAuth (in particolare rispetto ad altri flussi) si applicherebbero ancora a questa configurazione?

                                             +----------------+
                                             | Resource owner |
                                             +----------------+
                                                    ^
                                                    |
                                             (B) Approves access/scope
                                                    |
                                                    v
+--------+                                  +----------------------+
|        +----(A) Authorization Request --->|                      |
| Client |                                  | Authorization server |
|        +<---(C) Access Token Response ----|                      |
+--------+                                  +----------------------+

I passaggi A e C sono webhook. Le richieste POST hanno risposto immediatamente (probabilmente con stato 202 Accepted ).

I parametri sono tratti dalle sezioni 4.2.1 e 4.2.2 di RFC 6749, eccetto che redirect_uri è sostituito da webhook_uri , e response_type è cambiato da "token" a "webhook" .

Ecco una richiesta di esempio del server all'indirizzo link che cerca di ottenere un token da link , chiedendo di inviare la risposta al link :

POST /auth HTTP/1.1
Host: foo.com
Content-Type: application/x-www-form-urlencoded

response_type=webhook&webhook_uri=https%3A%2F%2Fbar.com%2Fwebhook
&client_id=https%3A%2F%2Fbar.com%2F&state=b2dZnjdZQdmxwvMbibS6vQ

Una volta approvato, viene fornita la risposta:

POST /webhook HTTP/1.1
Host: bar.com
Content-Type: application/x-www-form-urlencoded

access_token=...&token_type=bearer&expires_in=86400
&state=b2dZnjdZQdmxwvMbibS6vQ

(Gli errori vengono gestiti in modo simile, utilizzando i parametri della sezione 4.2.2.1 )

Note:

• L'alternativa ovvia è implementare qualcosa di più simile al flusso del "codice di autorizzazione", in cui la risposta del webhook contiene un codice di autenticazione che viene poi scambiato con un token di accesso.
  • Supponendo il corretto utilizzo del parametro state (in particolare che contiene un valore non ipotizzabile come indicato nella sezione 10.12 ), ci sono dei vantaggi in questo?
• Uno dei motivi per cui il flusso "implicito" è considerato meno sicuro è che il token di accesso è trasportato dal browser dell'utente (nel frammento) e può essere trapelato tramite la cronologia del browser o un altro comportamento imprevisto. Dato che qui il token viene inviato da server a server, non penso che questo sia valido.
• Un'altra ragione per cui il flusso "implicito" è considerato problematico è che le web-app spesso (erroneamente) presumono che se finiscono con un token di accesso valido per un utente su un sito di terze parti, allora possono trattare quell'utente come "loggato" sull'app web. Tuttavia, se un utente malintenzionato ottiene un token di accesso per un utente (anche uno con permessi insignificanti, facendo in modo che l'utente "acceda" al sito dell'attore ), può utilizzare questo token per impersonare l'utente l'app web.
  • In primo luogo, non penso che ci sia un modo per un utente malintenzionato di fornire i propri token di accesso come quello nella configurazione del webhook. Senza conoscenza di state , l'utente malintenzionato non può far sembrare che il suo token di accesso provenga dal server di autorizzazione. (Al contrario, il reindirizzamento del browser consente all'utente malintenzionato di manomettere i parametri / token di reindirizzamento, poiché il browser è il canale per tutte le informazioni)
  • In secondo luogo, questa debolezza si verifica quando link si basa su link per identificare l'utente - invece, nel modello webhook, link conosce già l'identità dell'utente e sta cercando di usare quell'identità su link API.
• In altri flussi, il parametro state aiuta a prevenire gli attacchi CSRF, e qui svolge un ruolo simile - consentendo al client di abbinare le richieste in uscita ai token in entrata e, quindi, assicurandosi che non stia utilizzando un token di accesso per un utente diverso su link (in cui potrebbe inserire informazioni riservate).