OAuth 2.0 con webhooks

Estoy implementando un OAuth2-like flow usando webhooks entre dos webservices (sin navegador / agente de usuario involucrado). El servidor de autenticación otorgará acceso según la URL del webhook al que se debe devolver el resultado.

Está (actualmente) basado en el flujo "implícito": los mismos parámetros, que se pasan utilizando cuerpos de solicitud POST en lugar de consultas / fragmentos y redirecciones.

Entonces, la pregunta es: ¿cuáles (si las hay) preocupaciones de seguridad para el flujo de OAuth "implícito" (particularmente en comparación con otros flujos) todavía se aplicarían a esta configuración?

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

Los pasos A y C son webhooks: las solicitudes POST se respondieron de inmediato (probablemente con el estado 202 Accepted ).

Los parámetros se toman de las secciones 4.2.1 y 4.2.2 de RFC 6749, excepto que redirect_uri se reemplaza por webhook_uri , y response_type se cambia de "token" a "webhook" .

Aquí hay una solicitud de ejemplo del servidor en enlace que busca obtener un token de enlace , solicitando que la respuesta se envíe a enlace :

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 vez aprobada, se da la respuesta:

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

(Los errores se manejan de manera similar, usando parámetros de la sección 4.2.2.1 )

Notas:

• La alternativa obvia es implementar algo más similar al flujo de "código de autorización", donde la respuesta de webhook contiene un código de autenticación que luego se intercambia por un token de acceso.
  • Suponiendo un uso adecuado del parámetro state (especialmente que contiene un valor no adivinable según la sección 10.12 ), ¿hay alguna ventaja en esto?
• Una de las razones por las que el flujo "implícito" se considera menos seguro es que el token de acceso lo lleva el navegador del usuario (en el fragmento) y se puede filtrar a través del historial del navegador u otro comportamiento inesperado. Como aquí se envía el token de servidor a servidor, no creo que esto se aplique.
• Otra razón por la que el flujo "implícito" se considera problemático es que las aplicaciones web a menudo (falsamente) asumen que si terminan con un token de acceso válido para un usuario en un sitio de terceros, entonces pueden tratar a ese usuario como "conectado" en la aplicación web. Sin embargo, si un atacante obtiene un token de acceso para un usuario (incluso uno con permisos triviales, al hacer que el usuario "inicie sesión" en el sitio del atacante ) puede usar este token para hacerse pasar por el usuario. La aplicación web.
  • En primer lugar, no creo que haya una forma de que un atacante proporcione sus propios tokens de acceso como ese en la configuración de webhook. Sin el conocimiento de state , el atacante no puede hacer que parezca que su token de acceso proviene del servidor de autorización. (Por el contrario, el redireccionamiento del navegador permite al atacante manipular los parámetros / redireccionamiento del token, ya que su navegador es el conducto de toda la información).
  • En segundo lugar, esta debilidad ocurre cuando enlace confía en enlace para identificar al usuario, en su lugar, en el modelo de webhook, enlace ya conoce la identidad del usuario y busca usar esa identidad en enlace 's API.
• En otros flujos, el parámetro state ayuda a prevenir ataques CSRF, y aquí desempeña una función similar: permite al cliente hacer coincidir las solicitudes salientes con los tokens entrantes y, por lo tanto, asegurarse de que no esté usando un token de acceso para un usuario diferente en enlace (en el que podría colocar información confidencial).