¿La mejor manera de asegurar el sitio web de arquitectura de front-end / REST back-end de javascript?

18

Me gustaría construir el siguiente proyecto:

  • back-end de la API de REST pública a la que puede acceder cualquier cliente autenticado.
  • front end con archivos estáticos en HTML / CSS / Javascript con Backbone.js jQuery llamadas al back end REST.

De hecho, hay tres partes en mi arquitectura: el front-end, que es un cliente del back-end, el back-end y el usuario que quiere autenticarse en la página de inicio de sesión del front-end.

¿Cuál es la mejor manera de proteger a las tres partes involucradas en esta arquitectura?

De hecho, creo que es simplemente imposible hacer una aplicación segura en el front-end si hago todo en javascript, así que tengo la intención de delegar la autenticación / autorización a una capa proxy en el front-end de mi servidor.

Mi problema es que no sé cómo realizar este flujo de trabajo con OAuth:

  • un usuario desea crear una cuenta en el extremo delantero.
  • el Front End delega la creación de la cuenta al REST back end.
  • el back-end crea la cuenta y envía un agradecimiento al frente.
  • entonces el usuario puede realizar llamadas que requieren autorización.

Y también quiero que mi back-end REST sea accesible a cualquier otra aplicación de terceros con OAuth.

¿Tendré que usar OAuth de 2 patas o de 3 patas en el extremo posterior de REST?

¿Puedo considerar mi Front End como una aplicación especial de terceros que tiene la capacidad de crear una cuenta de usuario?

¿Qué protocolo de seguridad puedo tener que usar en el front-end?

    
pregunta rico 19.12.2011 - 21:06
fuente

1 respuesta

2

Bueno, dado que usted declara que solo los clientes autenticados pueden acceder a la API REST, en primer lugar requerirá una forma de sesiones para recordar el estado de autenticación del cliente. Dependiendo de si puede alterar el código del servidor de la API REST, podría implementarlo en el propio servidor de la API.

Esto podría usar cualquiera de los medios de autenticación de usuario conocidos como una combinación de nombre de usuario / contraseña o un certificado (autofirmado).

Sin embargo, al igual que con HTTP, tendrá que asegurarse de que las contraseñas no viajen a la línea en texto sin formato y una vez que la sesión esté autenticada, la conexión no debe perder el identificador de la sesión, lo que permite su secuestro. Básicamente, esto significa que tiene que imitar el comportamiento similar a SSL o implementar el soporte SSL para su front-end. Puede encontrar un ejemplo aquí: enlace

Sus preguntas relacionadas con OAuth son una pregunta diferente y le sugeriría que las haga en otra pregunta si aún es algo que desea saber.

Con respecto a una capa de proxy, esta es una opción viable solo siempre que la API no sea de acceso público a través de dicho proxy. Esta capa proxy tendría que implementar las mismas propiedades similares a SSL, pero esta configuración le brinda la característica adicional de poder mantener separados la lógica de autenticación y el proveedor de API. Sin embargo, no lo recomendaría si puede modificar la API, porque si alguna parte de su servidor proporciona accidentalmente acceso a la API privada, puede burlar sus requisitos de autenticación.

    
respondido por el Beanow 22.04.2012 - 17:34
fuente

Lea otras preguntas en las etiquetas