¿Qué es OAuth 2.0?

OAuth 2.0: definición e importancia

Antes, los usuarios entregaban su contraseña a aplicaciones de terceros para que pudieran acceder al correo o al calendario, un riesgo considerable. OAuth 2.0 lo resuelve: el usuario permite a una aplicación un acceso concreto y la contraseña permanece en el servicio correspondiente. El estándar está publicado desde 2012 como RFC 6749 y es la base de muchos inicios de sesión e interfaces.

Conviene distinguir bien: OAuth 2.0 regula la autorización, es decir, lo que una aplicación puede hacer. Para el inicio de sesión (¿quién es el usuario?) se emplea normalmente OpenID Connect, que se basa en él. Ambos aparecen, por ejemplo, en «Iniciar sesión con Google» o «Iniciar sesión con Microsoft».

Cómo funciona OAuth 2.0

Intervienen cuatro roles: el usuario como propietario del recurso, la aplicación como cliente, el servidor de autorización, que comprueba la concesión, y el servidor de recursos con los datos protegidos. El usuario es dirigido al servidor de autorización, inicia sesión allí y confirma qué permisos (scopes) recibe la aplicación.

La aplicación obtiene entonces un token de acceso de corta duración y, en su caso, un token de actualización para conseguir nuevos tokens de acceso. Para aplicaciones web y móviles, el método recomendado es el flujo de código de autorización con PKCE; para conexiones entre servidores se usa el flujo de credenciales de cliente. Variantes antiguas como el flujo implícito se consideran obsoletas.

Ejemplo práctico: reserva de citas con acceso al calendario

Una consulta de fisioterapia usa un sistema de reservas que debe registrar automáticamente las citas reservadas en el calendario de Google u Outlook de los terapeutas. Antes habría que haber almacenado credenciales para ello; hoy basta una autorización mediante OAuth 2.0, en la que la contraseña nunca llega al sistema de reservas.

La terapeuta confirma una sola vez que el sistema puede crear entradas en el calendario, y nada más. Puede revocar el acceso en cualquier momento sin cambiar su contraseña. El sistema solo guarda los tokens, a ser posible cifrados, y solicita otros nuevos automáticamente cuando caducan.

Ventajas, límites y errores habituales

OAuth 2.0 separa contraseña y acceso, permite permisos finamente graduados y revocables y cuenta con un amplio soporte. Pero el estándar es un marco con muchas variantes, y en la implementación surgen con facilidad brechas de seguridad, porque detalles como las redirecciones y el almacenamiento de tokens son responsabilidad propia. Errores típicos:

• Usar flujos obsoletos como el flujo implícito o la concesión por contraseña
• Guardar tokens en el código fuente, en URL o en texto plano en la base de datos
• Solicitar scopes demasiado amplios en lugar de solo los permisos necesarios
• No definir ni comprobar con exactitud las URI de redirección
• Confundir OAuth con el inicio de sesión y prescindir de OpenID Connect

Qué debe tener en cuenta su empresa

Apueste por bibliotecas contrastadas y servicios de identidad reconocidos en lugar de desarrollos propios, solicite solo los permisos necesarios y planifique la revocación y la rotación de tokens. Nano Concepts conecta servicios como Microsoft, Google o plataformas sectoriales mediante OAuth 2.0 y protege las interfaces de portales y aplicaciones.