---
term: 'IAM (Gestión de Identidad y Acceso)'
seoTitle: 'IAM (Gestión de Identidad y Acceso): pilares, estándares, ciclo de vida'
headline: '¿Qué es IAM (Gestión de Identidad y Acceso)?'
slug: iam
category: auth-security
shortDefinition: '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.'
relatedTerms:
  - role-based-access-control-rbac
  - oauth-2-social-login
  - multi-factor-authentication-mfa
  - json-web-token-jwt
contrastsWith:
  - role-based-access-control-rbac
aboutTerms:
  - 'Proveedor de Identidad (IdP)'
  - 'Single Sign-On (SSO)'
  - 'Ciclo de Vida de la Identidad'
  - 'CIAM'
faq:
  - question: '¿Qué es IAM en términos simples?'
    answer: 'La disciplina de gestionar quién puede acceder a qué: probar que los usuarios son quienes dicen ser (autenticación), decidir qué pueden hacer (autorización), administrar las cuentas de la creación a la eliminación (ciclo de vida) y llevar registro de todo (auditoría). Responde "¿quién eres?" y "¿qué tienes permitido hacer?" para cada solicitud.'
  - question: '¿Cuál es la diferencia entre autenticación y autorización?'
    answer: 'La autenticación verifica quién eres — credenciales, códigos, biometría. La autorización decide qué puedes hacer — roles, permisos, políticas. En versión aeropuerto: el control de pasaportes versus el pase de abordar. La autenticación siempre corre primero; la autorización corre en cada acción posterior.'
  - question: '¿Cuáles son los componentes de un sistema IAM?'
    answer: 'Un repositorio de identidades (el directorio de usuarios), servicios de autenticación (contraseñas, MFA, single sign-on), la maquinaria de autorización (roles, permisos, ACLs), herramientas de ciclo de vida (aprovisionamiento y desaprovisionamiento) y logging de auditoría. Todo sistema real tiene los cinco, ya sea armados a mano o heredados de una plataforma.'
  - question: '¿Qué es un proveedor de identidad (IdP)?'
    answer: 'El sistema dueño de las identidades y que responde por ellas: autentica al usuario y emite tokens o aserciones firmadas — vía OpenID Connect o SAML — en las que otras aplicaciones confían. Cada botón de "Iniciar sesión con…" es un IdP en acción; las empresas operan el propio para el single sign-on de su fuerza laboral.'
  - question: '¿Qué es el single sign-on (SSO)?'
    answer: 'Autentícate una vez con el proveedor de identidad y accede a muchas aplicaciones sin nuevos logins — cada app confía en la aserción del IdP en lugar de guardar sus propias credenciales. Menos contraseñas, un solo lugar para imponer MFA, un solo interruptor para cortar el acceso en todas partes.'
  - question: '¿Qué es el aprovisionamiento y el desaprovisionamiento?'
    answer: 'Los verbos del ciclo de vida: el aprovisionamiento crea la cuenta y concede los derechos cuando alguien entra o cambia de rol; el desaprovisionamiento los revoca a la salida. Automatizado vía estándares como SCIM. Un desaprovisionamiento fallido deja cuentas huérfanas — perennemente uno de los principales hallazgos de auditoría y un punto de apoyo favorito de los atacantes.'
  - question: '¿Cuál es la diferencia entre IAM corporativo (workforce) y CIAM?'
    answer: 'Audiencia y prioridades. El IAM de fuerza laboral gestiona empleados — miles de usuarios, controles impuestos por TI, mínimo privilegio y compliance primero. El IAM de clientes (CIAM) gestiona a los usuarios de tu app — potencialmente millones, registro self-service, login social, donde mandan la UX, la conversión y el consentimiento de privacidad. La mayoría de los desarrolladores de apps está construyendo CIAM, use la palabra o no.'
  - question: '¿Cómo se relaciona IAM con zero trust?'
    answer: 'Zero trust — nunca confíes, siempre verifica — sustituye el perímetro de red por la identidad: cada solicitud se autentica y autoriza sin importar de dónde venga. IAM es la maquinaria que lo hace posible — por eso "la identidad es el nuevo perímetro" se volvió el lema de la disciplina.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'NIST SP 800-63-4 — Digital Identity Guidelines'
    url: 'https://pages.nist.gov/800-63-4/'
  - name: 'NIST Identity & Access Management program'
    url: 'https://www.nist.gov/identity-access-management'
  - name: 'OpenID Connect Core 1.0'
    url: 'https://openid.net/specs/openid-connect-core-1_0.html'
  - name: 'RFC 7644 — SCIM Protocol'
    url: 'https://datatracker.ietf.org/doc/html/rfc7644'
  - name: 'Identity and access management — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Identity_and_access_management'
cta:
  title: 'IAM a nivel de app, preensamblado'
  text: 'Back4app entrega los primitivos de IAM que tu app necesita desde el primer día — repositorio de usuarios, sesiones, roles, ACLs, verificación de email, login social, MFA — aplicados por la plataforma en cada solicitud.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-04'
translationKey: identity-access-management-iam
---

**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

