01 Contexto y problema
Un grupo de consumidores gestionaba nueve marcas separadas en una plataforma compartida para clientes. Un cliente podría crear una cuenta una vez y reutilizarla en cualquier lugar, iniciando sesión con Apple, Google o correo electrónico y contraseña. El inicio de sesión social estaba pensado como una vía principal de entrada, no como una comodidad secundaria, por lo que la misma persona a menudo llegaba a través de diferentes proveedores en distintos momentos: Google en una marca, Apple en otra, y una contraseña después.
Esa flexibilidad creó un problema de identidad. Cuando un cliente iniciaba sesión con una nueva identidad de Apple o Google cuyo correo electrónico ya pertenecía a una cuenta existente, la plataforma tenía que decidir qué hacer. Vincular ambos automáticamente solo con un emparejamiento de correo electrónico sería inseguro: una dirección de correo coincidente sugiere una relación, pero no prueba que la persona que inicia sesión controle realmente esa bandeja de entrada. La plataforma necesitaba una forma de conectar identidades compatibles de Apple y Google a una sola cuenta compartida sin conceder nunca acceso a una coincidencia de correo electrónico por sí sola, y hacerlo de forma consistente en las nueve marcas, incluidos los casos incómodos: las direcciones privadas de Apple en relés, cuentas con contraseña, inicios de sesión arriesgados y caídas de proveedores.
02 Rol y Limitaciones
Como AI Product Manager yo era responsable del diseño de identidad y vinculación de cuentas de principio a fin: los procesos de autenticación entre las nueve marcas, la lógica de detección y resolución de correos electrónicos, el modelo de verificación que bloqueaba el enlace, la política de desafíos basada en riesgos, la gestión de relés privados, las reglas de desvinculación y reverificación en cambio de correo electrónico, la política de bloqueo y el comportamiento de fallo seguro para las caídas de proveedores. El principio guía era que la coincidencia de correos electrónicos podía iniciar un proceso de enlace, pero nunca completarlo. El cliente siempre tenía que demostrar el acceso al correo vinculado a la cuenta existente antes de que se asociaran dos métodos de autenticación a un solo perfil.
Las limitaciones eran concretas. El enlace tenía que ser bidireccional e independiente del orden: primero Google y luego Apple, o Apple primero y luego Google, tenía que llegar a la misma cuenta compartida. Ocultar mi correo electrónico de Apple tuvo que gestionarse por separado, porque una dirección de retransmisión privada que no coincidiera con el correo real de la cuenta del cliente no debe vincularse silenciosamente a esa cuenta. La verificación tuvo que reutilizar el mismo mecanismo de desafío de código que ya era confiable para la autenticación de alto riesgo, por lo que vincular heredó controles probados en lugar de inventar nuevos. El riesgo debía modular la fricción: los registros de bajo riesgo debían mantenerse sin fricción, mientras que el riesgo medio, alto e indeterminado requería un OTP. Los fallos repetidos debían contenerse mediante una política de bloqueo que se aplicaba a nivel de cuenta, en todas las marcas, no por cada marca. Y los fallos de los proveedores tenían que ser de forma segura, sin dejar nunca a un cliente con una cuenta parcial o duplicada.
03 Enfoque del producto
El replanteamiento principal fue tratar una coincidencia por correo electrónico como el inicio de un proceso de verificación, no como prueba de propiedad. Cuando Apple o Google autenticaban a un cliente, la respuesta del proveedor y su correo electrónico se resolvían en el servidor contra la plataforma de cuentas compartidas. Si el correo coincidía con una cuenta existente, la plataforma aún no enlazaba nada. Emitía un código único al correo electrónico de la cuenta existente y vinculaba al nuevo proveedor solo después de que el cliente introdujera ese código. Solo se asignaron dos métodos de autenticación a un perfil cruzado una vez demostrada la propiedad.
El mismo camino verificado cubría ambas direcciones de enlace. Si un cliente creaba una cuenta con Google y luego elegía Continuar con Apple usando el mismo correo compartido, el sistema detectaba la cuenta existente, enviaba un código a su correo electrónico y vinculaba a Apple tras una verificación exitosa. Al revés, primero Compartir mi correo electrónico de Apple y luego Google se resolvió con la misma cuenta compartida mediante el mismo desafío. Tras vincularse, el cliente podía iniciar sesión con Apple, Google o con correo electrónico y contraseña donde se hubiera configurado, y aterrizar en la misma cuenta.
El programa Ocultar mi correo electrónico de Apple se mantuvo deliberadamente por un camino separado. Cuando la dirección de retransmisión privada no coincidía con el correo personal no revelado del cliente, las identidades no eran elegibles para vincular el mismo correo electrónico. En lugar de vincular el relé a una cuenta no relacionada, la plataforma mostró una explicación de acceso limitado y creó una cuenta de correo electrónico de retransmisión separada. Más allá de la primera conexión, la misma cuenta tenía su propio ciclo de vida: un cliente podía establecer una contraseña en una cuenta social, cambiar el correo electrónico principal (lo que desvinculaba al proveedor social anterior y requería una nueva verificación), y cada inicio de sesión que regresaba pasaba por una evaluación de riesgos antes de que se emitiera la sesión.
Un correo electrónico coincidente parece una prueba de identidad, pero solo es una señal. La plataforma lo utilizó para abrir un proceso de verificación, sin conceder acceso. Las identidades compatibles de Apple y Google se vinculaban a una sola cuenta compartida solo después de que el cliente completara un desafío de código de correo electrónico, por lo que una coincidencia iniciaba la verificación en lugar de fusionar automáticamente dos inicios de sesión.
04 Características construidas
Inicio de sesión de Apple y Google
Un orquestador de autenticación enruta Continuar con Apple, Continuar con Google y iniciar sesión con contraseña entre las nueve marcas.
Cuenta compartida entre marcas
Un cliente crea una cuenta una vez y la reutiliza en todas las marcas, sea cual sea el proveedor a través del que llegue.
Detección de mismos correos electrónicos
La resolución de identidad en el servidor se activa cuando el correo electrónico de un nuevo proveedor ya pertenece a una cuenta existente.
Desafío de código de correo electrónico
Debe introducirse un código de un solo uso enviado al correo electrónico de la cuenta existente antes de vincular a dos proveedores.
Enlace bidireccional
Google primero y luego Apple, o primero Apple y luego Google, resuelven la misma cuenta compartida a través del mismo desafío.
Ruta de relé privado de Apple
Ocultar mis direcciones de correo electrónico que no coinciden no están vinculadas; En su lugar, se crea una cuenta de correo electrónico de retransmisión separada.
OTP basado en riesgos
Los inscritos de bajo riesgo tienen una sesión; Riesgo medio, alto y indeterminado requiere un OTP por correo electrónico antes de acceder.
Bloqueo a nivel de cuenta
Fallos repetidos de OTP, código o contraseña bloquean la cuenta compartida en las nueve interfaces de las marcas.
Configuración de contraseñas para redes sociales
Los clientes pueden añadir un inicio de sesión con correo electrónico y contraseña a una cuenta creada primero a través de un proveedor social.
Desvinculación del proveedor tras el cambio de correo electrónico
Cambiar el correo principal desvincula el proveedor social anterior y requiere una nueva verificación del proveedor.
Recuperación segura por fallos del proveedor
Los fallos de los servicios de Apple o Google devolven un error seguro y lo intentan de nuevo, evitando cuentas parciales o duplicadas.
Contraseña + paridad social
Una vez configurada una contraseña, el correo electrónico y la contraseña funcionan junto a Apple y Google como un inicio de sesión igualitario.
También se incluyeron: configuración de contraseña para las cuentas sociales, correo electrónico y contraseña como inicio de sesión adicional una vez configurados, cambios de correo electrónico con control de contraseña, re-verificación del proveedor tras un cambio de correo, gestión de riesgos indeterminados y un proceso de seguridad consistente independientemente de la marca desde la que partiera el cliente.
Arquitectura 05
Nueve experiencias de marca alimentaron a un solo orquestador de autenticación. Un cliente que llegaba a través de cualquier marca era encaminado al mismo flujo: continuar con Apple, continuar con Google, o enviar correo electrónico y contraseña. Las respuestas de Apple y Google pasaban por la validación de la respuesta del proveedor y luego la resolución de identidad en la plataforma de cuentas compartidas, mientras que los inicios de sesión por contraseña se resolvían directamente a la cuenta compartida. Identity Resolution planteó dos preguntas en orden: ¿este proveedor ya está vinculado y, si no, existe alguna cuenta de correo electrónico compatible con la que enlazar?
A partir de ahí, el flujo se ramificó hacia resultados claramente delimitados. Una coincidencia de correo electrónico elegible emitía un código de enlace al correo de la cuenta existente; tras una verificación exitosa, el proveedor se vinculaba; en caso de fallo, el intento era rechazado y registrado. Un correo electrónico de Apple que no coincidía se enrutaba a una explicación de acceso limitado y a una cuenta de correo electrónico separada. Una vez resuelta a una cuenta compartida entre marcas, se comprobaba el estado de la cuenta: una cuenta bloqueada se mostraba como bloqueada, una cuenta activa se clasificaba en una categoría de riesgo. Bajo riesgo emitió directamente una sesión autenticada; el riesgo medio, alto e indeterminado envió un OTP de autenticación, y repetidos desafíos fallidos, hasta un umbral fijo, bloquearon la cuenta compartida entre las nueve marcas. La cuenta en sí expuso cambios de configuración de contraseñas y correo electrónico, donde cambiar el correo principal desvinculaba al proveedor social anterior y requería una nueva verificación del proveedor. Los fallos del servicio del proveedor no creaban un estado parcial: devolvían un error seguro y lo intentaban de nuevo que se enrutaba de nuevo al mismo orquestador, por lo que una llamada fallida de Apple o Google nunca producía una cuenta a medias vinculada o duplicada. El límite de enlace combinaba tres comprobaciones: una respuesta validada del proveedor, una coincidencia compatible con el mismo correo electrónico y un desafío exitoso del código de correo, y las entregas fallidas de código pasaban por la misma política de control de desafíos y bloqueo que los OTP de riesgo.
06 Medición y Análisis
Los recorridos de identidad se midieron como un embudo desde la autenticación del proveedor hasta la resolución, verificación y emisión de sesión, de modo que una caída pudiera rastrearse hasta la etapa que la causó: respuesta del proveedor, detección del mismo correo electrónico, desafío de código, puntuación de riesgos o bloqueo. Los datos disponibles apoyaban una estimación combinada de adopción, aproximadamente cuarenta mil de cien mil visitantes diarios por marca usando un viaje de Apple, Google o vinculado a cuentas, pero deliberadamente no exageraron lo que no podía separar. Apple contra Google, registro frente a inicio de sesión que devuelva, cuentas recién vinculadas frente a cuentas previamente vinculadas, desafíos de código exitosos frente a abandonados, cuentas de Apple por correo relé frente a correo compartido, y cualquier reducción de cuentas duplicadas, fraude o contacto de soporte quedaron sin cuantificar hasta que sus análisis subyacentes estuvieron disponibles, en lugar de reportarse como cifras precisas.
Métricas de adopción
Cuota de visitantes diarios por marca que utiliza Apple, Google o un recorrido de cuentas vinculadas, agregado entre las nueve marcas.
Embudo de verificación
Respuesta del proveedor, detección del mismo correo electrónico, código enviado, código verificado y vinculado al proveedor, medido etapa a etapa.
Riesgo y métricas OTP
Distribución por categorías de riesgo, tasas de desafío de OTP para riesgos medios, altos e indeterminados, y éxito y abandono de OTP.
Métricas de fallo y bloqueo
Los códigos de enlace fallidos, los OTP de riesgo y las contraseñas contaban para el umbral fijo y los bloques a nivel de cuenta aplicados.
Métricas de proveedor y relé
Cuentas de Apple entre correo de retransmisión y correo compartido, y fallos en el servicio de los proveedores enrutados en un reintento seguro.
07 Verificación y Toma de Decisiones de Riesgos
La capa de decisión respondía a una secuencia de preguntas estrechas en lugar de un solo sí o no. ¿Este proveedor ya está vinculado? Si no es así, ¿existe alguna cuenta de correo electrónico compatible con el mismo eje o es una dirección de Apple Relay que no es elegible? Si es elegible, ¿el cliente ha demostrado la propiedad a través del desafío del código de correo? Y en cada inicio de sesión resuelto, ¿cuál es la categoría de riesgo de la cuenta y requiere eso un OTP antes de emitir una sesión? Bajo riesgo continuó en una sesión autenticada; el riesgo medio, alto e indeterminado requería un OTP por correo electrónico; y fallos repetidos, ya fuera en un código de enlace, un OTP de riesgo o una contraseña, se contaban mediante un mecanismo compartido de control de desafíos que bloqueaba la cuenta a un umbral fijo. El riesgo aquí modulaba la fricción y la fuerza de verificación; No decidía la identidad por sí sola, y nunca reemplazó la prueba de propiedad que bloqueaba el enlace.
La vinculación de cuentas estaba protegida por un desafío de código, no se completaba mediante una coincidencia por correo electrónico. El límite combinaba una respuesta validada de Apple o Google, una cuenta de correo electrónico compatible y una verificación exitosa por correo electrónico. Un correo electrónico coincidente abrió el viaje; El cliente aún tenía que demostrar el acceso al correo electrónico en la cuenta existente antes de que se asociaran dos inicios de sesión en un perfil cruzado de marcas.
08 Estado y resultado
La implementación estableció la autenticación social como un canal de acceso principal en lugar de una opción secundaria de inicio de sesión. Los clientes podían registrarse en Apple o Google, reutilizar la misma cuenta en las nueve marcas, vincular identidades compatibles de Apple y Google tras un desafío de código de correo electrónico, añadir una contraseña a una cuenta social y avanzar en un proceso de seguridad constante independientemente de la marca desde la que empezaran. Cada marca recibió aproximadamente cien mil visitantes diarios, y aproximadamente cuarenta mil por marca al día usaron un recorrido de Apple, Google o cuentas vinculadas: se estima que un cuarenta por ciento de interacción con redes sociales o acceso vinculado. En las nueve marcas, eso supone aproximadamente novecientos mil visitantes diarios y alrededor de trescientos sesenta mil viajes diarios en redes sociales o cuentas vinculadas. El resultado fue una base de autenticación compartida en la que Apple, Google y el acceso a contraseñas funcionaban como métodos controlados alrededor de una sola cuenta de cliente de marca cruzada, con la vinculación bloqueada por verificación, los inicios de sesión arriesgados bloqueados por OTP, el relé privado gestionado por separado y los fallos repetidos contenido por el bloqueo a nivel de cuenta. Estas cifras son aproximadas y se basan en la proporción suministrada; Combinan la actividad social y la de cuentas vinculadas en lugar de separar cada proveedor o tipo de viaje.
~40%
Visitantes diarios usando un recorrido social o vinculado (por marca)
9
Marcas de consumo en una cuenta compartida
~360K
Viajes diarios de Apple, Google o cuentas vinculadas
~900K
Total de visitantes diarios en todo el grupo
09 Reflexión / Qué sigue
El logro definitorio fue no añadir botones de Apple y Google. Estaba construyendo los controles de identidad que hacían que el acceso social fuera seguro y reutilizable a través de nueve marcas: la plataforma podía saber si la identidad de un proveedor era nueva, ya vinculada, elegible para vincular, usando un relé privado, con contraseña, arriesgada o bloqueada, y vinculaba identidades compatibles solo tras un desafío de código de correo electrónico. Lo que reforzaría a continuación: separar las analíticas que hoy en día permanecen combinadas (Apple frente a Google, registro frente a inicio de sesión, nuevo frente a previamente vinculado, éxito del desafío frente a abandono, retransmisión frente a correo compartido) para que el embudo pueda ajustarse con evidencias en lugar de estimaciones; formalizar las definiciones de categorías y umbrales del modelo de riesgo con una gobernanza explícita; endurecer la guía de cuentas de relay para que los clientes entiendan por qué un inicio de sesión de Ocultar mi correo electrónico creó una cuenta separada; y mantener las reglas de desvinculación y reverificación en cambios de correo electrónico auditables de principio a fin. El resultado duradero fue una capa de autenticación compartida donde un correo electrónico coincidente iniciaba la verificación en lugar de conceder acceso automáticamente, y los inicios de sesión de Apple, Google y contraseñas funcionaban como métodos controlados y vinculables alrededor de una única cuenta de cliente de marca cruzada.