Tema 1
La autenticación, la autorización y la identidad no son funciones aisladas: juntas definen cómo un sistema reconoce sujetos, valida quiénes son, decide qué pueden hacer y deja trazabilidad de esas decisiones. Entender esta base es indispensable para diseñar aplicaciones, APIs y plataformas que controlen el acceso de forma segura y mantenible.
Cada vez que una persona inicia sesión, una aplicación consulta un token o una API evalúa si una operación está permitida, entran en juego conceptos de identidad y control de acceso. En muchos sistemas estos mecanismos se perciben como algo secundario, pero en realidad forman parte del núcleo de la seguridad y de la arquitectura del software.
Un sistema puede tener una interfaz excelente y lógica de negocio correcta, pero si no controla bien quién accede, cómo demuestra su identidad y qué acciones puede ejecutar, termina siendo inseguro. A la inversa, un sistema con controles de acceso mal diseñados también suele ser difícil de operar, integrar, auditar y escalar.
Por eso este curso no se limita a explicar cómo crear un formulario de login. El objetivo es entender el problema completo: identidades, credenciales, sesiones, permisos, políticas, federación, proveedores de identidad, protocolos y riesgos operativos.
Este curso estudia cómo representar identidades digitales, cómo autenticar sujetos, cómo autorizar acciones y cómo gobernar el acceso a recursos a lo largo del tiempo.
Nos enfocaremos en cuatro preguntas centrales:
La mayoría de los incidentes graves no requieren vulnerabilidades exóticas. Muchas veces empiezan con credenciales robadas, sesiones secuestradas, permisos excesivos o integraciones mal diseñadas entre aplicaciones. Eso convierte a la capa de identidad en un objetivo prioritario para atacantes y en un área crítica para arquitectos y desarrolladores.
Además, la identidad digital atraviesa toda la operación: empleados, clientes, administradores, microservicios, herramientas internas, paneles administrativos, entornos cloud, plataformas SaaS y APIs públicas o privadas. Si este plano de control está mal resuelto, el riesgo se expande al resto de los sistemas.
| Escenario | Problema de identidad o acceso | Consecuencia típica |
|---|---|---|
| Aplicación web corporativa | Permisos demasiado amplios o sesiones débiles | Acceso indebido a datos o funciones administrativas |
| API consumida por terceros | Tokens mal emitidos o scopes mal definidos | Abuso de endpoints y exposición de información |
| Entorno empresarial | Altas y bajas mal gestionadas | Usuarios con acceso residual tras cambiar de rol o salir |
| Infraestructura cloud | Claves y roles de servicio excesivos | Escalada de privilegios y compromisos de gran alcance |
| SSO entre aplicaciones | Confianza mal configurada o validaciones incompletas | Suplantación o aceptación de identidades no válidas |
La identidad digital es la representación de un sujeto dentro de un sistema. Ese sujeto puede ser humano o no humano. La identidad incluye atributos, relaciones, estado, historial y uno o más mecanismos para demostrar pertenencia.
No debe confundirse identidad con cuenta. Una identidad puede estar vinculada a varias cuentas, y una cuenta puede existir como una manifestación operativa de esa identidad en una aplicación concreta.
Por ejemplo, una persona puede tener una identidad organizacional con atributos como nombre, sector, cargo y ubicación. A partir de esa identidad pueden derivarse accesos a correo, ERP, VPN, CRM y paneles internos. El verdadero problema de seguridad no es cada cuenta por separado, sino la coherencia del conjunto.
Para entender control de acceso conviene separar tres piezas básicas:
Esta distinción parece simple, pero estructura todo el diseño posterior. Cuando un sistema madura, deja de pensar en términos de “usuario logueado” y empieza a pensar en términos de “qué sujeto intenta qué acción sobre qué recurso bajo qué condiciones”.
Autenticar es verificar que un sujeto es quien dice ser. No alcanza con que un identificador exista; el sistema necesita una prueba suficiente. Esa prueba puede basarse en algo que el sujeto sabe, posee, es, hace o en señales contextuales que aumentan o disminuyen la confianza.
En la práctica, la autenticación suele combinar varios elementos:
Un punto importante: autenticar no implica autorizar. Un usuario puede estar autenticado correctamente y aun así no tener derecho a ejecutar una acción concreta.
La autorización responde a la pregunta “¿qué puede hacer este sujeto autenticado?”. Esa decisión puede ser muy simple o extremadamente compleja según el dominio del sistema.
Algunos sistemas usan reglas directas, como “el rol administrador puede editar usuarios”. Otros evalúan políticas más ricas: departamento, geografía, sensibilidad del dato, horario, tipo de dispositivo, estado del recurso, relación entre sujetos o nivel de riesgo actual.
Durante el curso veremos distintos modelos de autorización, pero desde ahora conviene retener esta idea: una buena autorización no solo restringe acceso, también expresa reglas de negocio de forma clara, auditable y sostenible.
En muchos contextos aparece el conjunto AAA: Authentication, Authorization y Accounting. A eso hoy se suma el plano más amplio de identidad.
| Concepto | Pregunta que responde | Ejemplo |
|---|---|---|
| Identidad | ¿Cómo está representado el sujeto en el ecosistema? | Usuario con atributos, grupos, relaciones y ciclo de vida |
| Autenticación | ¿Es realmente quien dice ser? | Ingreso con contraseña y segundo factor |
| Autorización | ¿Qué puede hacer sobre un recurso? | Puede ver facturas pero no aprobar pagos |
| Accounting o trazabilidad | ¿Qué hizo, cuándo y bajo qué contexto? | Registro de acceso, cambios y eventos de seguridad |
Si falta cualquiera de estas piezas, el control de acceso queda incompleto. Sin identidad no hay base estable; sin autenticación no hay confianza; sin autorización no hay restricción; sin trazabilidad no hay auditoría ni capacidad de investigación.
Una credencial es un elemento que el sistema usa para verificar identidad. Puede ser una contraseña, una clave API, un token, un certificado, una clave privada o un secreto compartido. Pero no todas las credenciales ofrecen el mismo nivel de seguridad ni encajan igual en cada escenario.
En aplicaciones modernas aparece una diferencia importante entre:
Un sistema seguro no solo valida credenciales. También define cómo se emiten, almacenan, rotan, revocan y monitorean.
IAM significa Identity and Access Management. Es la disciplina y el conjunto de prácticas, procesos y tecnologías orientados a administrar identidades y controlar accesos de manera consistente.
Cuando una organización crece, ya no alcanza con tener usuarios dispersos en cada aplicación. Hace falta gobernanza: aprovisionar cuentas, asignar permisos según rol, revisar accesos, retirar privilegios al cambiar de puesto y dejar evidencia verificable de lo ocurrido.
IAM conecta dimensiones técnicas y organizativas:
La teoría se vuelve más clara cuando se la vincula con situaciones reales. Algunos escenarios frecuentes son los siguientes:
Todos estos casos comparten principios, pero cambian mucho en protocolos, amenazas y requisitos de implementación.
Los sistemas de identidad son atacados de forma constante porque permiten acceso directo o facilitan escalada. Algunos riesgos típicos son:
Aunque las implementaciones varían, muchas arquitecturas de identidad incluyen componentes similares.
| Componente | Función principal | Ejemplo de responsabilidad |
|---|---|---|
| Directorio o repositorio de identidad | Guardar identidades, atributos y grupos | Usuarios, áreas, estados, relaciones y metadatos |
| Proveedor de identidad | Autenticar y emitir afirmaciones sobre el sujeto | Login centralizado y SSO |
| Servidor de autorización | Emitir tokens y aplicar políticas de acceso delegadas | OAuth 2.0 y OpenID Connect |
| Aplicación o recurso protegido | Consumir identidad y aplicar autorización local | Panel web, API, servicio de negocio |
| Sistema de auditoría | Registrar eventos y decisiones críticas | Logs de acceso, cambios de rol y revocaciones |
En cursos introductorios suele parecer que “el login” sucede dentro de la aplicación y termina ahí. En la práctica, muchas veces intervienen varios sistemas coordinados con responsabilidades separadas.
En una aplicación pequeña, identidad y acceso pueden resolverse con una base de usuarios, contraseñas almacenadas de forma segura y algunas reglas de permisos. Pero al crecer el ecosistema aparecen nuevas exigencias:
Ese cambio de escala explica por qué este curso incluye IAM, SSO, federación y protocolos estándar. No son complejidades “opcionales”; son respuestas a problemas reales de ecosistemas distribuidos.
Antes de profundizar en herramientas concretas conviene fijar algunos principios que se repetirán durante todo el curso.
La seguridad real aparece cuando estos principios se convierten en decisiones de diseño concretas, no cuando quedan escritos como declaraciones generales.
Estos problemas no solo debilitan la seguridad. También encarecen el mantenimiento, dificultan auditorías y vuelven frágiles las integraciones futuras.
Este tema sirve como mapa general. En los próximos temas iremos descomponiendo cada parte del problema.
La autenticación, la autorización y la identidad constituyen el plano de confianza de un sistema. Allí se define quién entra, cómo lo hace, qué puede alcanzar y qué evidencia queda de ese acceso. Cuando este plano está bien diseñado, la seguridad mejora, pero también mejora la operación, la integración entre sistemas y la gobernanza del negocio.
En el próximo tema profundizaremos en la identidad digital propiamente dicha: qué representa, cómo se modela y por qué usuarios, cuentas, atributos y credenciales no son la misma cosa.