tutorial servicios por net example ejemplo crear autenticacion asp iphone security authentication asp.net-web-api token

iphone - servicios - web api c# tutorial



Autenticación de las solicitudes desde la aplicación móvil(iPhone) a la API web ASP.Net(se solicitan comentarios en mi diseño) (3)

En VS 2013, puede utilizar la plantilla "Asp MVC SPA Application" para generar una implementación en funcionamiento que genere un portador de tokens Oauth2 al iniciar sesión y autorizarlo para llamadas de controlador WebApi utilizando los atributos [Authorize]. Utiliza Membership y Entity Framework para almacenar usuarios y hashes localmente en un SQL Server. Simplemente elimine las partes de asp mvc que no necesita y conserve la parte de autenticación para WebApi. Más detalles aquí: http://msdnrss.thecoderblogs.com/2013/09/understanding-security-features-in-the-spa-template-for-vs2013-rc/

Estoy diseñando un sitio web que tendrá un compañero móvil (inicialmente solo iPhone). El sitio web será una aplicación ASP.Net MVC 3. También tendré un sitio ASP.Net Web API (MVC 4) para exponer servicios a la aplicación iPhone. La aplicación iPhone tendrá su propio formulario para capturar el nombre de usuario y la contraseña del usuario y enviarla a la API web en los encabezados JSON.

Quiero considerar la seguridad desde el principio en lugar de una idea posterior. No soy un experto en seguridad de ninguna manera. Investigué mucho para ver cómo otros manejan la autenticación de un cliente de aplicaciones móviles desde un servicio web. Creo que he encontrado una solución decente que no implica conectar con OAuths de terceros.

Agradecería enormemente cualquier opinión, consejo, crítica y WTF generales que cualquiera de ustedes pueda ofrecer. :)

Mis mayores preocupaciones son:

  1. Garantizar que las llamadas realizadas a la API web estén autorizadas
  2. Minimizando el riesgo de ataques de repetición (por lo tanto, marcas de tiempo en las llamadas a continuación)

La aplicación de iPhone se desarrollará como tal:
Dos cadenas están codificadas en la aplicación de iPhone (los mismos valores para cada usuario):

  1. ID de aplicación
    Esta es una cadena que se utiliza para identificar el tipo de cliente que está accediendo a la API web (iPhone, Android, teléfono Windows, etc.).

  2. Sal Hashing de la aplicación
    Esta es una cadena que se usa para los valores hash de sal para las solicitudes independientes del usuario.

Dos cadenas se almacenan en la base de datos local de la aplicación iPhone (valores únicos para cada usuario):

  1. Token de acceso de usuario de API
    Esta es una cadena (token) proporcionada al cliente por la API web tras la autenticación exitosa y permite al cliente acceder a la API web sin enviar el nombre de usuario y la contraseña en cada solicitud.
  2. Sal Hashing del usuario
    Se trata de una cadena que se utiliza para calcular hashes de sal para solicitudes realizadas contra cuentas de usuario establecidas.



El iPhone realizará llamadas a la API web de la siguiente manera:

Método API: Crear cuenta
Cliente envía:

  • Nuevos datos de cuenta (nombre de usuario, contraseña, nombre, apellido, etc.)
  • ID de aplicación
  • Marca de tiempo UTC
  • Hash de UTC Timestamp + ID de aplicación salados con la sal hashing de la aplicación

Devoluciones de API:

  • Sal Hashing del nuevo usuario

    La idea aquí es que, al crear una cuenta, puedo usar la sal codificada de la aplicación, ya que no supone un gran riesgo de seguridad si alguna vez se salga (mediante descompilación u otros medios).

    Pero para los métodos que acceden y modifican los datos del usuario, usaré un salt que solo pertenece a ese usuario, por lo que no puede ser utilizado por un atacante para suplantar a otros.


Método API: obtener cuenta
(Se utiliza para obtener sal hash del usuario para las cuentas que se crearon en el sitio web pero aún no se han sincronizado en el iPhone. Esto sucede cuando un usuario intenta iniciar sesión en el iPhone y el iPhone detecta que no tiene registro para ese nombre de usuario) .)

Cliente envía:

  • Nombre de usuario
  • Contraseña (hash con sal hashing de la aplicación)
  • ID de aplicación
  • Marca de tiempo UTC
  • Hash de UTC Timestamp + ID de aplicación salados con la sal hashing de la aplicación

Devoluciones de API:

  • Sal Hashing del usuario existente


Método API: Iniciar sesión (autenticar)
Cliente envía:

  • Nombre de usuario
  • Contraseña (hash con sal hashing del usuario)
  • ID de aplicación
  • Marca de tiempo UTC
  • Hash de UTC Timestamp + ID de aplicación salados con User''s Hashing Salt

Devoluciones de API:

  • Token de acceso de usuario de API


Método API: cualquier comando (es decir, crear publicación, actualizar perfil, obtener mensajes, etc.)
Cliente envía:

  • Datos de comando
  • Token de acceso de usuario de API
  • ID de aplicación
  • Marca de tiempo UTC
  • Hash de UTC Timestamp + Application ID + API Token de acceso de usuario salado con User''s Hashing Salt

Mis sugerencias

  1. Autenticacion y autorizacion. Compilarlo en 2 servidores diferentes (en algunos proyectos también he usado 3). Los servidores proxy inversos son realmente buenos con esto. Autenticar en un servidor y autorizarlo en el otro.

Este es el paso más importante que creo que se necesita en seguridad móvil que usa API web.

  1. Encapsula todo

  2. Use SSL para toda la información segura. En mi caso, lo uso para todo.

  3. Para su marca de tiempo, seleccione un momento adecuado para el que pueda tener autorización. No lo hagas muy corto, ya que tu aplicación se volverá lenta o demasiado larga, ya que los rastreadores de red pueden acceder a los paquetes.

Si desea una arquitectura de 3 servidores Para sus solicitudes, también tiene una clave de aplicación que usa para generar una clave de acceso (desde el Servidor 1). Esta clave de acceso autenticará sus solicitudes, que después de la autenticación exitosa (desde el servidor 2) puede usar esa clave para autorizar sus solicitudes desde otro servidor (servidor 3)

Las solicitudes que ha mencionado son normas estándar. Realmente no veo un problema con eso.