| Pregunta | Respuesta |
| --- | --- |
| Los cuatro pilares | Autenticación · autorización · ciclo de vida · auditoría |
| El lema | Personas correctas, acceso correcto, recursos correctos, momento correcto |
| Los dos mundos | IAM de fuerza laboral (empleados, compliance) · CIAM (los usuarios de tu app, UX) |
| Los estándares | OIDC y OAuth para tokens · SAML para SSO corporativo · SCIM para ciclo de vida · WebAuthn para credenciales |
| La versión del desarrollador | Repositorio de usuarios + sesiones + roles + ACLs + recuperación — constrúyelo o herédalo |

## 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:

```text
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:**

```javascript
// 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: 'ada@example.com' });

// 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
// 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, 'ada@example.com');
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)
```

**Swift:**

```swift
// 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 = "ada@example.com"
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)
```

**Kotlin:**

```kotlin
// 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 = "ada@example.com"
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:

| | Autenticación (AuthN) | Autorización (AuthZ) |
| --- | --- | --- |
| Pregunta | ¿Quién eres? | ¿Qué puedes hacer? |
| Evidencia | Credenciales, códigos de [MFA](/glossary/es/autenticacion-multifactor-mfa/), biometría, passkeys | Roles, permisos, [ACLs](/glossary/es/listas-de-control-de-acceso-acl/), políticas |
| Ocurre | Una vez por sesión | En cada acción |
| Produce | Una sesión o un [token](/glossary/es/json-web-token-jwt/) | Un permitir/denegar por solicitud |
| Falla como | Robo de cuenta | Escalada de privilegios, exposición de datos |

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.

```mermaid
flowchart LR
  accTitle: Flujo de solicitud de IAM a través de los cuatro pilares
  accDescr: Un usuario se autentica contra el repositorio de identidades y recibe una sesión. Cada solicitud se autoriza luego contra roles y permisos antes de llegar a los recursos, mientras la gestión del ciclo de vida gobierna la existencia de la cuenta y el logging de auditoría registra los eventos de autenticación y autorización.
  U["Usuario"] -->|"credenciales + MFA"| AN["Autenticación<br/>repositorio de identidades · IdP"]
  AN -->|"sesión / token"| AZ["Autorización<br/>roles · permisos · ACLs"]
  AZ --> R[("Recursos")]
  L["Ciclo de vida<br/>entrar · cambiar · salir"] -.->|"gobierna las cuentas"| AN
  AN -.-> AU["Auditoría<br/>quién hizo qué, cuándo"]
  AZ -.-> AU
```

## 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](/glossary/es/control-de-acceso-rbac/), 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:

| Estándar | Qué hace | Dónde lo encuentras |
| --- | --- | --- |
| [OAuth 2.0](/glossary/es/oauth-2-login-social/) | Autorización delegada — tokens con alcance en vez de contraseñas compartidas | Acceso a APIs, la plomería bajo el login social |
| OpenID Connect | Autenticación sobre OAuth — ID tokens firmados atestiguan quién inició sesión | Cada botón de "Iniciar sesión con…", el SSO moderno |
| SAML 2.0 | Aserciones de federación en XML — el hermano mayor corporativo de OIDC | Integraciones de SSO corporativo |
| SCIM | API estándar para aprovisionar/desaprovisionar cuentas | Automatización del ciclo de vida laboral |
| WebAuthn / FIDO2 | Credenciales de clave pública resistentes al phishing | Passkeys, llaves de seguridad de hardware |
| [JWT](/glossary/es/json-web-token-jwt/) | El formato de token en el que viajan las aserciones | ID tokens, access tokens |
| LDAP | Protocolo de consulta de directorios | Repositorios de identidad legados |

## Workforce IAM vs. CIAM

| | IAM de fuerza laboral | IAM de clientes (CIAM) |
| --- | --- | --- |
| Usuarios | Empleados, contratistas — miles | Los usuarios de tu app — hasta millones |
| Onboarding | TI te aprovisiona | Registro self-service — la fricción mata la conversión |
| Autenticación | SSO corporativo, MFA obligatoria | Login social, passwordless, MFA opcional |
| Prioridades | Mínimo privilegio, compliance | UX, conversión, consentimiento de privacidad |
| Ciclo de vida | Entrar/cambiar/salir guiado por RR. HH. | Registrarse/usar/abandonar/eliminar guiado por el usuario |
| Comprador | TI y seguridad | El equipo de producto — muchas veces se *construye*, no se compra |

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

| Situación | Inclínate por |
| --- | --- |
| Auth a nivel de app para un producto | Heredar de un BaaS — del repositorio de usuarios a la MFA, preconstruido |
| SSO de fuerza laboral entre herramientas SaaS | Comprar un servicio de IdP |
| Control total, autoalojado, protocolos estándar | IdP open-source (Keycloak, Ory) |
| Una app, necesidades simples, sesiones del framework | Construir lo mínimo — pero planea recuperación y auditoría |
| Verificación de identidad regulada | Comprar — los niveles de garantía son trabajo de certificación |
| Hacer tu propio almacenamiento de contraseñas "por ahora" | No lo hagas — esta es la única rueda que no se reinventa |

## 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](/glossary/es/oauth-2-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](/glossary/es/control-de-acceso-rbac/) y las [ACLs](/glossary/es/listas-de-control-de-acceso-acl/) 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.