Cómo Proteger tu API Guía de Autenticación

COM PROTEGIR la teva API: GUIA D’AUTENTICACIÓ

Una part crucial per al disseny de l’arquitectura d’una API és decidir quines dades seran públics i quins no. També, quin tipus d’usuaris podran accedir a una certa mena d’informació. En aquest article, explorarem diferents mètodes d’autenticació, les seves formes d’implementació i els avantatges i desavantatges de cadascun dels mètodes. Gràcies a tots aquests consells descobriràs com protegir el teu API.

COM FUNCIONA L’AUTENTICACIÓ EN UNA API?

L’autenticació en una API és el procés que verifica la identitat d’un usuari o d’una aplicació que intenta accedir a aquesta. Per tant, aquest procés és fonamental per a assegurar que només els usuaris o aplicacions autoritzades puguin accedir als recursos proporcionats per la API.

Aquest procés serveix tant per a protegir l’accés a la API d’usuaris no autoritzats, com per a realitzar controls d’accés basats en l’usuari. Tot això permet controlar que només els usuaris autoritzats puguin entrar i, a més, segregar dins d’aquests usuaris quins rols poden realitzar depenent de les accions.

També, pot servir per a rastrejar qui accedeix a la API i quines accions realitzar, ja que, en alguns tipus d’autenticació, els tokens generats van associats a un usuari en concret. D’aquesta manera, es pot realitzar una auditoria per a poder determinar si un usuari està duent a terme un ús sospitós del nostre servei. Per tant, es contribueix al fet que es redueixi el risc que hi hagi usuaris que facin un ús excessiu de recursos o puguin haver-hi atacs de denegació de servei (DDoS).

COM ÉS UNA API SENSE AUTENTICACIÓ?

Consisteix a tenir la informació totalment exposada al públic, ja que no es comprova quin usuari està realitzant la petició. D’aquesta manera, qualsevol persona que faci ús d’aquest endpoint podrà accedir a la informació o podrà alterar les dades emmagatzemades en la base de dades relacionats amb dita endpoint.

¿Cómo es una API sin autenticación?

Com és de suposar, aquest mètode no conté cap particularitat de cara a ser implementat.

Els avantatges que presenta són les següents:

  • A causa de la seva manca de necessitat de configuració, són simples d’implementar i utilitzar.
  • Tenen un accés ràpid, per la qual cosa són ideals per a serveis públics o per a poder recuperar dades que no necessiten ser protegits.
  • A causa d’aquesta absència de configuració és totalment vulnerable a atacs, qualsevol persona pot accedir a la API.
  • No es recomana el seu ús per a aplicacions que gestionin dades sensibles i molt menys per a qualsevol acció que pugui arribar a alterar les dades emmagatzemades.

En conclusió, aquest tipus de endpoints haurien de reservar-se per a dades simples. Com algun mètode que recuperi l’últim número o nom de la versió del producte, o per a recuperar els textos de traducció d’una pàgina pública.

API amb autenticació via API Key

L’autenticació en una API via API Key es basa en el fet que el propi sistema genera una clau que, en cada endpoint de la API, es comprovarà que estigui registrat en el servei per a poder accedir a les dades.

La implementació d’aquest mètode requereix de diversos passos. Te’ls expliquem:

  1. El primer és que cal identificar al proveïdor del servei (API) i al consumidor dels serveis del proveïdor (client).
  2. Una vegada identificats, s’ha d’implementar un endpoint mitjançant el qual, des del costat del proveïdor del servei, es generi una API Key associada a un client en concret amb una durada determinada del token. D’aquesta manera, el sistema té control de qui té accés a aquesta API, i fins quan pot tenir accés.
  3. Després d’això, l’usuari podrà accedir a l’aplicació del proveïdor del servei i podrà veure la API Key associada a la seva aplicació. També podrà ser forma automàtica, o bé després de ser validat per part del proveïdor. Així ja es pot anotar aquesta clau i autenticar totes les crides realitzades al proveïdor del servei des de la seva aplicació.
API con autenticación vía API Key

Cada vegada que es realitza una anomenada a un endpoint es comprova la validesa del token generat i, a continuació, ja s’elabora qualsevol acció que hagi de fer aquest endpoint.

Avantatges i desavantatges de l’autenticació via API Key

L’avantatge que ofereix aquest mètode d’autenticació és que permet controlar l’accés a la informació a un grup d’usuaris. És senzill de revocar, ja que des de l’aplicació del proveïdor de serveis es pot donar de baixa un token en qualsevol moment.

La part negativa és que les API Keys donen accés a la API directament i no fan una segregació per usuaris. D’igual manera, necessiten diversos passos intermedis per a configurar-ho, com generar la clau en el proveïdor i anotar aquesta clau en l’aplicació client. És important dir que qualsevol usuari que tingui el token podrà accedir a les dades encara que no sigui l’usuari que l’hagi generat.

Aquest tipus d’autenticació es reserva per a serveis que seran consumits per altres serveis. Per exemple, una API que presenta la informació climatològica i una pàgina web que ofereix dades sobre una ciutat en concret.

