Actualmente estamos implementando una aplicación de una sola página (Angular2) y, por lo tanto, nos hemos encontrado con el problema estándar de "cómo asegurar nuestra API de backend".
Aparentemente, la solución estándar para esto es utilizar el flujo de concesión implícita OAuth2, que está bien. Estamos implementando un Servidor de Autorización personalizado que se autentica utilizando nuestra Solución de SSO Web (Open AM / SAML), verifica las licencias y luego emite tokens de acceso a través de la puerta de enlace API (Mashape Kong).
El token de acceso (como se especifica en el Flujo implícito de OAuth2) se devuelve al SPA mediante una redirección, que proporciona el token de acceso en el fragmento ( https://my.spa.com/#access_token=asdfasdf&token_type=bearer&expires_in=1800 ).
Hasta ahora, no hay especialidades. Ahora: el token de acceso solo es válido por un corto período de tiempo, y no hay token de actualización; no queremos que el usuario final sea redirigido de nuevo al Servidor de Autorización (se vería mal / flicker / ...). Nuestra idea fue utilizar la sesión existente con el Servidor de Autorización (que implementamos, ver más arriba) para actualizar el token de acceso (crear uno nuevo) a través de una llamada CORS a un punto final especial del Servidor de Autorización (llamémoslo /heartbeat ).
Obviamente, esto requiere hacer un par de cosas:
- El
Origindebe ser exactamente el host de la aplicación que realiza la llamada, y el Auth Server debe verificarlo y reflejarlo en la respuesta de verificación previa - La aplicación cliente debe hacer la llamada CORS con
withCredentials: trueactivado (usandoXMLHttpRequest,credentials: includepara Fetch)
Hicimos una implementación de prueba de esto, y parece funcionar bastante bien, pero todavía quiero preguntarle a ustedes como expertos en esto: ¿Existen vectores de ataque (adicionales) al habilitar este tipo de actualización? Además de los sospechosos habituales para la concesión implícita, es decir.
Saludos cordiales, Martin