Autenticación de APIs: qué es y porqué importa
Tags: spanish, api
Published: 2022-06-13 04:23:39

¿Qué pasa cuando un servidor permite acceso a sus datos indiscriminadamente?

Lo mismo que pasa si le prestamos dinero a otras personas indiscriminadamente. Siempre estará ese pequeño grupo de personas que se aproveche.

Lo que te voy a contar es como se establece la confianza en la web. Como los actores se identifican ante otros para acceder al contenido que solicitan. Voy a mostrarte como la autenticación en la web ha evolucionado, haciendo la comunicación entre páginas cada vez más automatizada y más segura.

Empecemos con un breve repaso.

Primero vamos a recordar que en todo proceso de autenticación hay tres actores: usuario, cliente y servidor. El usuario es la persona de carne y hueso que quiere conectar dos equipos, el cliente es el equipo que solicita la información y el servidor es el equipo que comparte la información.

Los servidores comparten información en la web a partir de APIs [puedes ver mi post anterior sobre el tema](https://dev.to/ledacoding/entiende-que-es-una-api-en-un-minuto-41nd). Esto sigue un ciclo de _request_ _response_, donde el cliente y servidor siguen un protocolo donde uno solicita y otro responde.

Para que el servidor confíe se han usado varios mecanismos:
- Basic Auth
- API Key
- O Auth 

El primer mecanismo es lo más sencillo que nos podemos imaginar. Basic Auth, es una forma corta de decir _basic authorization_.

Es algo así:

![Modelo de Basic Auth para aplicaciones de Rust [Acceder a fuente](https://github.com/EstebanBorai/http-auth-basic)](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/47i438tl8h05w2iey8fw.png)

Esto sigue un sistema muy familiar: la combinación _user:password_. De manera análoga a como nosotros nos identificamos en una página web lo hace Basic Auth. En su caso usa la combinación _user:password_ del usuario y lo pasa por un proceso de encriptación. Luego lo pone en los Headers como parte la HTTP Request bajo el nombre "Authorization".

Se podría ver así:

```
Authorization: Basic tZNlpmtwXYNzd29sTAe=
```

El servidor tiene una lista _user:password_ de sus usuarios y si ve esos credenciales están en su lista le dejará pasar. Básicamente usa la misma información para acceder a la cuenta del dueño y para acceder a los APIs. Esto le de un acceso amplio a los datos del servidor. Aquí el cliente no es solo un visitante, es alguien de la casa.

¿Que pasa entonces si queremos restringir más el acceso?

Introducimos API Keys. Con API Keys el dueño de la cuenta da acceso al cliente compartiendo una llave secreta, no su usuario.  Como las llaves de un hotel, el invitado solo ingresa al cuarto que le corresponde. A diferencia de Basic Auth, el protocolo para usar API Keys no está estandarizado. En algunos casos el cliente escribe esta llave en la sección de Headers de la HTTP request y en otros casos lo hará en la URL.

![Diagrama de _request_ con API Keys [Acceder a fuente](https://blog.restcase.com/4-most-used-rest-api-authentication-methods/)](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0vo2ow2tx9zuisk5xocu.png)

Tanto este método como el anterior tienen un problema: la experiencia de usuario no es la mejor. Parte de la configuración de cliente y servidor debe hacerse manualmente y hay una posibilidad alta de cometer errores. 

O Auth mejora todo esto. Con este sistema la experiencia de usuario se ve como un simple _logueo_ pero de fondo cliente y servidor están trabajando para automatizar el intercambio de llaves.

El proceso que O Auth suele seguir en la web es:

1. El usuario le dice al cliente que se conecte con un servidor.
2. El cliente dirije el usuario al servidor compartiendo una URL de partido (_callback_ URL)
3. El usuario se _loguea_ y le da acceso al cliente
4. El servidor envía de vuelta al usuario a la URL previa compartiendo un código de autorización en el fondo
5. El cliente hace una nueva petición con el código de autorización y la llave secreta del cliente. El servidor responde con un token de acceso
6. El cliente utiliza el token de acceso para acceder al contenido del servidor

Visto gráficamente sería algo así (numeración varía):

![Modelo de O Auth 2 [Acceder a fuente](https://goteleport.com/blog/how-oauth-authentication-works/)](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/du63i5rhigs68gjs5duv.png)

Este proceso aunque aparentemente más largo, permite una experiencia de usuario realmente sencilla. Vemos que solo en un paso el usuario tiene que tomar acción directa, lo demás está totalmente automatizado, a la vez que hace el proceso más seguro. O Auth tiene 2 versiones: O Auth 1 y O Auth 2. Se espera que encontremos más APIs con Auth 2 por ser última versión, y la que se considera más cómoda y segura. 

Hemos visto brevemente como la web ha evolucionado para ser más segura y predecible, y que con un simple _logueo_ hay un gran proceso detrás de autenticación en muchas de las páginas que usamos. Esto nos dará más claridad a la hora de utilizar los diferentes modelos de autenticación y también saber que está pasando cuando accedemos a páginas como usuarios.

Espero este texto haya sido útil. Para finalizar comparto un apartado con los conceptos clave.

**Conceptos clave**

- Autenticación: proceso por el cual un cliente prueba su identidad ante un servidor
- Basic Auth: sistema de autenticación que utiliza la encriptación de un usuario y una contraseña como credenciales
- API Keys: preceso de autenticación que utiliza llaves secretas como credenciales
- O Auth: sistema de autenticación que automatiza el intercambio de llaves secretas entre usuario y servidor.