¿Necesito protección CSRF en esta configuración con una API REST respaldada con oauth2 y un servidor de autenticación SSO básico?

Para responder a su pregunta inicial: no necesita implementar contramedidas CSRF en su servidor de recursos, si no está utilizando cookies (sesiones) y no está usando la autenticación básica dentro del navegador.

El navegador almacena las cookies y el encabezado de autorización Básico para cada nombre de dominio que visita, y cada vez que envía una solicitud a un sitio, las cookies guardadas y el encabezado de autorización Básico se agregan automáticamente a los encabezados de solicitud.

Ya que está usando un token de acceso, y presumiblemente lo está enviando usando Authorization: Bearer <token> , debe estar seguro. Su navegador no sabe cómo manejar este tipo de autorización y por eso también tiene que agregar manualmente este encabezado en cada solicitud.

Redirigir URIs

Está utilizando URI de redireccionamiento pre-registrado, que es recomendado por el estándar OAuth 2.0. Esto garantiza que su servidor de autorización solo envíe códigos de autorización a sitios en los que confíe.

Es importante que sus URI de redireccionamiento utilicen un esquema seguro, como HTTPS, de lo contrario, son vulnerables a un ataque MITM.

Intercambio de código de autorización por token de acceso

Su sitio está recibiendo un código de autorización a través de un parámetro de consulta, cuando se le redirige desde el servidor de autorización. Lo más probable es que esté intercambiando inmediatamente el código de autorización por un token de acceso, que luego debería revocar el código de autorización.

El parámetro state se debe usar aquí para evitar ataques CSRF, por ejemplo. enviando un valor aleatorio al punto final authorize y comprobando que está recibiendo el mismo valor con el código de autorización. En un SPA, puede guardar el valor aleatorio en el almacenamiento local, es decir,

En un SPA, debes preocuparte menos por esto, por ejemplo, en una aplicación web del lado del servidor con estado. ¿Qué sucede si un atacante lo redirige a la página de autorización desde su propia página web? Terminas en tu propio SPA, donde el atacante no debería poder continuar.

En una aplicación de servidor con estado, es posible que al hacer esta autorización, en realidad se vinculen las cuentas, y las cosas puedan comenzar a suceder. (Dependiendo de la aplicación, por supuesto).

CORS en token endpoint

En primer lugar, CORS solo lo controla su navegador, por lo que no debe confiar en él para impedir que un atacante use su punto final token .

Para evitar CORS aquí, todo lo que un atacante tendría que hacer, es crear un punto final proxy, que simplemente envía la solicitud a su punto final token .

Además, el punto final token solo funciona si recibe un código de autorización válido.

CORS en el punto final authorize

Normalmente, redirigiría a sus usuarios al punto final authorize , donde (iniciarían sesión y) harían clic en un botón de autorización, dando acceso a la aplicación.

Sin CORS, un ataque probable es que un atacante puede crear su propio sitio, donde usa XHR / fetch para recuperar su página authorize . Y suponiendo que el usuario haya iniciado sesión (de manera estatal) en su página authorize , podría hacer clic en el botón de autorización, sin el consentimiento del usuario.

No hay ningún escenario en el que sea necesario usar XHR / fetch para recuperar la página authorize . Así que puedes bloquearlo con seguridad con CORS.

Servidor de autorización

Si su servidor de autorizaciones tiene estado, mientras escribe, debe implementar la protección CSRF siempre que realice una acción que pueda cambiar algo. Lo mejor es hacer esto en general, y si agrega una función de actualización de contraseña en el futuro, ya tiene el código necesario para protegerse contra CSRF.

Recomendaciones

Parece que entiendes la especificación OAuth. y parece que estás haciendo lo que se supone que debes hacer.

• Las recomendaciones obvias son usar HSTS con precarga (y HPKP), para prevenir ataques MITM.
• Asegúrese de que sus códigos de autorización sean de corta duración y se puedan usar solo una vez. No necesitan ser válidos por mucho tiempo, en escenarios normales se usa inmediatamente después de ser otorgados.
• No almacene tokens de acceso final, tokens de actualización, códigos de autorización en su base de datos. En su lugar, almacene un identificador (por ejemplo, 64 bytes de forma aleatoria) y emita una versión firmada (por ejemplo, JWT). Esto evita que los atacantes extraigan tokens de acceso de su base de datos, ya que el atacante no puede usarlos de todos modos.
• Use una implementación estándar de OAuth, no haga su propio rollo.