Estoy luchando con los mismos conceptos. Creo que lo primero es hacer solo HTTPS, para que esté comenzando de forma más segura que no.
A continuación, depende de cómo va a hacer la autenticación. Si todo lo que necesita es una clave API, (para rastrear qué entidad está accediendo a los datos) eso debería estar bien. Si también desea realizar un seguimiento de la información del usuario, necesitará asociar de algún modo que las claves API específicas puedan acceder a tipos específicos de registros, en función de una unión en algún lugar.
Estoy buscando la autenticación de formularios en mi aplicación y el uso de una cookie de autenticación. Afortunadamente ASP.NET en IIS puede hacer mucho de ese trabajo pesado para usted.
Ejemplo tiempo: (Estoy seguro de que tendrá que añadir más a esta, pero mientras estoy en el trabajo que da algo para roer)
Formas de autenticación: Enviar un par (o más) de campos en un cuerpo de formulario. Esto es POST de principio a fin. No hay cantidad de hashing no reversible que pueda hacer esto seguro. Para asegurarlo, debe estar siempre detrás de un firewall de todos los ojos que se entrometen (sí, a la derecha) o debe estar sobre HTTPS. Suficientemente simple.
autenticación básica: enviar una cadena base64 de "nombre de usuario: contraseña" sobre el alambre como parte de la cabecera. Tenga en cuenta que base64 es asegurar como una puerta de pantalla es a un submarino. Usted no quiere que no sea seguro. HTTPS es obligatorio.
Clave de API: Esto dice que se supone que una aplicación es XYZ. Esto debe ser privado. Esto no tiene nada que ver con los usuarios. Preferiblemente, en el momento en que se solicita la clave API, se comparte una clave pública con el otorgante de la API, lo que permite que la clave API se codifique en tránsito, garantizando así que se mantenga privada pero demuestre la fuente como quiénes son. Esto puede ser complicado, pero debido a que hay un proceso de solicitud y porque no cambiará del proveedor, esto puede hacerse a través de HTTP. Esto no significa por usuario, esto significa por-desarrollo-empresa-que-usa-su-api.
Entonces, lo que quiere que suceda es que para que la aplicación acceda a sus datos, que quiera asegurarse de que sea una aplicación autorizada, puede realizar la negociación utilizando claves privadas para iniciar sesión en tiempo de ejecución. Esto asegura que estás hablando con la aplicación con la que quieres hablar. Pero recuerde, esto no significa que el usuario es quien dice ser.
SIN EMBARGO.
Lo que puede hacer es usar la clave API y las claves públicas/privadas asociadas para codificar la información de nombre de usuario y contraseña para enviarlas a través del cable mediante HTTP. Esto es muy similar a cómo funciona HTTPS, pero solo está encriptando la parte sensible del mensaje.
Pero para permitir que un usuario rastree su información, tendrá que asignar un token basado en el inicio de sesión basado en un usuario. Deje que se conecten, envíe los datos a través del cable utilizando el sistema apropiado, luego devuelva un identificador único que represente al usuario de regreso a la aplicación. Deje que la aplicación envíe esa información cada vez que realice tareas específicas del usuario. (generalmente todo el tiempo).
La forma en que lo envía por cable es decirle al cliente que configure una cookie, y todas las implementaciones de httpClient que he visto saben que cuando hacen una solicitud al servidor, envían todas las cookies al servidor alguna vez ha establecido que todavía son válidos. Simplemente sucede para ti. Entonces configura una cookie en su respuesta en el servidor que contiene la información que necesita para comunicarse con el cliente.
HTH, hágame más preguntas para que podamos refinar esto más.
Entonces, ¿la autenticación de formularios pasará la cookie de autenticación a la aplicación de iPhone? –
Claro. Todo esto es manejado por el mecanismo de transporte HTTP (S). Necesitarás capturarlo específicamente dentro de la aplicación iPhone, por supuesto, pero parece que alguien más está haciendo eso. Solo diles cómo estás haciendo auth y deja que se resuelvan. – jcolebrand
Entonces, eso autenticaría la "aplicación", ¿y si la aplicación también necesitara autenticar a los usuarios? Como si la aplicación tuviera una forma para que los usuarios inicien sesión y editen un perfil, tal vez. –