Bienvenido a Platzi

1️⃣ Análisis del concepto

La definición mezcla dos cosas relacionadas pero distintas, lo cual es muy común (y válido didácticamente), pero conviene separarlas:

✔️ Correcto

• La autenticación verifica identidades.
• Las credenciales no siempre son usuario/contraseña.
• Aplica tanto a usuarios como a aplicaciones.
• Azure Active Directory (hoy Microsoft Entra ID) actúa como proveedor de identidad.
• El objetivo es seguridad y control de acceso.

⚠️ Ajuste conceptual importante

En server-to-server:

• No hay usuario humano
• Se autentica una aplicación / servicio
• No se usan contraseñas humanas, sino:
  • Client ID
  • Client Secret
  • Certificados
  • Tokens (OAuth 2.0)

📌 Lo correcto es hablar de autenticación de aplicaciones o service principal authentication.

2️⃣ Versión refinada del concepto (nivel corporativo)

La autenticación es el proceso de verificación de identidad de un usuario o de una aplicación que intenta acceder a un recurso protegido. En escenarios server-to-server, la autenticación no involucra usuarios humanos, sino identidades de aplicación, las cuales se validan mediante mecanismos seguros como tokens OAuth 2.0, certificados o secretos administrados por proveedores de identidad como Microsoft Entra ID (Azure AD). Este enfoque permite una comunicación segura, automatizada y controlada entre servicios, cumpliendo principios de seguridad empresarial como el mínimo privilegio.

3️⃣ ¿Qué es un escenario server-to-server?

👉 Un servicio backend llamando a otro servicio backend, sin intervención humana.

Ejemplos:

• API → API
• Microservicio → Base de datos
• Job automático → Servicio cloud

4️⃣ Ejemplo claro de Server-to-Server con Azure Entra ID

🎯 Escenario

Un backend Node.js necesita acceder a una API protegida en Azure para leer datos corporativos.

🧱 Componentes

• App A: Servicio backend (cliente)
• App B: API protegida (recurso)
• Microsoft Entra ID: Proveedor de identidad
• RBAC / Scopes: Control de acceso

🔐 Flujo de autenticación (Client Credentials Flow)

1️⃣ App A se registra en Entra ID 2️⃣ Se le asigna:

• Client ID
• Client Secret
  (o certificado)

3️⃣ App A solicita un access token a Entra ID:

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

4️⃣ Entra ID valida la identidad de la aplicación 5️⃣ Devuelve un JWT Access Token 6️⃣ App A llama a App B enviando el token:

Authorization: Bearer eyJ0eXAiOiJKV1Qi...

7️⃣ App B valida el token y permite el acceso

5️⃣ Qué se autentica realmente (clave conceptual)

EscenarioQuién se autentica

Usuario web

Persona

Login corporativo

Usuario

Server-to-Server

Aplicación

Microservicios

Identidad de servicio

📌 No se autentica el servidor físico, se autentica la identidad lógica del servicio.

6️⃣ Seguridad aplicada (principio de mínimo privilegio)

En Entra ID:

• A la App A solo se le da permiso para:
  • read:data
• No:
  • write
  • admin
  • delete

✔️ Cumple Least Privilege