segura - seguridad api rest

¿Cómo puedo autenticar a un usuario desde una aplicación web a una API?

Question

Parece ser una pregunta ampliamente formulada y después de haber leído toneladas de documentaciones sobre el tema, todavía no estoy seguro de haber entendido todo correctamente (supongo que ser tonto es una posible respuesta;)).

Estoy intentando crear una API que proporcionará un servicio a los usuarios. Los usuarios se conectarán a través de Facebook o cualquier proveedor de OpenId (yo separo Facebook ya que implementan su propio sistema de conexión).

(Creo que es una buena manera porque no almacenaré la contraseña del usuario y finalmente tendré menos problemas en caso de un problema similar con Gawker).

Cuando se realiza una solicitud desde el cliente (aplicación web, aplicación móvil, lo que sea) a la API, se debe enviar un indicador junto con la solicitud para identificar qué usuario está usando la aplicación. Esto generalmente se usa a través de un token , definido durante la Autenticación.

Pero con respecto a la Autenticación, no puedo encontrar ningún ejemplo valioso, tutorial, explicaciones sobre cómo implementarlo correctamente.

Voy a (intentar) explicar:

En mi (maravilloso mundo de happy care osos), estructuré mi proyecto en varias partes:

• Una API RESTful
• Una aplicación web que usará la API. Idealmente, estaba pensando en hacer un proyecto completo de html / css / js, sin ningún trabajo del lado del servidor (php / python / java o lo que sea)
• Una aplicación móvil
• Una aplicación de windows / mac / linux

Por lo que yo veo, cada vez que alguien pregunta cómo implementar una autenticación RESTful API, aparecen tres respuestas principales:

• El modo HTTP básico (+ preferiblemente SSL) / digest
• OAuth
• OpenId

Como no voy a guardar la contraseña del usuario, la primera está fuera de mi alcance, pero las otras dos me dejan perplejo.

Pero OAuth y OpenId no son lo mismo , un (OpenId) representa la Autenticación (que es la base de las preguntas) donde el segundo (OAuth) representa la Autorización .

Cuando Twitter implementa OAuth para su API, no están implementando un sistema de Autenticación, están configurando una forma de indicar a sus usuarios que la aplicación X desea tener acceso a la cuenta de usuario (en varios niveles de acceso). Si el usuario no está conectado actualmente en Twitter, primero tendrá que autenticarse y autorizar a la aplicación actual para acceder a sus datos.

Entonces, solo para aclarar las cosas, OAuth NO es un mecanismo de autenticación , es un:

Un protocolo abierto para permitir la autorización API segura (fuente: http://oauth.net/ )

Entonces, la única forma de autenticar a un usuario sería usando OpenId. Y luego, el infierno se hace realidad.

Si tomo como ejemplo una aplicación web que está exclusivamente hecha de html / css / js, sin componentes del lado del servidor, comuníquese con una API.

La aplicación web debe indicar a la API que el usuario que utiliza actualmente la API es el señor X.

Para hacerlo, la aplicación web muestra una ventana emergente que contiene una lista de proveedores de OpenId, pidiéndole al usuario que se autentique. El usuario hace clic en uno de ellos, es redirigido (o se abre una nueva ventana emergente) al proveedor de OpenId, indica su inicio de sesión / pase, se autentica por el proveedor de OpenId, que devuelve el éxito con un token (simplifiqué la comunicación).

Es genial, la aplicación web sabe ahora que el usuario es realmente el señor X. ¡Pero la API todavía tiene alguna pista!

Finalmente, mi pregunta es bastante simple: ¿cómo puedo autenticar mister x a través de la aplicación web a la API a través de OpenId y después de eso, cómo pueden la aplicación web y la API mantener la información de que este es el señor X que está usando actualmente la aplicación web? y por supuesto, la API.

Muchas gracias por su ayuda !

formato editado

Answer 1

Realmente no desea iniciar sesión en la API usando OpenID. Como dijo, OpenID es para Autenticación , es decir, Quién, mientras que OAuth es para Autorización , es decir, ¿estoy permitido? Pero su estructura sugiere que utilizará una API como back-end y una aplicación web como front-end.

La mejor forma es utilizar OpenID en la aplicación web para autenticar al usuario, y luego la aplicación web se conecta a la API y almacena las credenciales de OpenID. La aplicación web sabe quién es el usuario y puede proporcionar el servicio. La API no tiene nada que ver con el usuario, excepto que almacena sus datos.

La diferencia fundamental entre OpenID y OAuth es su uso. En su situación, podría tener algo como eso:

-------- --------- -------
| User | <------> | App | <--------> | API |
-------- OpenID --------- (OAuth) -------

El usuario nunca interactúa directamente con la API: ¿quién querría enviar manualmente una solicitud HTTP? (lol) En cambio, el servicio se proporciona a través de la aplicación, que se puede autorizar opcionalmente con OAuth. Sin embargo, en el caso de que una sola aplicación acceda a la API, puede hacer que la conexión de la aplicación <=> API sea interna y nunca la exponga.

Answer 2

(Si no quiere leer, la lista a continuación resume toda la idea)

Una posible solución (dime si estoy equivocado) sería mostrar el formulario de inicio de sesión en el consumidor (aplicaciones web, aplicaciones móviles, etc.), el usuario hace clic en su proveedor (myopenid, google, etc.) que abre una ventana emergente para hacer el inicio de sesión. La parte difícil es que el parámetro return_to se establecerá en la API, no en el sitio web

La API luego reenviará la verificación_authentication y obtendrá is_valid: true (o no). Durante este paso, la aplicación consultará la API a una URL específica que devuelve el estado de la autenticación (procesamiento, error, éxito). Mientras está procesando, se muestra un indicador al usuario (cargando gif), y si es exitoso / falla el resultado se muestra al usuario.

Si la API recibe un is_valid: true, solicitará información sobre el usuario al servidor de apertura, como correo electrónico, nombre, apellido y compararlos con su base de datos de usuario. Si hay una coincidencia, la API crea una sesión entre ella y la aplicación; si el usuario es nuevo, crea una nueva entrada y luego la sesión.

La sesión sería un token único con una duración específica (tal vez igual a la duración del assoc_handle del servidor de apertura).

Parece ser algo posible, pero no soy un experto en seguridad.

Para explicar las cosas más simples, aquí hay un pequeño "mapa":

Nota: El proveedor es el servidor OpenId (que proporciona la información sobre la autenticación)

• El usuario va a la aplicación web y hace clic en el ícono de inicio de sesión de su proveedor (Google por ejemplo)
• La aplicación web abre una ventana emergente que contiene la página de inicio de sesión del proveedor y la página de acceso, y especifica un return_to para la API.
• El proveedor envía información a la Api
• El API valida estas informaciones a través de la verificación_authentication
• Si no es válido, la API indica a la aplicación web (que pide a la API cada x segundos) la falla
• Si es válido, el Api solicita información sobre el usuario al proveedor, como correo electrónico, nombre para mostrar, etc.
• Si el usuario existe, se crea una sesión
• Si el usuario es nuevo, se agrega a la base de datos y se crea la sesión
• La API devuelve el estado de la autenticación (en este caso, éxito) con una sesión de token que la aplicación web utilizará para otras solicitudes.