¿Qué es IAM (Gestión de Identidad y Acceso)?

IAM es un framework de políticas y tecnologías que asegura a los usuarios correctos el acceso correcto a los recursos correctos, en el momento correcto. La Gestión de Identidad y Acceso es la disciplina detrás de toda caja de login y toda verificación de permisos — y una desambiguación de entrada: los grandes proveedores de nube también venden productos llamados “IAM” para controlar el acceso a su propia infraestructura; esos son implementaciones de la disciplina, no su definición. Este artículo cubre la disciplina — incluida la versión que todo desarrollador de apps construye o hereda, casi siempre sin llamarla IAM.

Puntos clave

El ciclo de vida de la identidad: entrar, cambiar, salir

El trabajo diario de IAM es un ciclo que toda cuenta recorre, y se traduce en operaciones concretas:

ENTRAR   crear la identidad → verificar el email → emitir credenciales/sesión
         (aprovisionamiento — automatizado vía SCIM en sistemas corporativos)
CAMBIAR  cambios de rol · cambios de equipo · concesiones y revocaciones
         (la autorización sigue a los roles: un cambio es una actualización de datos)
SALIR    revocar sesiones YA → desactivar la cuenta → eliminar o anonimizar
         (desaprovisionamiento — los pasos omitidos se vuelven "cuentas huérfanas",
          el hallazgo de auditoría que insiste en aparecer en los reportes de brechas)

El mismo ciclo como llamadas a la API:

// JavaScript / Node.js — Back4app JS SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret, email: '[email protected]' });

// Move: authorization follows roles, not people
editors.getUsers().add(user);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// Flutter / Dart — Back4app Flutter SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
final user = ParseUser('ada', secret, '[email protected]');
await user.signUp();

// Move: authorization follows roles, not people
editors.addRelation('users', [user]);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// iOS / Swift — Back4app Swift SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
var user = User()
user.username = "ada"
user.password = secret
user.email = "[email protected]"
let signedUp = try await user.signup()

// Move: authorization follows roles, not people
try await editors.users.add([signedUp]).save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// Android / Kotlin — Back4app Android SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.email = "[email protected]"
user.signUp()

// Move: authorization follows roles, not people
editors.users.add(user)
editors.save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

Autenticación vs. autorización

La distinción sobre la que se apoya la disciplina entera:

La versión aeropuerto, una sola vez: el control de pasaportes versus el pase de abordar. Después la versión de ingeniería, que importa más: la autenticación produce la identidad que una sesión lleva; la autorización la consume en cada solicitud posterior — por eso las dos fallan de formas distintas y se endurecen por separado.

Los cuatro pilares — y las tres letras del mercado

La anatomía funcional: autenticación (probar la identidad — contraseñas, MFA, SSO, passwordless), autorización (decidir acciones — roles, permisos, reglas por objeto), ciclo de vida (el bucle entrar/cambiar/salir) y auditoría (el cuarto pilar crónicamente subestimado: logs, revisiones de acceso y la capacidad de responder “¿quién podía leer esto, y quién lo leyó?”). El mercado de proveedores rebana el mismo territorio en segmentos que encontrarás en cualquier compra corporativa: AM (access management — login, SSO, MFA), IGA (gobernanza — certificaciones, segregación de funciones, la capa del “¿deberían tener esto?” encima del operativo “¿pueden?”) y PAM (acceso privilegiado — bóvedas y elevación just-in-time para las cuentas cuyo compromiso es fin del juego). La misma disciplina, dos mapas.

El stack de estándares

La sopa de letras, resuelta en funciones — la tabla que las páginas del ranking nunca ofrecen:

Workforce IAM vs. CIAM

La distinción se gana su tabla porque el contenido del ranking está casi todo escrito sobre la columna izquierda, mientras que la mayoría de los desarrolladores que leen un glosario está construyendo la derecha: los flujos de registro, la gestión de sesiones y la recuperación de cuentas para los usuarios de una app son CIAM — la disciplina aplica aunque nadie en la sala use la sigla.

Casos de uso comunes

• Gestión de usuarios de la app — registro, verificación, sesiones, roles, eliminación: CIAM como trabajo cotidiano de backend.
• SSO corporativo — un IdP, muchas apps; MFA y offboarding impuestos en un único punto.
• Identidad de APIs y servicios — credenciales de máquina, tokens con alcance y rotación para llamadores no humanos.
• Programas de compliance — revisiones de acceso, huellas de auditoría y evidencia de mínimo privilegio para GDPR, HIPAA, SOC 2.
• Arquitecturas zero trust — verificaciones de identidad por solicitud que sustituyen la ubicación en la red como señal de confianza.

¿Deberías construir o comprar tu IAM? Matriz de decisión

Limitaciones y trade-offs

• IAM es un proceso vestido de software. Las herramientas automatizan la política; no pueden inventarla — el diseño de roles, la cadencia de revisión y la disciplina de offboarding siguen siendo trabajo humano.
• Centralizar concentra el riesgo. Un IdP significa un solo lugar que proteger y una sola caída que desconecta a todos; la planificación de disponibilidad y recuperación viene con la conveniencia.
• La federación hereda confianza. Toda app que confía en un IdP hereda sus compromisos; la validación de tokens y los tiempos de vida cortos son la contención.
• La automatización del ciclo de vida necesita verdad. El aprovisionamiento es tan bueno como la fuente de registro que lo alimenta; datos de RR. HH. desactualizados se vuelven accesos desactualizados.
• La auditoría sin revisión es teatro. Logs que nadie lee y certificaciones sobre las que nadie actúa satisfacen checklists, no a los atacantes.

IAM en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La vista de IAM con ojos de desarrollador es exactamente lo que entrega: la clase User es el repositorio de identidades; el registro, la verificación de email, el restablecimiento de contraseña y el login social cubren la autenticación (con un adaptador de MFA para step-up); los tokens de sesión revocables llevan la identidad; los roles y las ACLs por objeto son el pilar de la autorización, aplicados en cada solicitud REST, GraphQL y Live Query; y el ciclo de vida de las pestañas de código — entrar, cambiar, salir — es trabajo ordinario de datos, con los triggers de Cloud Code como el lugar para imponer política (bloquear emails desechables, registrar eventos de auditoría, desaprovisionar en cascada). Es CIAM como capa de plataforma: los pilares llegan ensamblados, y tu trabajo pasa de construir la maquinaria de identidad a decidir la política.