Tots tenim clar que quan volem entrar al nostre banc, o al nostre compte d’Amazon, Spotify o un de similar, hem d’introduir el nostre nom d’usuari i la contrasenya. O que quan volem interactuar amb l’Administració pública podem utilitzar el certificat electrònic o el PIN, per exemple. Però, què passa quan s’utilitzen serveis de manera automatitzada? Com saben Amazon, el banc o l’ajuntament qui està utilitzant aquests serveis? Això és el que intentarem explicar en aquest article. No baixarem al nivell de tècniques concretes o frameworks específics, sinó que ens quedarem en un nivell conceptual, de manera que no hi ha distinció entre REST, SOAP o qualsevol altre format d’intercanvi d’informació. Simplifiquem: el que necessitem per accedir als serveis és una clau, i el que veurem tot seguit són els diferents tipus de clau que hi pot haver i alguns avantatges i inconvenients de cadascuna.
Abans de començar, un parell de conceptes previs. En primer lloc, de la mateixa manera que en els accessos a través de les pàgines web, és totalment necessari que els serveis estiguin publicats sota HTTPS perquè, altrament, les nostres comunicacions podrien ser capturades i les credencials quedarien al descobert. Si continuem amb l’exemple de la clau, és com si pengem la clau de casa nostra a la porta d’entrada perquè qualsevol pogués utilitzar-la o duplicar-la.
En segon lloc, hem de distingir entre autenticació i autorització. Tornem a l’exemple del banc.
- Autenticació: si posem malament la nostra contrasenya no hi podem entrar. Hem d’utilitzar la clau correcta.
- Autorització: una vegada hem encertat l’usuari i la contrasenya, ja podem entrar a la nostra zona privada, on podem veure les nostres dades (comptes, targetes…), però no hauríem de veure els comptes o les targetes del nostre veí, per exemple. La clau és correcta, però no serveix per obrir la porta del costat.
És a dir, el proveïdor dels serveis s’ha d’assegurar que cada aplicació que els utilitzi només tingui accés a la informació que li correspon. Per exemple, un servei d’un banc pot ser una “llista de comptes corrents”, i en aquest cas hauríem de controlar que només es tornessin els comptes corresponents. No sempre és necessari aquest control tan estricte. Hi ha moltes API o molts serveis que no contenen informació personal i, per tant, no és necessari aquest nivell de seguretat.
El proveïdor dels serveis s’ha d’assegurar que cada aplicació que els utilitzi només tingui accés a la informació que li correspon
Amb això una mica més clar, vegem molt per sobre algunes de les opcions:
- Usuari i contrasenya: Exactament de la mateixa manera que en l’accés web, els serveis han d’enviar un usuari i una contrasenya. Per la forma en què viatja aquesta informació, és més vulnerable que la resta de les opcions. A més, en sistemes complexos, implica la generació de dues paraules (usuari i contrasenya) amb el manteniment i la gestió que comporta. I parlant de hacking social, l’usuari podria ser fàcil d’endevinar.
- Ús de signatura electrònica: En aquest cas, el que se sol fer és signar una part del missatge, i tenim un parell d’opcions quant a quin certificat cal utilitzar.
Vegem les opcions:- Se signa amb la part privada i el proveïdor dels serveis té la part pública per a la seva validació. D’aquesta manera, ens assegurem que l’usuari dels serveis és qui diu ser, perquè s’utilitza una CA autoritzada i es valida la revocació del certificat. Això és exactament igual que quan utilitzem el nostre DNI electrònic, per exemple. El problema d’això és que els temps d’autenticació són més lents, perquè hem de validar el certificat; i en l’ús de serveis massius, en els quals el que volem és guanyar temps, aquesta solució no és òptima.
També tenim un altre problema relacionat amb l’autorització en sistemes complexos ja que, si la nostra entitat utilitza diverses integracions, hauríem de tenir un certificat per a cadascuna i que el proveïdor dels serveis sabés a quina integració correspon cada certificat. Per exemple, en l’API de Gestiona podem tenir una entitat que disposi d’una integració que utilitzi només serveis de registre i una altra que utilitzi només serveis d’expedients, a més amb dos proveïdors diferents. En aquest cas, hauria d’haver-hi dos certificats, un per a cada integració, amb el cost de gestió que suposa, a més, per a aquesta entitat. - Se signa amb la part pública i el proveïdor dels serveis genera i gestiona les parts privades. Aquesta és una variació de l’anterior, en la qual la part privada la gestiona el proveïdor dels serveis. Amb això evitem carregar l’integrador amb la gestió dels certificats, però es trasllada a l’altra part. I també continuem tenint el problema dels temps per a la validació de la revocació.
Perquè aquesta opció sigui 100 % confiable, l’ideal seria que els certificats fossin d’una CA reconeguda.
- Se signa amb la part privada i el proveïdor dels serveis té la part pública per a la seva validació. D’aquesta manera, ens assegurem que l’usuari dels serveis és qui diu ser, perquè s’utilitza una CA autoritzada i es valida la revocació del certificat. Això és exactament igual que quan utilitzem el nostre DNI electrònic, per exemple. El problema d’això és que els temps d’autenticació són més lents, perquè hem de validar el certificat; i en l’ús de serveis massius, en els quals el que volem és guanyar temps, aquesta solució no és òptima.
- Enviament de token o paraula “màgica”: En aquest cas es genera un token o una paraula al servidor que s’envia a l’integrador. Aquesta forma d’autenticació pot anar associada a la d’usuari i contrasenya.
Per exemple, amb el flux següent: Amb aquesta solució simplifiquem les trucades i afegim una garantia que és la caducitat, però continuem necessitant usuari i contrasenya per a la primera petició. I en integracions complexes, com Gestiona, caldria generar diversos usuaris per a la mateixa entitat, la qual cosa augmentaria la dificultat de gestió per part del client.- Enviament d’usuari i contrasenya al servidor
- El servidor genera el token associat a aquest usuari, i a més amb una caducitat
- Les trucades següents utilitzen el token, en lloc d’usuari i contrasenya.
- Clau única: En aquest cas, el que tenim és una única paraula o clau que s’envia a cada integrador. A més, el que se sol fer a l’hora de generar aquesta clau és xifrar certes dades de l’integrador, de manera que afegim aquesta seguretat sabent que si es desxifra veurem dades de l’aplicació que l’està utilitzant. És molt semblant conceptualment a la d’usuari i contrasenya, però ara tenim un únic valor per gestionar.
D’altra banda, com aquesta clau és “illegible” perquè està formada per lletres i nombres sense cap significat, s’evita caure en la temptació de fer associacions directes a integracions, la qual cosa augmenta la dificultat de la seva obtenció. Amb la qual cosa sí que podríem tenir en el cas de claus d’usuari.
Per acabar, breument, quin gran problema hi ha en les opcions que hem vist? Que no són escalables, és a dir, que no podem generar-les sense intervenció humana. Però això per a nosaltres no és un problema. I tampoc no ho és per al banc.
En el cas de Gestiona, quan es proporcionen les credencials d’autenticació per a l’API, el que hem de saber és qui les utilitzarà i per a què. I hi ha tot un procés de validació abans de lliurar una clau als integradors
En el cas de Gestiona, quan es proporcionen les credencials d’autenticació per a l’API, el que hem de saber és qui les utilitzarà i per a què. I hi ha tot un procés de validació abans de lliurar una clau als integradors. Exactament igual que quan volem obtenir el certificat de la FNMT i hem d’anar a Hisenda, per exemple.
En el nostre cas, com que treballem amb informació sensible, és necessari aquest procés d’alta manual, i no es preveu l’“autorregistre” per utilitzar l’API. Sobretot, perquè hem de limitar molt bé la part d’autorització i saber quines dades pot visualitzar cada integrador.
