Selección de un protocolo de autenticación

Actualizado: febrero de 2014

 

Logotipo de DataMarket

Cree una aplicación y comercialícela en una base de clientes amplia y en crecimiento en Marketplace. No importa si la aplicación consume datos de Marketplace o no; en todo caso, puede ser miembro de la comunidad que aprovecha Marketplace para vender sus aplicaciones. Marketplace realiza el aprovisionamiento y la facturación, lo que le permite recoger las recompensas. Si la aplicación consume datos de Marketplace, el usuario deben estar autenticado y autorizado para tener acceso a los conjuntos de datos.

Marketplace de Windows Azure (WAM) admite dos protocolos de autenticación: la autenticación HTTP Basic y OAuth. Para decidirse por uno de ellos, es necesario determinar quién utiliza la aplicación y cómo se utiliza.

Tanto la autenticación HTTP Basic como la autenticación OAuth pueden autenticar a un usuario y, según corresponda, conceder o denegar acceso a un recurso protegido.

Si contesta estas preguntas para su aplicación, podrá determinar cuál de ellos le conviene más:

  • ¿Se venderá esta aplicación en Marketplace?

  • ¿El usuario tendrá acceso o uno o varios conjuntos de datos de Marketplace?

Si contesta "Sí" a alguna de estas preguntas (o a las dos), OAuth es el protocolo de autenticación necesario.

La implementación de Marketplace de la autenticación HTTP Basic omite el identificador de usuario y solo requiere una clave de cuenta secreta como contraseña. Puede omitir el identificador de usuario, o si desea administrar el uso y la facturación por su cuenta, puede utilizarlo para identificar a usuarios específicos. Si la aplicación utiliza el protocolo de autenticación HTTP Basic para tener acceso al Marketplace:

  • Todos los accesos se producen a través de una sola cuenta.

  • Todos los usuarios comparten y usan una sola contraseña (la clave de cuenta de Marketplace).
    Si la clave de cuenta se incluye en el código o la introduce el usuario, la clave de cuenta es menos privada y secreta. Por lo tanto, con ello se pueden introducir vulnerabilidades que podrían aprovecharse.

  • Marketplace factura todos los accesos a una sola cuenta: la del propietario de la clave de cuenta (probablemente usted).

  • El hecho de quitar el acceso a un usuario (cambiando la clave de cuenta) quita el acceso a todos los usuarios.

  • Los conjuntos de datos a los que esté suscrito el propietario de la clave de la cuenta serán los únicos disponibles para los usuarios.

  • Si desea que los usuarios individuales paguen por su uso, debe administrar su uso individual y facturárselo.

Vea Implementación de la autenticación HTTP Basic en su aplicación de Marketplace.

La implementación de Marketplace de OAuth aprovecha el Windows Live ID y contraseña del usuario y la clave de registro de la aplicación (client_id) para autenticar y conceder acceso a conjuntos de datos. El uso de OAuth proporciona algunas ventajas de seguridad adicionales, como la capacidad de autenticar al cliente y al usuario y emitir un token de acceso directamente al cliente sin exponerlo potencialmente a terceros, incluido el propietario del recurso.

Si la aplicación utiliza el protocolo OAuth para tener acceso al Marketplace:

  • La aplicación debe estar registrada en Marketplace.

  • Cada usuario debe tener un Windows Live ID.

  • Todos los accesos se producen a través de la cuenta de usuario individual.

  • La facturación se realiza en la cuenta de usuario individual.

  • El hecho de quitar el acceso a un usuario no afecta a ningún otro usuario.

  • Es posible el acceso a cualquier conjunto de datos al que esté suscrito el usuario (si la aplicación admite este caso).

  • Marketplace administra la cuenta de usuario y la facturación.

Vea Implementación de OAuth en su aplicación de Marketplace.

Dado lo anterior, es razonable preguntarse por qué alguien querría utilizar la autenticación HTTP Basic. Hay dos motivos: 1) el código necesario para implementar la autenticación HTTP Basic es más corto y más sencillo que el código para implementar OAuth y 2) si es usted el único que va a usar la aplicación, no necesita la flexibilidad y la complejidad de OAuth.

Vea también

Mostrar: