Nuestro prototipo de especificación - API y seguridad

En este post voy a hablar sobre las bases mínimas que hemos definido en el prototipo respecto a la especificación de la API y su seguridad.

Para los que no sepáis que es una API, voy a intentar explicároslo.

Una API o Application Programming Interface es un conjunto de recursos y utilidades para ser usados por parte de otro proyecto de software como capa de abstracción. Es decir, es un acceso directo a funcionalidades presentes en un sistema ajeno o remoto.

¿Entonces donde encaja una API en Universitas? Os lo diré.

Universitas consta de dos partes claras:

  • El Front End, o conjunto de programas que son directamente accesibles al usuario. Esto incluye la plataforma web y la aplicación móvil así como cualquier interfaz que se presente a un usuario de Universitas. Este elemento hace uso de la API.

  • El Back End, o conjunto de servicios en los que se apoya cualquier elemento del Front End. Clásicamente se les conoce por servidores, aunque en la actualidad hay soluciones más complejas. Es en este apartado donde va localizada la API.


Genial, ¿entonces que os tengo que contar sobre la API?

Pues que estará enfocada en 2 aspectos:

  • Simplicidad
  • Seguridad
Simplicidad

La API es un sistema que retorna respuestas a solicitudes en forma de texto, el cual ha de ser entendido por el ordenador. Por ello se hacen uso de sistemas de organización de atributos en forma de texto. El que usaremos en Universitas por defecto será JSON.

{
    "mensaje": "hola mundo",
    "personaje": {
        "nombre": "Javier",
        "edad": 22
    },
    "intereses": [
        "informática",
        "gadgets",
        "universo"
    ]
}

Es una forma de estructurar distintos tipos de datos en formato de texto y a la vez que sea legible para las personas. Esto facilita la detección de errores o "bugs".

Por otro lado, nuestra API será servida via HTTP, el protocolo más extendido (por detrás de TCP, del cual depende). Esto aumenta nuestro alcance a prácticamente la totalidad de los dispositivos en el mercado, sin necesidad de instalar complejos sistemas de protocolos propietarios.

Y para rematar esta sección, la API sera natural. Esto significa dos cosas:

  • Solicitudes: se le podrá "hablar" con los verbos ya definidos en el protocolo HTTP, como GET, POST, DELETE...
  • Respuestas: se podrá conocer el resultado de una petición mediante los código de estado de HTTP, como 200 OK, 404 NOT FOUND o 503 SERVICE UNAVAILABLE.

Esto reduce la complejidad en las interacciones a cero, y permite pasar menos tiempo luchando con la API y más tiempo usándola para otras tareas mucho más productivas.


Seguridad

La API es un servicio expuesto a internet, cualquiera puede contactar con el, y dado el caso podría extraer datos sensibles.

Por ello, un aspecto crítico es la seguridad. Una API pública ha de tener unas medidas de seguridad lo suficientemente buenas tanto para asegurar la privacidad de los datos así como su disponibilidad.

Nuestro checklist a la hora de revisar la seguridad y disponibilidad es el siguiente:

  • Conexiones encriptadas: la información enviada entre tu ordenador y nuestros servidores solo la conocemos nosotros y tú. Esto se consigue con HTTPS, un protocolo que engloba al clásico HTTP, proporcionando encriptación end to end. Además de estar soportado por la mayoría de los navegadores, proporciona una garantía añadida y es la de las Autoridades Certificadoras, que verifican que la conexión encriptada establecida, es realmente una conexión con Universitas y no con cualquier otro servidor, que por ejemplo intente hacerse pasar por nosotros.

  • Información sensible hasheada: esta característica se usa principalmente para las contraseñas, y sirve para poder autentificar correctamente a un usuario sin necesidad de conocer directamente su clave de acceso. Podríamos hacer un post entero solo para hablar de este apartado, así que seré breve. Un hash es una función que nos genera un texto a partir de uno inicial. Combinando distintas técnicas conseguimos una clave generada a partir de la clave del usuario, muy difícil de descubrir y casi imposible de descifrar.

  • Tokens: por si todo lo anterior no fuese suficiente (cifrado, hasheo...), haremos uso de una gran medida de seguridad y es el uso de tokens en vez de las credenciales (hasheadas) del usuario. Un token es una clave muy larga que un cliente usa de forma automática para identificarse. El cliente obtiene un token con sus credenciales. De esta manera, se aumenta la seguridad para el cliente en sus operaciones habituales, incluso cuando haga uso de claves débiles o cortas. Además cuenta con una característica muy importante y es que los tokens se pueden revocar si se han visto comprometidos.

  • Anti-tampering: por último, esta medida de seguridad esta destinada a proteger los recursos del sistema, garantizando la alta disponibilidad del mismo. Se basa en implementar una huella temporal cifrada en cada operación que impide re-enviar dicha petición con el mismo contenido de nuevo. Eso implica que el cliente ha de recalcular una nueva huella temporal por cada nueva petición que quiera realizar.

Esto es un resumen MUY corto de las buenas prácticas y especificaciones que tenemos pensado implementar en Universitas. Si tenéis cualquier duda, publicar un comentario. Estaremos encantados de responderos.

Como nota final, queremos comentaros que el desarrollo de la plataforma lleva un buen ritmo y muestra avances. En breve publicaremos un DEVLOG o diario de desarrollo.