API amb autenticació via JWT (JSON Web Token)

JSON Web Token és un estàndard obert basat en JSON. Aquest crea tokens d’accés que permeten verificar la identitat d’un usuari, sense necessitat d’emmagatzemar informació addicional en el servidor.

L’autenticació mitjançant JWT segueix una estructura simple en la qual:

  • L’usuari s’autentica en l’aplicació proporcionant les seves credencials. Per exemple, proporcionant un usuari i una contrasenya.
  • L’aplicació envia aquestes credencials a un servidor d’autenticació. Si les credencials són vàlides el servidor genera un token JWT signat i l’envia a l’usuari com a resposta.
  • L’usuari integra aquest token d’autorització en la capçalera de cada sol·licitud que realitzi a la API.
  • La API passa a verificar en cada crida que rebi la validesa de dita token comprovant si és vàlid, si l’usuari està autoritzat i si el token no està caducat.
API con autenticación vía JWT (JSON Web Token)

Pros i contres de l’autenticació mitjançant JWT

Els avantatges que ofereix l’autenticació mitjançant JWT és que són tokens signats i encriptats, per la qual cosa la informació no es pot manipular. Com que no cal emmagatzemar informació de la sessió en el servidor la càrrega emmagatzemada en el servidor es redueix i se simplifica l’escalat de l’aplicació. Cal dir que la portabilitat dels tokens és òptima per a una arquitectura de microserveis, ja que són independents del domini de l’aplicació.

Els desavantatges d’aquesta implementació és que la revocació dels tokens és complexa, per la qual cosa no es pot llevar l’accés d’un token generat fins que es caduca. Per tant, fins que expira, pot ser utilitzat per a accedir als recursos de l’aplicació. Però, això pot ser solucionat activant un mètode de refresc del token i implementant una durada del token reduïda (per exemple, de 15 minuts). Tanmateix, això augmenta la complexitat a l’hora d’implementar aquest mètode d’autenticació.

API con autenticación vía OAuth 2.0

OAuth 2.0 és un estàndard d’autenticació que permet a un usuari o a una aplicació obtenir un accés limitat als recursos d’una API. Aquest protocol no proporciona credencials per a un usuari, sinó que emet tokens d’accés a les aplicacions client perquè actuïn en nom de l’usuari.

Això sol identificar-se fàcilment en tots els serveis que requereixen d’una confirmació d’accés a un compte ja existent d’un proveïdor de serveis, com pot ser Microsoft.

API con autenticación vía OAuth 2.0

Per a implementar això, l’encarregat ha de seleccionar un proveïdor de serveis. Per a aquest exemple, utilitzarem Azure Activi Directory.

Primer, s’haurà de registrar l’aplicació en l’Activi Directory, la qual cosa ens generarà un JSON necessari per a realitzar les peticions relacionades amb el servei d’autenticació. Dit JSON haurà de ser emmagatzemat en el fitxer de configuració de la nostra aplicació. 

L’aplicació client, en cadascuna de les peticions, comprovarà si existeix un token generat per Active Directory. En cas que aquest no existeixi, redirigirà a l’usuari al servidor d’autorització perquè autoritzi l’accés. Això es maneja per part del client de manera que s’emmagatzemaria internament en l’aplicació web o mòbil.

Després que l’usuari autoritza l’accés, l’Activi Directory redirigirà a l’usuari de tornada a l’aplicació client amb un codi d’autorització que aportarà un token d’accés, el qual pot ser reutilitzat per a fer sol·licituds a la API directament.

API con autenticación vía OAuth 2.0

Beneficis i desavantatges de l’autenticació via OAuth 2.0

Els avantatges que ofereix són notòries, ja que, principalment, les credencials de l’usuari no es comparteixen amb cap aplicació. A més, els tokens poden ser revocats directament sense afectar les credencials de l’usuari. Per tant, és especialment útil per a aplicacions amb múltiples usuaris, perquè permet una gestió òptima dels permisos proporcionats.

No obstant això, el principal desavantatge d’aquest mètode és que la implementació és més complexa en comparació a les altres opcions presentades en aquest article. Els passos en els quals l’usuari ha de donar el seu consentiment per a accedir a l’aplicació poden agregar una mica de temps a completar la sol·licitud. També requereix posar en mans d’un servei extern l’autenticació en l’aplicació. Per això, si aquest deixa de proveir el servei temporalment, cap usuari podrà accedir a l’aplicació.

Conclusions

En aquest article s’han presentat diverses formes d’autenticació per a protegir l’accés a dades sensibles en una API. No podem dir quin mètode és millor, ja que depèn totalment de quin sigui el context de l’aplicació.

Per exemple, seria excessiu muntar un servei d’autenticació OAuth 2.0 per a una API que únicament retorni dades públiques sobre els diferents fusos horaris en el món. Però sí que seria interessant aplicar una autenticació mitjançant API Key perquè només puguin obtenir aquesta informació unes persones comptades. I tu per quin apostes?

Elio San Martín – Software Developer at Itequia