SSO e identidad federada para programas B2B con distribuidores y socios
En un programa B2B, la persona participa en nombre de una empresa, distribuidor o socio cuya relación puede cambiar. SSO e identidad federada permiten delegar autenticación a un proveedor de identidad, pero no resuelven por sí solos el alta de la organización, la asignación de privilegios ni el retiro de acceso cuando termina la relación comercial. El diseño debe distinguir OAuth, OpenID Connect, identidad, membresía y autorización; mapear atributos con cautela; y preservar una ruta de soporte. KA-034 modela cuenta y persona, mientras KA-069 gobierna permisos internos. Esta guía decide cómo aceptar una identidad externa sin convertir sus claims en autoridad automática dentro del programa.
El acceso B2B no es un registro de consumidor
En una red de distribuidores, instaladores o aliados, la persona entra en representación de una organización. Su elegibilidad, rol y acceso dependen de una relación comercial que puede cambiar. Pedir una contraseña adicional para cada portal aumenta fricción y deja cuentas activas cuando alguien cambia de empresa. El inicio de sesión único puede trasladar la autenticación a un proveedor de identidad empresarial, mientras la plataforma conserva reglas propias de participación y autorización.
Federar no significa entregar control completo al socio. El programa sigue decidiendo qué organizaciones están habilitadas, qué roles reconoce y qué datos o acciones expone. El proveedor de identidad afirma quién se autenticó según un contrato; la plataforma vincula esa identidad con una cuenta, persona y permisos. Esta separación evita confundir prueba de acceso con elegibilidad comercial.
OAuth y OpenID Connect cumplen trabajos distintos
OAuth 2.0 es un marco de autorización para que una aplicación obtenga acceso limitado a recursos sin recibir la contraseña del usuario. OpenID Connect añade una capa de identidad sobre OAuth y permite que un cliente verifique al usuario y reciba información acordada. En un proyecto SSO, usar los términos con precisión importa porque un access token no debe tratarse automáticamente como prueba de identidad y un ID token no debe enviarse a cualquier API.
La arquitectura define cliente, proveedor de identidad, redirect URIs, audiencias, scopes, tokens y claves. Cada valor necesita validación estricta. El flujo elegido depende del tipo de aplicación y del riesgo; no se improvisa copiando un ejemplo. También se necesita un mecanismo para descubrir claves, rotarlas y manejar indisponibilidad del IdP.
Mapear persona, organización y relación
Una identidad federada suele entregar un identificador estable del sujeto dentro de un emisor. El correo puede cambiar y no siempre es una clave confiable. La plataforma debe guardar la relación entre emisor, subject, persona y organización, además del origen de la asociación. Si dos socios usan el mismo correo o un proveedor reasigna direcciones, un match simple puede otorgar acceso incorrecto.
El alta necesita decidir quién puede vincular por primera vez, qué ocurre si ya existe un perfil y cómo se resuelven fusiones. La invitación previa reduce riesgo; el aprovisionamiento automático acelera onboarding, pero requiere dominios y claims confiables. La organización debe elegir según escala y gobernanza. Cada asociación y cambio quedan auditados para que soporte pueda explicar el acceso sin editar la identidad directamente.
Convertir claims en atributos, no en privilegios ciegos
Los tokens pueden incluir atributos como nombre, organización o grupos. Confiar ciegamente en un grupo externo para asignar permisos sensibles transfiere decisiones de negocio a un directorio que quizá no conoce el programa. Conviene separar atributos recibidos de roles efectivos y aplicar un mapeo aprobado. Un claim identifica contexto; la autorización final considera estado del partner, contrato, territorio y función.
El principio de menor privilegio exige defaults conservadores. Si un claim falta o cambia, el sistema no debe elevar acceso. Los mapeos se versionan y prueban con usuarios reales, grupos múltiples y organizaciones suspendidas. También se controla quién puede modificarlos. El diseño debe contemplar una ruta de acceso de emergencia para administradores, protegida y monitoreada, sin crear una puerta permanente débil.
Onboarding y offboarding coordinados
SSO mejora la experiencia, pero no garantiza baja automática. El IdP puede desactivar una cuenta; la plataforma debe decidir cuándo revoca sesiones, bloquea nuevas acciones y conserva historial. Si el programa recibe aprovisionamiento mediante un protocolo o feed, necesita reconciliación y manejo de eventos perdidos. Si no lo recibe, establece revisiones periódicas y responsables en cada organización.
Al salir una persona, sus transacciones y evidencia no se borran necesariamente; se separa identidad activa de registro histórico según política. Al salir un partner completo, se aplican reglas de offboarding de KA-097: accesos, saldos, responsabilidades y datos. La federación hace más rápida la señal, pero la operación comercial define sus consecuencias.
Sesiones, logout y recuperación
La autenticación ocurre en el IdP, pero la sesión local vive en la aplicación. Deben definirse duración, reautenticación para acciones sensibles, revocación y comportamiento ante logout. Cerrar sesión en una superficie no siempre cierra todas las sesiones del proveedor; prometer logout global sin soporte crea una falsa sensación de seguridad. La aplicación debe proteger tokens, validar nonce y state donde correspondan y limitar redirecciones.
La recuperación también cambia. Si el usuario perdió acceso corporativo, el programa no debería crear una contraseña paralela sin aprobación. Soporte necesita verificar organización y responsable, y registrar cualquier excepción. Para participantes pequeños sin IdP, puede coexistir autenticación local, pero sus políticas y capacidades deben quedar claras para no producir una experiencia arbitraria.
Modelo multi-tenant y elección de IdP
Una red puede tener un IdP central, uno por socio o ninguno en parte de la población. Aceptar múltiples emisores aumenta alcance y complejidad: discovery, claves, dominios, claims y soporte varían. Un broker de identidad puede normalizar, pero añade dependencia. Conectar cada socio directamente ofrece control específico, aunque eleva mantenimiento. La decisión debe considerar cantidad de organizaciones, madurez técnica y valor del acceso.
El aislamiento es obligatorio. Un usuario autenticado por el IdP de un partner no debe poder indicar otro tenant mediante un parámetro. El emisor, subject y vínculo aprobado determinan contexto. Las pruebas incluyen intentos de mezclar tokens, audiencias incorrectas, usuarios deshabilitados y cambios de dominio. La federación segura se demuestra en fronteras, no solo en un login exitoso.
Cómo evaluar y desplegar
El piloto debe incluir una organización representativa y casos de alta, usuario existente, cambio de rol, suspensión, salida y caída del IdP. Se miden tiempo de acceso, tickets, cuentas huérfanas y errores de mapeo. También se valida que los logs permitan correlacionar autenticación con acciones sin copiar tokens completos. La documentación asigna propietarios entre cliente, partner, proveedor de identidad y plataforma.
Lealto puede participar en experiencias B2B e integraciones, pero SSO debe confirmarse en el alcance técnico real. La decisión no puede derivarse solo de que exista una API. Una solución correcta reduce contraseñas duplicadas y acelera control, manteniendo en el programa la autoridad sobre elegibilidad, roles y datos.
Preguntas frecuentes
¿SSO reemplaza los roles del programa? No. SSO autentica; la plataforma todavía debe autorizar según reglas propias.
¿El correo es un identificador suficiente? Puede cambiar o reutilizarse. Es preferible una clave estable del sujeto combinada con el emisor.
¿Todos los partners deben tener IdP? No. Puede coexistir acceso local, siempre que las rutas tengan políticas y soporte definidos.
Privacidad y minimización de atributos federados
El proveedor de identidad puede ofrecer numerosos claims, pero el programa solo debería solicitar y conservar los necesarios. Nombre, identificador, organización y rol pueden bastar para un caso; fecha de nacimiento, teléfono o grupos internos pueden ser excesivos. Los scopes y mapeos deben corresponder a finalidad, y los tokens no se registran completos. La empresa documenta quién ve atributos y cuánto se retienen.
También debe distinguirse información autoritativa de información editable. Si la organización controla el nombre legal o rol, el usuario quizá no deba cambiarlo en el programa; preferencias y datos propios pueden seguir editables. Cuando un atributo cambia, se define si actualiza automáticamente o requiere revisión. Este gobierno evita que SSO se convierta en una importación indiscriminada del directorio corporativo y reduce impacto de errores o filtraciones.
Disponibilidad y ruta de contingencia
Depender de un IdP agrega una relación operacional. Si el proveedor del partner está caído, debe saberse si los usuarios conservan sesiones existentes, si se bloquean nuevos accesos y qué acciones críticas quedan disponibles. La contingencia no puede ser una contraseña compartida. Puede existir acceso de emergencia limitado para administradores internos, con aprobación, caducidad y alertas.
Los SLAs y contactos se acuerdan por organización. La telemetría separa errores del IdP, configuración del cliente, mapeo y aplicación. Así soporte deriva el caso correcto en lugar de pedir al usuario que reinicie indefinidamente. Las pruebas de continuidad incluyen claves rotadas, certificados vencidos y metadatos inaccesibles. La federación reduce fricción cotidiana solo cuando su dependencia también está gobernada.
Diseñar una federación que también sepa retirar acceso
Un piloto de federación debe cubrir alta, cambio de organización, pérdida de relación, expiración de sesión, indisponibilidad del IdP y recuperación asistida. También debe demostrar qué atributos recibe la plataforma, cuáles conserva y qué reglas convierten una identidad autenticada en permisos concretos. El éxito no es solamente entrar con un clic, sino retirar acceso a tiempo, auditar decisiones y mantener soporte cuando los sistemas no coinciden. Lealto y el proveedor de identidad deben evaluarse sobre responsabilidades y capacidades verificadas para el alcance acordado. La arquitectura más simple es la que mantiene separadas autenticación, pertenencia y autorización, incluso cuando para el usuario parezcan un solo acceso.
Fuentes
- IETF — OAuth 2.0 Authorization Framework, RFC 6749
- OpenID Foundation — OpenID Connect Core 1.0
- NIST SP 800-63C — Federation and Assertions
- Lealto — modelos B2B y capacidad de integración
Contáctenos
Construyamos su estrategia de lealtad