¿Por qué España se está llenando de centros de datos y cables submarinos?

Iniciar sesión con Google o Apple parece un atajo inocente. Pero convierte tu acceso en una dependencia: si tu “llave” es ajena, una incidencia en esa llave puede dejarte fuera de servicios que ni siquiera pertenecen a quien te autentica.

Cuando tu identidad es una llave prestada

Durante años, crear una cuenta era “tener usuario y contraseña”. Hoy, en muchos servicios, el primer botón es “Continuar con Google” o “Iniciar sesión con Apple”. La promesa es comodidad: menos contraseñas, menos fricción, menos riesgo de que te la roben. La realidad es un intercambio: ganas facilidad, pero delegas una parte crítica de tu acceso en una identidad que no controlas del todo.

Qué es realmente: federación de identidad

En términos simples, un tercero (Google, Apple, Microsoft u otro) demuestra al servicio que tú eres tú. El servicio no guarda tu contraseña: confía en la “prueba” del proveedor de identidad. Eso se llama identidad federada o “single sign-on” (SSO).

sequenceDiagram
participant U as Usuario
participant P as Proveedor de identidad (Google/Apple)
participant S as Servicio (app/web)
U->>S: "Quiero entrar"
S->>U: "Ve al proveedor"
U->>P: Me autentico (biometría/clave/2FA)
P-->>U: Token de acceso (prueba firmada)
U->>S: Entrego token
S->>S: Verifico firma y permisos
S-->>U: Acceso concedido

Por qué se ha extendido tanto

1. Reduce abandono: cuantos menos pasos, más altas y más uso.
2. Traslada seguridad: el servicio “hereda” 2FA, biometría y detección de fraude del proveedor.
3. Menos soporte: menos “olvidé mi contraseña”, menos tickets.
4. Ecosistemas: la identidad se convierte en pegamento: apps, pagos, nube, dispositivos.

El coste oculto: exclusión, rastreo cruzado y poder asimétrico

El problema no es que sea “malo” iniciar sesión así. El problema es que cambia el punto único de fallo. Si tu cuenta del proveedor se bloquea, o si pierdes el dispositivo, o si falla una verificación, el daño se propaga.

Cuadro comparativo: cuenta propia vs. identidad prestada

Aspecto	Cuenta propia (usuario/contraseña del servicio)	Identidad prestada (Google/Apple/SSO)
Comodidad	Más fricción	Muy alta
Recuperación	Depende del servicio (email/soporte)	Depende del proveedor (y su criterio)
Punto único de fallo	Más distribuido	Más concentrado
Rastreo entre servicios	Más limitado por diseño	Puede aumentar si se cruzan señales
Portabilidad	Variable (a veces exportable)	Acceso ligado a mantener esa identidad

Dos confusiones frecuentes

1. “No doy mis datos”: aunque no des tu contraseña al servicio, sí entregas una prueba de identidad y, a veces, permisos (correo, perfil básico, contactos).
2. “Si me bloquean, el servicio me ayudará”: muchas veces no puede; el servicio confía en el proveedor y no tiene forma de saltárselo.

Línea de tiempo: de contraseñas a llaves externas

• 2000–2010: usuario/contraseña por servicio, reutilización masiva.
• 2011–2016: se populariza “Iniciar con…” y 2FA.
• 2017–2022: crece el acceso desde móvil y biometría como gesto cotidiano.
• 2023–hoy: más dependencia de cuentas “núcleo” para pagos, nube, dispositivos, y recuperación de identidad.

Implicaciones prácticas: cómo usarlo sin quedarte atrapado

1. Evita un solo punto único: para servicios críticos, valora tener método alternativo de acceso (correo + passkey, o cuenta propia).
2. Revisa permisos: si el login te pide más de lo necesario, no es “solo entrar”.
3. Cuida la recuperación: el verdadero riesgo aparece cuando pierdes el dispositivo o cambia tu número.
4. Separa identidades: una cuenta para lo personal y otra para experimentos o servicios prescindibles reduce el daño en cascada.

Cómo encaja este tema en el contexto actual

La identidad prestada se vuelve tentadora justo cuando la vida digital se llena de fricciones de acceso y de recuperación: por eso encaja con el salto hacia passkeys y el inicio de sesión “sin contraseña”, que empuja a usar llaves del dispositivo y cuentas núcleo como infraestructura de acceso (motor). Esa comodidad hace que “entrar” sea más fácil, pero también concentra dependencia.

Cuando esa dependencia falla, la experiencia se parece a otros bloqueos automáticos: no es solo perder una cuenta, sino perder continuidad. En ese sentido, el fenómeno se conecta con la idea de que lo automático puede convertirse en un muro, porque el proceso de recuperar acceso suele ser un embudo donde demostrar quién eres se vuelve más difícil que crearte la cuenta (consecuencia).

Y, como marco, ayuda entender cómo se desplaza el equilibrio cuando pasamos de “usuario” a “identidad verificable”: la transición que describe el paso del anonimato práctico a la trazabilidad explica por qué cada vez más funciones quedan ligadas a una identidad fuerte, y por qué quien controla esa identidad controla también parte de tu participación y tu acceso (marco).

1) Iniciar sesión con Google o Apple significa, sobre todo, que…

El servicio ya no necesita saber nada de ti.
El servicio confía en un tercero para verificar tu identidad mediante un token.
El tercero guarda tu contraseña del servicio.

2) ¿Cuál es el principal riesgo estructural de la identidad prestada?

Que el botón de acceso sea más lento.
Que el punto único de fallo se concentre en una cuenta núcleo.
Que sea imposible usar 2FA.

3) Una ventaja real del SSO para el servicio es…

Reducir soporte por contraseñas olvidadas y heredar seguridad del proveedor.
Evitar cualquier obligación de protección de datos.
Garantizar siempre una revisión humana si hay problemas.

4) Si tu cuenta del proveedor se bloquea, el servicio al que intentas entrar…

Siempre puede saltarse el bloqueo y dejarte entrar.
A menudo no puede ayudarte, porque su puerta de entrada depende del proveedor.
Te dará automáticamente una cuenta nueva con tus datos.

5) Para servicios críticos, una medida prudente es…

Usar siempre una única identidad para todo, sin alternativas.
Mantener un método alternativo de acceso o recuperación que no dependa solo del proveedor.
Desactivar cualquier forma de verificación adicional.