¡No soy tú! Soy yo… lo que pasa es que te estoy delegado en él, ¿me lo permitirás? Si, ¡Bien! buffff…. pues sí él eres tú y él dice que yo soy yo… ¡tú palante, con el permiso de él ¡Claro! ¡Ohautthhhh, qué dolor!
En este primer post sobre OAuth, voy a exponer un caso de uso, con el objetivo de poner en el escenario el protocolo e ir viendo su utilidad y usos posteriormente. Pocas aclaraciones técnicas, nos las guardamos para los siguientes posts.
Si necesitas aclarar los conceptos base sobre autenticación y autorización, quizás mi post anterior pueda ayudarte.
¡Ostras! Si has llegado hasta aquí, tienes interés y no puedo defraudarte, voy a intentar ser muy coloquial.
OAuth 2 es un protocolo que estandariza la delegación de la autorización (AuthZ), ¿te has quedado igual?, ok, vamos a por un ejemplo.
Recuerda, si quieres molar en este mundo del IAM, tienes que referirte a la autenticación como AuthN y a la autorización como AuthZ. ?
La necesidad.
Imagínate que estás desarrollando una aplicación, por ejemplo, una Web que dará un servicio y que colgaras de Internet. Además, tienes la necesidad de AuthN y AuthZ, ya que vas a necesitar identificar usuarios y asignarles un nivel de acceso… ¡para que no te rompan cosas!
Pues bien, para cumplir con estos requisitos de seguridad, vas a necesitar implementar o utilizar un Proveedor de identidad y sus ciclos de vida, eso es, un lugar donde almacenar los identificadores de usuarios, sus contraseñas y los procedimientos para darlos de alta, baja, administrar su existencia y una gestión de sus estados… Olvidos de contraseñas, etc.
Supón que no deseas disponer de tu propio almacén de credenciales o prefieres aliviar la experiencia del usuario dando la posibilidad de que empleen las credenciales que puedan tener en un proveedor de identidad externo, típicamente, su cuenta de google, Facebook, Twitter, Google, Azure AD o recientemente Apple ID, ¡pero existen muchos más!
Resumiendo, lo que deseas es que cuando el usuario haga click en uno de los botones de la derecha, ese proveedor el login resuelve la identidad del usuario y a nuestra aplicación llegue una prueba de todo correcto que nos sirva para el AuthZ en nuestra Web y adicionalmente de los posibles servicios que pueda disponer este tercero.
Para implementar todos estas posibilidades, podríamos encontrarnos que cada caso es particular. Afortunadamente para nosotros y también para los proveedores, existe OAuth como un protocolo que estandariza esta necesidad.
The OAuth 2.0 Authorization Framework ?¡Un poco de rock’n’roll!
Flujo interactivo
Continuamos, para que realices estas integraciones, tendrás que leerte la documentación del proveedor, normalmente, dispondrá de una consola donde tramitar todo este proceso.
Los pasos serían los siguientes, más o menos, será necesario que des de alta tu aplicación, te asignarán un identificador (ClientID) y una contraseña (Client Secret), te preguntarán si los usuarios son humanos o máquinas (el primero, el flujo interactivo), nos solicitarán que indiquemos URI de redirección (dónde te van a entregar el resultado) y que definimos unos scopes (A que recursos podrá acceder el usuario, aqui esta la chica del AuthZ). Profundizaremos en esto en los siguientes siguiente post, es de las partes más importantes que hay que entender.
Tras esto, normalmente nos facilitarán los parámetros para integrar tu aplicación… ¿Continuamos? ¿Si?
Configurando la aplicación
Deberás buscar una buena librería para OAuth apropiada a la tecnología con la que hayas escrito tu Web, la integramos y la configuramos, con los parámetros que nos dio el proveedor, un ejemplo sería algo así:
client id: my super disruptive web ID grant type: authorization code with PKCE client secret: secret scopes: apiweb1 apiwebexterna2 offline_access
Y si todo ha ido bien, la experiencia de usuario será la siguiente:
- Un usuario llegará a tu web, y pulsará el botón de identificarse empleando el proveedor externo.
- Su navegador, será redireccionado al proveedor, el usuario introducirá sus credenciales y quizás sea sometido a un tercer grado, si son correctas, el control es devuelto a tu aplicación la cual recibirá un token de acceso validado por el proveedor y con los scopes que indican el nivel de Autorización otorgado.
- Cada vez que el usuario se mueva por tu web, enviará este token, que tú deberás comprobar su firma, su tiempo de caducidad y sus scopes en los accesos para validar al usuario identificado
Faltan muchas cosas, pero han ocurrido otras muchas interesantes que te resumo.
Conclusiones
- El usuario utilizará su cuenta de un servicio externo para demostrar tu identidad, que es este caso te interesa. ¡Podría haber sido que no!
- Las contraseñas no pasan por nuestro aplicación, ni nos tendremos que preocupar por el ciclo de vida de ellas. Los cierres de sesión, los singlesignon, los refrescos… ¡casi nada!
- Es posible, que la experiencia de usuario y la fricción del alta de cuenta sea mucho mejoren.
- Estos proveedores, invierten mucho en seguridad. Podrás parametrizar la caducidad del acceso y cómo son sus refrescos
- ¿Y si fuera al revés? Igual te interesa ser un proveedor, con sus ventajas e inconvenientes y que terceros se integren contigo.
Siguiente parada, un ejemplo de como configurar esto con dos o tres proveedores y nos vamos a lo técnico.
¡A darle caña!