Todos tenemos claro que cuando queremos entrar a nuestro banco, o a nuestra cuenta de Amazon, Spotify o similares tenemos que poner nuestro usuario y contraseña. O que cuando queremos interactuar con la Administración Pública podemos usar nuestro Certificado Electrónico o nuestro PIN, por ejemplo. Pero ¿qué pasa cuando se utilizan servicios de forma automatizada? ¿Cómo sabe Amazon, el Banco o nuestro Ayuntamiento quién está utilizando esos servicios? Eso es lo que vamos a intentar explicar en este artículo. No vamos a bajar al nivel de técnicas concretas o frameworks específicos, sino que nos quedaremos en un nivel conceptual, por lo que no hay distinción entre REST, SOAP o cualquier otro formato de intercambio de información. Simplificando, lo que necesitamos para acceder a los servicios es una llave, y lo que vamos a ver son los distintos tipos de llave que puede haber y algunas ventajas e inconvenientes de cada una.
Antes de comenzar, un par de conceptos previos. El primero es que al igual que en los accesos a través de las páginas web, es totalmente necesario que los servicios estén publicados bajo HTTPS, ya que sino nuestras comunicaciones podrían ser capturadas y las credenciales quedarían al descubierto. Siguiendo con el ejemplo de la llave, es como si colgamos la llave de nuestra casa en la puerta de entrada, para que cualquiera pudiera usarla o duplicarla
El segundo, es que tenemos que distinguir entre autenticación y autorización. Volvemos al ejemplo del banco.
- Autenticación: si ponemos mal nuestra contraseña no podemos entrar. Tenemos que usar la llave correcta.
- Autorización: una vez que hemos acertado con el usuario y contraseña, entraríamos a nuestra zona privada, donde podemos ver nuestros datos (cuentas, tarjetas, …) pero no deberíamos ver las cuentas o tarjetas de nuestro vecino, por ejemplo. La llave es correcta, pero no sirve para abrir la puerta de al lado.
Es decir, el proveedor de los servicios debe asegurarse de que cada aplicación que los utilice solo tiene acceso a la información que le corresponde. Por ejemplo, un servicio de un Banco puede ser “listado de cuentas corrientes”, y en este caso deberíamos controlar que solo se devolvieran las cuentas correspondientes. No siempre es necesario este control tan estricto. Existen muchas APIs o muchos servicios, que no contienen información personal, y por lo tanto no es necesario ese nivel de seguridad.
El proveedor de los servicios debe asegurarse de que cada aplicación que los utilice solo tiene acceso a la información que le corresponde
Con esto un poco más claro, vamos a ver muy por encima algunas de las opciones:
- Usuario y contraseña: Exactamente igual que en el acceso web, los servicios tienen que enviar un usuario y una contraseña. Por la forma en que viaja esta información, es más vulnerable que el resto de las opciones. Además, en sistemas complejos, implica la generación de dos palabras (usuario y contraseña) con el mantenimiento y gestión que conlleva. Y hablando de hacking social, el usuario podría ser fácil de adivinar.
- Uso de firma electrónica: En este caso lo que se suele hacer es firmar una parte del mensaje y tenemos un par de opciones en cuanto a qué certificado usar.
Veamos las opciones:- Se firma con la parte privada y el proveedor de los servicios posee la parte pública para su validación. De esta forma nos aseguramos de que el usuario de los servicios es quien dice ser, porque se utiliza una CA autorizada y se valida la revocación del certificado. Esto es exactamente igual que cuando usamos nuestro DNIe, por ejemplo. El problema de esto es que los tiempos de autenticación son más lentos, porque tenemos que validar el certificado, y en el uso de servicios masivos que lo que queremos es ganar tiempo, esta solución no es óptima.
También tenemos otro problema relacionado con la autorización en sistemas complejos, ya que, si nuestra entidad utiliza varias integraciones, tendríamos que tener un certificado para cada una de ellas, y que el proveedor de los servicios sepa a que integración corresponde cada certificado. Por ejemplo, en la API de Gestiona podemos tener una Entidad que tenga una integración que use solo servicios de Registro y otra que use solo Servicios de Expedientes, además con dos proveedores distintos. En este caso, tendría que haber dos certificados, una para cada integración, con el coste de gestión que supone además para esta entidad. - Se firma con la parte pública y el proveedor de los servicios genera y gestiona las partes privadas. Esta es una variación de la anterior, en la que la parte privada la gestiona el proveedor de los servicios. Con esto evitamos cargar al integrador con la gestión de los certificados, pero se traslada a la otra parte. Y también seguimos teniendo el problema de los tiempos para la validación de la revocación.
Para que esta opción sea 100% confiable, lo ideal sería que los certificados fueran de una CA reconocida.
- Se firma con la parte privada y el proveedor de los servicios posee la parte pública para su validación. De esta forma nos aseguramos de que el usuario de los servicios es quien dice ser, porque se utiliza una CA autorizada y se valida la revocación del certificado. Esto es exactamente igual que cuando usamos nuestro DNIe, por ejemplo. El problema de esto es que los tiempos de autenticación son más lentos, porque tenemos que validar el certificado, y en el uso de servicios masivos que lo que queremos es ganar tiempo, esta solución no es óptima.
- Envío de token o palabra “mágica: En este caso se genera un token o una palabra en el servidor que se envía al integrador. Esta forma de autenticación puede ir asociada a la de usuario y contraseña.
Por ejemplo, con el siguiente flujo:- Envío de usuario y contraseña al servidor
- El servidor genera el token asociado a ese usuario, y además con una caducidad
- Las siguientes llamadas utilizan el token, en lugar de usuario y contraseña.
- Clave única: En este caso lo que tenemos es una única palabra o clave que se envía a cada integrador. Además, lo que se suele hacer a la hora de generar esta clave es cifrar ciertos datos del integrador, de forma que añadimos esa seguridad sabiendo que si se descifra veremos datos de la aplicación que lo está utilizando. Es muy parecida conceptualmente a la de usuario y contraseña, pero ahora tenemos un único valor a gestionar.
Por otro lado, como esta clave es “ilegible” porque está formada por letras y números sin ningún significado, se evita caer en la tentación de realizar asociaciones directas a integraciones, lo que aumenta la dificultad de su obtención. Lo cual sí que podríamos tener en el caso de claves de usuario.
Y ya brevemente y para finalizar, ¿qué gran problema hay en las opciones que hemos visto? Que no son escalables, es decir, que no podemos generarlas sin intervención humana. Pero esto para nosotros no es un problema. Igual que tampoco lo es para el Banco.
En el caso de Gestiona, cuando se proporcionan las credenciales de autenticación para la API, lo que tenemos que saber es quién las va a usar y para qué. Y hay todo un proceso de validación antes de entregar ninguna clave a los integradores
En el caso de Gestiona, cuando se proporcionan las credenciales de autenticación para la API, lo que tenemos que saber es quién las va a usar y para qué. Y hay todo un proceso de validación antes de entregar ninguna clave a los integradores. Exactamente igual que cuando queremos obtener el certificado de la FNMT que tenemos que ir a Hacienda, por ejemplo.
En nuestro caso, siendo que trabajamos con información sensible es necesario este proceso de alta manual, y no se contempla el “auto-registro” para utilizar la API. Sobre todo, porque tenemos que limitar muy bien la parte de autorización, y saber qué datos puede visualizar cada integrador.
