[OTROS] FLUJO DE AUTORIZACIÓN EN OAUTH 2.0
1. ¿Qué es OAuth 2.0?
Si alguna vez has ingresado a una aplicación usando tu cuenta de Google, Facebook, GitHub u otra plataforma, sin escribir una contraseña nueva, entonces ya has utilizado OAuth 2.0 sin darte cuenta.
OAuth 2.0 es un estándar de autorización, no de autenticación. Esto es importante, porque su objetivo principal es permitir que un usuario dé acceso limitado a sus datos en un servicio, sin compartir su contraseña. Es decir, más que decir “quién eres”, OAuth 2.0 se encarga de “qué puedes hacer”.
Este estándar surgió porque el modelo tradicional donde los usuarios entregaban sus credenciales directamente a aplicaciones de terceros era demasiado riesgoso. Con OAuth 2.0, las contraseñas dejan de circular entre sistemas, y en su lugar se utilizan tokens temporales, que pueden expirar, revocarse o renovarse.
Lo interesante es que OAuth 2.0 funciona bien en muchas situaciones: desde un simple login hasta la protección de APIs en arquitecturas modernas. Por eso es uno de los protocolos más utilizados en la actualidad, tanto en servicios web como en aplicaciones móviles.
2. ¿Cómo funciona OAuth 2.0?
OAuth 2.0 no es complicado, una vez entiendes sus piezas, todo tiene sentido. A grandes rasgos, intervienen tres actores:
- Usuario: Es el dueño de los datos. Por ejemplo, tú, cuando autorizas que una app acceda a tu perfil de Google.
- Cliente (la app): Es la app que quiere usar esos datos, como una aplicación de notas que quiere leer tu nombre o correo.
- Servidor de Autorización:: Es el encargado de validar tu identidad y entregar permisos como Google, Facebook, GitHub.
- Servidor de Recursos: Es quien almacena los datos protegidos (como tu email o tus fotos). A veces está integrado en el mismo proveedor, por eso no siempre se menciona aparte.
3. Flujo general explicado paso a paso
Este es el proceso simplificado que sigue el flujo más común (Authorization Code):
- La app solicita permisos: Por ejemplo, te redirige a Google y te pregunta si permites compartir tus datos.
- El usuario acepta desde el servidor de autorización: Aquí Google te pide iniciar sesión (si no lo estabas) y confirmar que aceptas.
- El servidor envía un Authorization Code: Este código es temporal y sirve únicamente para obtener un token.
- La app intercambia el código por un Access Token: Aquí la app lo envía a Google desde su backend, y Google responde con un token.
- La app usa el token para acceder a recursos protegidos: Con ese token, la app puede obtener tus datos autorizados (como tu nombre o email).
4. Tipos de Grant en OAuth 2.0
Uno de los primeros retos de entender OAuth 2.0 es distinguir los diferentes "flujos" o grants. Los más comunes son:
Authorization Code Flow: El más seguro y usado en web apps modernas, ideal cuando hay un backend que puede guardar secretos.
Client Credentials Flow: Para comunicación entre servicios, sin intervención del usuario, ideal para microservicios.
Password Grant (deprecado): Permitía enviar usuario y contraseña directamente, ya no se recomienda porque es inseguro.
Implicit Flow (también deprecado): Pensado para SPAs sin backend, pero ya se considera riesgoso, hoy se recomienda usar Authorization Code + PKC.
5. ¿En qué casos debemos usar OAuth 2.0?
OAuth 2.0 es útil cuando:
Necesitas integrar "Iniciar sesión con Google/Facebook/GitHub".
Quieres que tu sistema permita que apps externas usen tus APIs.
Debes proteger recursos en una API REST.
Gestionas autenticación en aplicaciones móviles.
Creas un ecosistema de microservicios con acceso seguro.
CONCLUSIÓN
La importancia de OAuth 2.0 radica en su capacidad para reducir el uso de contraseñas, uno de los puntos más vulnerables de cualquier sistema. Al reemplazar credenciales por tokens controlados, con expiración y permisos definidos, se minimizan ataques y accesos no deseados. Este enfoque token-based se ha convertido en el estándar más confiable para proteger recursos, APIs y servicios externos. Comprender OAuth 2.0 es entender cómo funciona la seguridad moderna.
No hay comentarios:
Publicar un comentario