Guía de registro de aplicaciones y OAuth para una integración segura de aplicaciones

By Mirko Peters · 2026-05-04

Registra tu aplicación con OAuth 2.0. Comprende el flujo de código de autorización para un acceso seguro, una parte clave de la concesión de código de autorización de OAuth 2.0.

Automatically translated with AI from the original post. Read the English original

Seamos sinceros: acertar con la autenticación y el registro de aplicaciones no consiste solo en seguir protocolos ingeniosos; se trata de asegurar que tus usuarios, tus datos y tu organización estén protegidos. Esta guía desmitifica el registro de aplicaciones y OAuth 2.0, para que puedas crear una autenticación segura y basada en estándares con Microsoft Entra ID (antes Azure AD) o con el proveedor que elijas.

Desglosaremos los pasos y conceptos que necesitas, desde entender el porqué de OAuth hasta ponerte manos a la obra para que funcione en aplicaciones web, móviles o SaaS. Por el camino encontrarás definiciones claras, consejos prácticos y una hoja de ruta pensada para mantener tu integración encarrilada y evitar los errores habituales que cometen los desarrolladores que se inician en OAuth. Tanto si lo exploras por primera vez como si ajustas una configuración empresarial avanzada, estás en el lugar adecuado para construir con confianza y entender los identificadores que necesita tu aplicación.

Guía de registro de aplicaciones y OAuth: definición

El registro de aplicaciones es el proceso de crear y configurar una identidad de aplicación en un proveedor de identidades (como Azure AD, Google o Auth0) para que la aplicación pueda solicitar autenticación y autorización de forma segura. Normalmente implica asignar un identificador de cliente (client ID), un secreto de cliente o un certificado, definir los URI de redirección, establecer los permisos o ámbitos (scopes) y configurar los tipos de concesión permitidos.

8 datos sorprendentes sobre la guía de registro de aplicaciones y OAuth

• Los secretos de cliente pueden filtrarse a través de los registros: Muchos desarrolladores registran sin darse cuenta los client ID y los secretos durante la depuración, lo que deja expuestas las credenciales del registro de aplicaciones si no se endurecen las directivas de registro; trata siempre los identificadores con cuidado.
• Los URI de redirección son más estrictos de lo que esperas: Los proveedores de OAuth suelen exigir URI de redirección que coincidan exactamente (incluidas las barras finales y el esquema), de modo que diferencias sutiles pueden romper flujos que parecen configurados correctamente en el registro de tu aplicación.
• Los clientes públicos no requieren secretos, pero aun así necesitan protección: Las aplicaciones nativas y las de una sola página se tratan como clientes públicos sin secretos de cliente, pero deben usar PKCE y enfoques seguros de redirección para evitar la interceptación del código.
• Los ámbitos no garantizan por defecto el mínimo privilegio: Al registrar aplicaciones, los ámbitos predeterminados o las pantallas de consentimiento pueden solicitar permisos amplios; para imponer el mínimo privilegio son esenciales las restricciones explícitas de ámbitos y el consentimiento incremental.
• La revocación de tokens no está soportada de forma universal: No todos los proveedores de identidades respetan la revocación de tokens ni ofrecen cierre de sesión inmediato entre sesiones, así que el registro de aplicaciones debe incluir la gestión de sesiones y las directivas de tokens de actualización.
• Los metadatos del registro de aplicaciones son una superficie de ataque: Los nombres, logotipos y URI de redirección de las aplicaciones expuestos públicamente pueden ayudar a los atacantes a diseñar ataques de phishing convincentes o de redirección abierta si no se gestionan con cuidado.
• La automatización del aprovisionamiento puede configurar mal los permisos: La automatización de CI/CD que crea registros de aplicaciones suele conceder permisos de API demasiado permisivos o no registra los URI de redirección necesarios, lo que provoca fallos silenciosos o exposición de seguridad.
• La experiencia de consentimiento afecta a las decisiones de seguridad: Usuarios y administradores suelen conceder un consentimiento amplio porque los cuadros de diálogo de consentimiento resultan confusos; diseñar avisos de consentimiento claros y mínimos en el registro de aplicaciones y en la guía de OAuth reduce la concesión excesiva de acceso.

Comprender OAuth 2.0 y los fundamentos de Entra ID

OAuth 2.0 es la base de los flujos de autenticación modernos: permite que las aplicaciones accedan de forma segura a los datos y recursos del usuario sin llegar a ver nunca una contraseña. Aquí tienes una visión general del proceso de OAuth. En esencia, OAuth 2.0 define cómo trabajan juntos un usuario (el "propietario del recurso"), una aplicación (el "cliente") y un proveedor de identidades (el "servidor de autorización"), de modo que los usuarios mantengan el control de su información.

Pero ¿qué ocurre cuando quieres autenticar usuarios y no solo autorizar el acceso a datos? Ahí entra OpenID Connect, que añade una capa de identidad e inicio de sesión seguros sobre OAuth 2.0. Con OpenID Connect, proveedores como Microsoft Entra ID y Google permiten a tus aplicaciones verificar quiénes son los usuarios y solicitar permisos con ámbito limitado para recursos adicionales, todo en una experiencia unificada.

Si oyes términos como "ID de cliente", "punto de conexión de autorización" o "token de acceso", no te abrumes. Todos se reducen a definir quién se comunica con quién y qué puede hacer. Microsoft Entra ID, en particular, utiliza estos protocolos para ofrecer a los desarrolladores una base basada en estándares, adecuada desde aplicaciones empresariales de un solo inquilino hasta productos SaaS masivos y multiinquilino.

Entender estos fundamentos significa que construyes sobre terreno probado. Elegir el flujo de OAuth adecuado para tu escenario (por ejemplo, el flujo de código para aplicaciones web o el flujo de dispositivo para smart TV) garantiza un inicio de sesión seguro y sencillo en el que los usuarios puedan confiar y que tu equipo de cumplimiento normativo agradecerá.

Registro de aplicaciones & guía de OAuth: errores comunes con OAuth 2.0 y Entra ID

Esta guía de registro de aplicaciones & OAuth recoge los errores frecuentes que cometen los equipos al implementar OAuth 2.0 con Microsoft Entra ID (Azure AD) y explica cómo afectan a la seguridad, la funcionalidad y la experiencia de usuario.

• Mezclar conceptos de OAuth 2.0 con los de OpenID Connect (por ejemplo, esperar tokens de ID donde solo se emiten tokens de acceso).
• Usar los flujos de OAuth de forma incorrecta, como tratar el flujo implícito como válido para aplicaciones modernas en lugar de Authorization Code con PKCE.

• Registrar los URI de redirección de forma incorrecta (esquema equivocado, barra final o uso de localhost en producción).
• Usar la configuración de cliente público en aplicaciones confidenciales o viceversa, lo que provoca errores de token o expone secretos.
• No definir los permisos o ámbitos de API correctos, u olvidar conceder el consentimiento de administrador cuando sea necesario.

• Incrustar secretos de cliente en código del lado del cliente o en repositorios públicos.
• No rotar periódicamente los secretos o certificados, o no eliminar las credenciales caducadas del registro de la aplicación.
• Usar secretos de larga duración sin necesidad, en lugar de certificados de corta duración o identidades administradas.

• No validar correctamente los tokens (emisor, audiencia, firma, nonce, exp).
• Almacenar los tokens de acceso o de actualización de forma insegura (por ejemplo, en el almacenamiento local del navegador sin protección).
• Confiar en el contenido de los tokens sin verificar los ámbitos o roles devueltos por Entra ID.

• Asumir que el consentimiento del usuario equivale al permiso de la aplicación, sin darse cuenta de que algunos permisos requieren consentimiento de administrador.
• Solicitar permisos o ámbitos excesivos, lo que aumenta el riesgo innecesario y la tasa de rechazo durante el consentimiento.

• No gestionar la rotación y la revocación de tokens de actualización según las directivas de Entra ID, lo que provoca cierres de sesión inesperados.
• Usar tokens de actualización en clientes públicos sin las protecciones adecuadas (utiliza PKCE y duraciones de token apropiadas).

• No configurar correctamente los ajustes multiinquilino en aplicaciones pensadas para funcionar entre inquilinos.
• Usar los puntos de conexión incorrectos (específicos del inquilino frente a common) y encontrarse con problemas de inicio de sesión o de consentimiento.

• No probar el comportamiento de la aplicación cuando se aplican Conditional Access, MFA o directivas de cumplimiento de dispositivos.
• Asumir que los tokens siempre se emitirán en las mismas condiciones: las directivas pueden bloquearlos o exigir pasos de autenticación adicionales.

• Seguir flujos de OAuth heredados o patrones de Azure AD v1 en lugar de las recomendaciones de la plataforma de identidad de Microsoft (v2).
• Usar ejemplos de la comunidad sin verificar que implementen prácticas seguras (PKCE, almacenamiento seguro, validación adecuada).

• No registrar los errores de autenticación ni los errores de emisión de tokens, lo que dificulta el diagnóstico.
• Mostrar a los usuarios mensajes de error sin procesar en lugar de traducirlos a indicaciones claras y accionables.

Usa esta guía de registro de aplicaciones y OAuth para revisar tu implementación, seguir las prácticas recomendadas de la plataforma de identidad de Microsoft y reducir los riesgos de seguridad y operativos al integrar OAuth 2.0 con Entra ID.

Requisitos previos del registro de aplicaciones para la configuración de OAuth

Antes de empezar con las pantallas de registro y de copiar el nombre de tu aplicación en un portal, revisa algunos requisitos imprescindibles. En primer lugar, necesitas acceso al centro de administración de Microsoft Entra de tu organización o a la consola correspondiente del proveedor de identidades que utilices, sin atajos. Sin los permisos adecuados, te encontrarás con un muro antes incluso de entrar.

A continuación, decide qué tipo de aplicación vas a crear y qué identificadores serán necesarios para su funcionamiento. ¿Es una aplicación web, una aplicación de una sola página, una aplicación móvil o quizá un servicio automatizado? Cada tipo tiene sus propios requisitos en cuanto a autenticación y autorización. Definir esto desde el principio condiciona la configuración de seguridad que elegirás más adelante.

También es importante determinar quién va a usar tu aplicación. ¿Solo la usarán personas de tu propia organización (inquilino único)? ¿O debe atender a usuarios de otras empresas o del público en general (multiinquilino)? Esto afecta a la configuración del registro, a qué directorios de usuarios se aplican y al flujo de consentimiento que verán tus usuarios.

Por último, reúne los detalles técnicos, como las URL permitidas para las redirecciones de inicio de sesión, las plataformas que vas a admitir (¿iOS, Android, Windows?) y los permisos (o «ámbitos») que tu aplicación necesitará solicitar. Tener estos datos definidos desde el principio ahorra mucho tiempo durante la configuración y evita problemas habituales, como URI no válidos o tipos de cuenta que no coinciden más adelante.

Cómo registrar tu aplicación en Microsoft Entra ID

Registrar tu aplicación en Microsoft Entra ID (antes Azure AD) sienta las bases para toda la autenticación y el acceso a las API. El proceso empieza en el centro de administración de Entra, donde crearás un nuevo registro de aplicación, que asigna a tu aplicación una identidad única (llamada «id. de cliente») dentro del directorio de tu organización.

Introduce un nombre para tu aplicación y, a continuación, selecciona quién puede usarla: solo tu organización, varias organizaciones o cualquier cuenta de Microsoft. Este paso es fundamental, sobre todo en aplicaciones SaaS y B2B, porque determina el alcance de la aplicación y cómo se gestiona el consentimiento del inquilino.

Tras elegir la audiencia, configura los detalles de la plataforma. En las aplicaciones web, añadirás un URI de redirección; en las aplicaciones móviles o de una sola página, la configuración específica de cada plataforma garantiza inicios de sesión fluidos. El portal de Entra te guía para añadir credenciales, como secretos de cliente o certificados, que tu aplicación usará para demostrar su identidad.

Completar el registro alinea tu aplicación con los estándares de OAuth 2.0 y garantiza que el flujo de autenticación siga siendo seguro y cumpla la normativa. Tanto si optas por un inquilino único como por un enfoque multiinquilino, entender estos ajustes desde el principio sienta una base sólida para la escalabilidad y las necesidades de integración futuras.

Ventajas clave de registrar tu aplicación en Microsoft Entra ID

• Gestión centralizada de identidades: administra la autenticación, la autorización y las identidades de usuario de tu aplicación desde un único inquilino de Entra ID.
• Flujos OAuth seguros: aprovecha el soporte integrado de OAuth 2.0 y OpenID Connect para implementar inicios de sesión seguros, emisión de tokens y acceso delegado.
• Inicio de sesión único (SSO): ofrece un SSO sin fisuras en Microsoft 365, Azure y otros servicios integrados para mejorar la experiencia de usuario y reducir las solicitudes de contraseña.
• Control detallado de permisos: define y gestiona permisos de API de grano fino, experiencias de consentimiento y acceso con privilegios mínimos, tanto para permisos delegados como de aplicación.
• Acceso condicional y directivas de seguridad: aplica MFA, cumplimiento de dispositivos, ubicación y directivas basadas en riesgo para proteger el acceso a las aplicaciones y los datos sensibles.
• Gestión de secretos y credenciales de aplicaciones: almacena y rota de forma segura los secretos de cliente, los certificados y la configuración multiinquilino, aplicando prácticas de gestión del ciclo de vida para mantener la integridad de los usos de la aplicación.
• Integración con los servicios de la plataforma de Microsoft: accede a Microsoft Graph, a las API de Azure, a Teams y a otras capacidades de la plataforma mediante tokens estandarizados y modelos de consentimiento.
• Compatibilidad con aplicaciones híbridas y multiplataforma: autentica a los usuarios en escenarios web, móviles, de escritorio y de servicio a servicio con protocolos de identidad coherentes, asegurándote de que cada aplicación utiliza los identificadores adecuados.
• Supervisión y auditoría: utiliza registros, informes de inicio de sesión e información de seguridad para detectar anomalías, investigar incidentes y mantener el cumplimiento.
• Escalabilidad y preparación para empresas: aprovecha la infraestructura global de Entra ID, las opciones multiinquilino y las funciones empresariales para dar soporte a bases de usuarios en crecimiento y necesidades organizativas complejas.
• Herramientas para desarrolladores y documentación: aprovecha los SDK, el código de ejemplo y la guía de registro de aplicaciones y OAuth para acelerar la implementación y resolver los escenarios habituales.

Configuración de URI de redirección y de la configuración de plataforma para aplicaciones de Entra ID

Definir los URI de redirección correctos durante el registro de la aplicación parece sencillo, pero este paso es decisivo para la seguridad. Los URI de redirección indican a Entra ID adónde enviar a los usuarios (junto con sus tokens) tras un inicio de sesión correcto. Al configurarlos, Entra aplica reglas estrictas: nada de dominios comodín, nada de esquemas de URI peligrosos y nada de cabos sueltos que los atacantes puedan explotar.

Si estás creando una aplicación de página única (SPA), normalmente usarás una URL HTTPS que apunte al dominio de tu aplicación para garantizar una comunicación segura en la obtención de datos. Las aplicaciones nativas necesitan esquemas de URI vinculados al nombre del paquete o del bundle de la aplicación, lo que evita que aplicaciones ajenas secuestren tokens en el mismo dispositivo. Las aplicaciones web suelen usar sus endpoints de callback de inicio de sesión, y cada uno debe incluirse explícitamente.

Las configuraciones incorrectas provocan los clásicos errores de "redirect URI mismatch" y, lo que es peor, abren la puerta a que los atacantes intercepten tokens. Dedicar tiempo a identificar cada plataforma en la que se ejecutará tu aplicación, junto con los URI de redirección correspondientes, ayuda a garantizar una autenticación fluida y tranquilidad.

Recuerda actualizar el registro de tu aplicación cada vez que cambies las URL de cliente, añadas plataformas o amplíes entornos (como pruebas y producción). Mantener esos URI bien protegidos y ordenados es el primer paso para que el flujo de tokens sea hermético.

Fundamentos de los flujos de OAuth y la gestión de tokens

OAuth 2.0 se basa en un conjunto de flujos de autorización que cubren distintos casos de uso: inicios de sesión web, inicios de sesión móviles, llamadas de servidor a servidor o aplicaciones que se ejecutan sin usuario presente. El más popular y seguro de ellos es el flujo de código de autorización, diseñado para mantener los tokens sensibles fuera de los navegadores y las aplicaciones móviles, poniendo la seguridad en primer lugar.

Una vez que el usuario se ha autenticado y concede su consentimiento, tu aplicación recibe un código de corta duración. Debe intercambiar este código en el endpoint de tokens para obtener tokens de acceso y de actualización. Estos tokens conceden acceso temporal a los datos: cuando caducan, el token de actualización puede solicitar un nuevo token de acceso para mantener la sesión activa.

La gestión de tokens no se limita a controlar las fechas de caducidad; se trata de mantener los tokens seguros en todo momento. Esto implica usar comunicaciones seguras (como HTTPS), no exponer nunca secretos en el código del lado del cliente y aplicar el principio de mínimo privilegio al solicitar los ámbitos.

Esta sección te prepara para entender cómo OAuth gestiona los intercambios críticos entre usuarios, aplicaciones y plataformas, y cómo una gestión de tokens robusta respalda flujos de trabajo persistentes y seguros, tanto para usuarios finales como para sistemas automatizados.

Implementación del flujo de código de autorización de OAuth

1. Inicia la autorización: tu aplicación redirige al usuario al endpoint de autorización de Entra ID, incluyendo datos como el ID de cliente, los ámbitos solicitados y un parámetro state único y aleatorio para la protección contra CSRF.
2. El usuario concede el permiso: el usuario revisa la pantalla de consentimiento, en la que se muestran claramente los permisos que necesita tu aplicación, y aprueba el acceso.
3. Recibir el código de autorización: Tras el consentimiento, Entra ID redirige a tu URI de redirección configurada, pasando un código de autorización temporal y el valor de state que definiste inicialmente.
4. Intercambiar el código por tokens: Tu backend envía de forma segura el código, junto con tus credenciales de cliente (y el code verifier de PKCE, si lo usas), al endpoint de tokens de Entra. Si la verificación es correcta, recibes tokens de acceso (y, con frecuencia, de actualización).
5. Usar los tokens para acceder a las API: Tu aplicación ahora adjunta el token de acceso a cada solicitud a la API, demostrando la autorización en nombre del usuario. Los tokens de acceso solo son válidos durante un periodo corto, lo que minimiza la exposición, mientras que los tokens de actualización obtienen nuevos tokens de acceso para las sesiones en curso.

Seguir estos pasos en el orden correcto cierra agujeros de seguridad y ayuda a prevenir ataques como la interceptación de códigos o el uso indebido de tokens, sobre todo cuando trabajas con clientes públicos o manejas datos sensibles.

Buenas prácticas para gestionar la caducidad de los tokens de acceso y de actualización

1. Almacena los tokens de forma segura: Usa soluciones de almacenamiento seguras proporcionadas por el sistema operativo, como Keychain en iOS, Keystore en Android o gestores de secretos cifrados en el servidor. Nunca incluyas tokens codificados en los binarios de la aplicación ni los expongas en los registros.
2. Respeta la vigencia de los tokens: Supervisa el valor de expiración (claim exp) de cada token y actualízalo de forma proactiva antes de que caduque, para evitar solicitudes a la API fallidas y una mala experiencia de usuario.
3. Admite la rotación de tokens: Usa siempre el refresh token más reciente en cada solicitud y descarta rápidamente los tokens reutilizados o obsoletos. Así se limita el impacto si un token se ve comprometido.
4. Limita los permisos por token: Solicita únicamente los ámbitos que necesites y prefiere tokens de acceso de vida corta. Esto reduce drásticamente el daño si un token se filtra o es robado.

Cómo proteger las implementaciones de OAuth en distintos contextos

Implementar bien la integración de OAuth es mucho más que marcar pasos: se trata de construir capas de seguridad que se ajusten a la arquitectura de tu aplicación y a sus patrones de uso. Tanto si tu aplicación se ejecuta en el navegador, en un teléfono o solo en la nube, necesitas estrategias de autenticación adaptadas a cada contexto.

Tecnologías como PKCE (Proof Key for Code Exchange) blindan el flujo de código para clientes públicos, impidiendo que los atacantes intercepten códigos y los cambien por tokens. Por otro lado, en aplicaciones que se ejecutan en entornos seguros, los secretos de cliente y los certificados son tus mejores herramientas para acreditar la identidad y gestionar la confianza.

Una gestión cuidadosa de los tokens y un control estricto de los niveles de privilegio ayudan a evitar fugas accidentales y a limitar el posible alcance del daño si algo sale mal. Al elegir las herramientas de seguridad adecuadas (PKCE, secretos, certificados y un ámbito de permisos bien definido), reduces considerablemente la superficie de ataque y aumentas las probabilidades de un funcionamiento fluido y conforme a la normativa.

A continuación se presentan estrategias probadas que sirven para contrarrestar amenazas habituales y adaptar tu configuración de OAuth para una protección sólida en todo tipo de aplicaciones y entornos.

Cómo PKCE protege la autorización de OAuth en clientes públicos

PKCE (Proof Key for Code Exchange) es fundamental cuando se usa OAuth en aplicaciones móviles y de navegador, es decir, clientes públicos en los que no es posible almacenar un secreto. Al iniciar el flujo de código de autorización, tu aplicación genera un "code verifier" aleatorio y un "code challenge" con hash. Estos valores viajan con el usuario y con la solicitud de token final. Aunque un atacante consiga un código de autorización, no podrá cambiarlo por un token sin este verifier secreto, lo que hace prácticamente imposibles los ataques de interceptación de código en Microsoft Entra ID y plataformas similares.

Gestión de secretos de cliente, certificados y credenciales federadas

• Secretos de cliente: los usan las aplicaciones confidenciales, como los servicios backend de confianza, para demostrar su identidad en el endpoint de tokens. Guárdalos en almacenes seguros, rótalos periódicamente y nunca los incluyas en el código de la aplicación del lado del cliente.
• Certificados: para una mayor garantía, usa certificados X.509 en lugar de secretos simples para reforzar la seguridad de los identificadores de tu aplicación. Los certificados permiten una validación más segura mediante pares de claves pública y privada, y son ideales para sectores regulados o aplicaciones con requisitos de cumplimiento estrictos.
• Credenciales federadas: para configuraciones de "trae tu propia identidad", usa credenciales federadas, como la identidad federada de Microsoft Entra o proveedores externos. Esto permite la autenticación sin gestionar secretos directamente, lo que reduce la carga de administración.
• Gestión en pipelines: en los flujos de CI/CD, inserta y rota secretos y certificados según sea necesario, sin codificarlos nunca en el control de código fuente. Las alertas automáticas de caducidad añaden otra capa de resiliencia.

Proteger los tokens y reducir la exposición de privilegios

• Almacena los tokens solo en ubicaciones seguras (almacenes del sistema operativo, entornos de servidor cifrados), nunca en un almacenamiento accesible para el usuario.
• Transmite siempre los tokens a través de HTTPS o canales seguros; HTTP sin cifrar expone los tokens a la interceptación.
• Solicita los permisos mínimos («scopes») para cada token: nunca pidas más de lo que necesita tu aplicación.
• Audita periódicamente el uso de los tokens y las asignaciones de privilegios para evitar una acumulación de permisos que pase desapercibida.

Mejores prácticas de OAuth en aplicaciones móviles y nativas

Las aplicaciones móviles y nativas tienen obstáculos particulares: los dispositivos se pierden, las aplicaciones comparten espacio de almacenamiento y los usuarios esperan un inicio de sesión rápido y casi invisible. Por eso, seguir las mejores prácticas de OAuth en iOS, Android y escritorio, usando los SDK integrados y mecanismos de almacenamiento probados, marca la diferencia.

El SDK adecuado (como MSAL para Microsoft Entra ID) se encarga de gran parte del trabajo pesado: gestiona los tokens, la lógica de renovación y la integración con el almacenamiento seguro a nivel del sistema operativo. Para los tokens sensibles, estos SDK determinan por defecto el repositorio más seguro y resuelven las particularidades de cada dispositivo o sistema operativo.

No descuides una experiencia de usuario fluida: los enlaces universales, los enlaces profundos y los flujos con el navegador del sistema ayudan a los usuarios a completar el inicio de sesión sin confusión ni riesgo de phishing. Bien configurada, tu aplicación redirige a los usuarios a una vista web del sistema segura y de confianza, y después los devuelve de forma segura a la aplicación cuando el inicio de sesión termina, sin ventanas emergentes ni fugas de tokens.

Estas prácticas no solo sirven para proteger los tokens, sino también para generar confianza en los usuarios finales, lo que aumenta la adopción y reduce los problemas de soporte a futuro.

Enlaces universales y autenticación nativa de primera parte

Los enlaces universales (en iOS) y los esquemas de aplicación (en Android) hacen que la autenticación de los usuarios sea mucho más segura. Al usar enlaces verificados por el sistema operativo y vinculados a la identidad de tu aplicación, impides que aplicaciones maliciosas intercepten las redirecciones de inicio de sesión y obtengan tokens que no les corresponden. La autenticación nativa aprovecha los navegadores de confianza del sistema, de modo que es el usuario real quien inicia sesión, eliminando el phishing, el espionaje de tokens y los inicios de sesión accidentales en aplicaciones no relacionadas. En conjunto, estas herramientas ofrecen a los usuarios una experiencia fluida y segura, prácticamente a prueba de las amenazas habituales de OAuth en dispositivos móviles.

Solución de errores de OAuth y escenarios avanzados

Las integraciones de OAuth rara vez funcionan perfectamente a la primera: los errores y los casos límite inesperados forman parte del proceso. Con frecuencia, los problemas se deben a discrepancias en los URI de redirección, códigos caducados o secretos de cliente incorrectos, que pueden bloquear los flujos de autenticación y afectar al uso de la aplicación. Esta sección te ayudará a interpretar las respuestas de error, rastrear los intercambios fallidos y resolver los problemas antes de que lleguen a tu servicio de asistencia técnica.

Más allá de lo básico, algunos escenarios, como la comunicación entre servidores, el inicio de sesión de dispositivos IoT o la necesidad de garantías de protocolo más sólidas, requieren extensiones especializadas de OAuth o flujos no interactivos. Las cuentas de servicio, el TLS mutuo y los flujos de código de dispositivo están diseñados específicamente para estos requisitos.

Con orientación sobre los fallos más comunes y los casos de uso avanzados, estarás mejor preparado para solucionar problemas, diseñar y mantener soluciones de OAuth robustas, incluso cuando el ecosistema de tus aplicaciones se vuelva más complejo.

Tanto si estás buscando un error persistente en el endpoint de tokens como si preparas tu aplicación para los retos del mundo real (donde abundan los dispositivos con entrada limitada y los servicios sin interfaz), estas ideas mantendrán tus integraciones fluidas y seguras.

Interpretar las respuestas de error de OAuth y los fallos en el intercambio de código

• URI de redirección no válido: se produce cuando la redirección no coincide con la lista registrada; revisa con cuidado los valores introducidos y las mayúsculas y minúsculas.
• Código de autorización caducado: los usuarios tardan demasiado o los códigos se reutilizan; utilízalos siempre una sola vez y justo después de recibirlos.
• Credenciales de cliente no coincidentes: se ha proporcionado un secreto o certificado incorrecto; comprueba las credenciales y renuévalas cuando sea necesario.
• Scope o recurso no válido: la API o los scopes solicitados no están permitidos o están mal escritos; verifica la configuración y los permisos de la aplicación.

Cuentas de servicio, dispositivos de entrada limitada y extensiones de OAuth

• Cuentas de servicio (flujo de credenciales de cliente): permiten que las aplicaciones se autentiquen sin un usuario, ideal para automatización y trabajos entre servidores.
• Flujo de código de dispositivo: pensado para smart TV e IoT; solicita al usuario que complete el proceso en otro dispositivo, y resulta útil cuando no hay un navegador disponible.
• Extensión de TLS mutuo: utiliza certificados tanto en el servidor como en el cliente, lo que refuerza la seguridad de las integraciones sensibles y garantiza que la aplicación emplee métodos de autenticación sólidos.
• Registro dinámico de clientes: automatiza la incorporación de aplicaciones en sistemas SaaS grandes o multiinquilino, simplificando la gestión de credenciales a escala.

Guía de registro de aplicaciones y OAuth en Entra ID

Ventajas

• Gestión de identidades centralizada: se integra con Microsoft Entra ID para mantener una identidad coherente de usuarios y aplicaciones en todos los servicios.
• Controles de seguridad sólidos: admite OAuth 2.0, OpenID Connect, acceso condicional y permisos granulares (ámbitos y roles).
• Protocolos estándar del sector: aprovecha los estándares OAuth/OIDC, ampliamente compatibles, lo que facilita la interoperabilidad con herramientas y bibliotecas de terceros.
• Configuración detallada de las aplicaciones: permite configurar URI de redirección, certificados y secretos, permisos de API y opciones de personalización de marca para las aplicaciones.
• Modelo de consentimiento granular: admite permisos delegados y de aplicación, con flujos de consentimiento de administrador para limitar las aplicaciones con privilegios excesivos.
• Funciones empresariales: admite aplicaciones multiinquilino, colaboración B2B e integración con Microsoft 365 y los servicios de Azure.
• Supervisión y auditoría: incluye registros, inicios de sesión y pistas de auditoría integrados para los registros de aplicaciones y los flujos de OAuth, lo que ayuda con el cumplimiento y la resolución de problemas.
• Herramientas para desarrolladores y SDK: amplia oferta de SDK de la plataforma de identidad de Microsoft, documentación y ejemplos de inicio rápido que agilizan la implementación.

Desventajas

• Complejidad para quienes empiezan: la configuración y los modelos de permisos (URI de redirección, URL de respuesta, flujo implícito frente a flujo de código de autorización, ámbitos) pueden resultar confusos para los desarrolladores nuevos.
• Curva de aprendizaje pronunciada en las funciones de seguridad: el acceso condicional, las identidades administradas y la configuración avanzada de tokens requieren conocimientos de seguridad más profundos para configurarse de forma segura.
• Riesgo de proliferación de permisos: un consentimiento inadecuado o permisos de aplicación demasiado amplios pueden dar lugar a aplicaciones con privilegios excesivos si no se revisan periódicamente.
• Matices en la gestión de tokens: la gestión de tokens de actualización, la vigencia de los tokens y su revocación tiene comportamientos específicos de cada plataforma que pueden causar problemas de integración.
• Consideraciones sobre los límites entre inquilinos: el comportamiento de las aplicaciones multiinquilino y las solicitudes de consentimiento de administrador añaden complejidad operativa en escenarios entre inquilinos.
• Cambios en la interfaz y la terminología: Microsoft actualiza periódicamente la interfaz y los nombres de Entra (Azure AD → Entra ID), lo que puede provocar desajustes o confusión con la documentación.
• Dependencia del ecosistema de Microsoft: el fuerte acoplamiento con las funciones de Entra ID puede limitar la portabilidad a proveedores de identidad que no son de Microsoft sin tener que rehacer trabajo.
• Riesgo de configuración incorrecta: una configuración errónea del registro de aplicaciones (por ejemplo, URI de redirección, URL de respuesta o ajustes del flujo implícito) puede crear agujeros de seguridad o interrumpir los flujos de autenticación.

Próximos pasos y recursos clave de la comunidad para tener éxito con OAuth

Muy bien, ya tienes OAuth configurado y funcionando, pero no bajes el ritmo todavía: asegúrate de que la aplicación que obtiene los tokens esté correctamente configurada. Tener lo básico conectado es solo el primer paso. Si de verdad quieres que tu aplicación destaque y mantener seguros a tus usuarios, ha llegado el momento de explorar los extras. Empieza a revisar bibliotecas cliente avanzadas, experimenta con Microsoft Graph y explora las nuevas funciones de identidad que pueden hacer tu integración más sólida y más fluida para todos los implicados.

Tampoco tienes que resolverlo tú solo. La documentación de Microsoft Entra ID es tan profunda como el lago Michigan, y incluye guías actualizadas, ejemplos de código y todas esas especificaciones técnicas que probablemente querrás tener a mano. Haz el hábito de revisar las actualizaciones, sobre todo porque los estándares de OAuth y de identidad en la nube siguen evolucionando.

¿Contento con tu registro de aplicaciones? Perfecto. Ahora mira cómo la gente del sector se ha puesto creativa. Consulta los foros de desarrolladores, los foros de debate oficiales e incluso los repositorios de GitHub de las bibliotecas de autenticación. Si te topas con un muro, es muy probable que alguien ya haya resuelto tu problema exacto o, al menos, se haya quejado de él con suficiente fuerza como para que alguien responda.

Si te gusta experimentar y aprender haciendo, revisa las pruebas gratuitas disponibles, los inquilinos de prueba y las funciones en versión preliminar pública. Te permiten romper cosas (sin riesgo) y descubrir qué funciona antes de implementar cambios con tus usuarios reales. Y no olvides que OAuth y la seguridad son un esfuerzo colectivo, así que comparte tus logros y tus dudas: así ayudarás a que todo el ecosistema siga siendo transparente y crezca con fuerza, y a que todos entiendan mejor el flujo de OAuth.

Lista de verificación de la guía de registro de aplicaciones y OAuth & - Entra ID

• Planifica el tipo de aplicación y el modelo de acceso: decide entre inquilino único, multiinquilino o cuentas personales de Microsoft, y determina si es una SPA, una aplicación web, móvil, daemon o de servicio.
• Registra la aplicación en Entra ID: crea un nuevo registro de aplicación con un nombre claro y los tipos de cuenta admitidos.
• Configura los URI de redirección: añade los URI de redirección o de devolución de llamada correctos para cada plataforma (https, esquema personalizado, localhost para desarrollo).
• Configura los ajustes de plataforma de la aplicación: habilita las opciones de plataforma SPA, web y móvil y de escritorio, y configura los flujos implícitos o de concesión según sea necesario.
• Crea y gestiona los secretos de cliente: genera secretos de cliente para los clientes confidenciales, anota la fecha de caducidad y guárdalos de forma segura en Azure Key Vault.
• Usa certificados para la autenticación: sube certificados de clave pública para los clientes confidenciales de producción en lugar de secretos de larga duración.
• Configura los permisos de API: añade los ámbitos y permisos de Microsoft Graph o de API personalizadas que necesite la aplicación.
• Concede el consentimiento de administrador cuando sea necesario: solicita y registra el consentimiento de administrador para los permisos delegados que requieran consentimiento para todo el inquilino.
• Define y expón ámbitos personalizados (si es una API): añade ámbitos en "Exponer una API" y define sus nombres, descripciones y nombres para mostrar en el consentimiento de administrador.
• Configura roles de aplicación (si es necesario): define roles de aplicación y delegados para el control de acceso basado en roles y asígnalos a usuarios, grupos o aplicaciones cliente.
• Configura CORS para las SPA que llaman a API: añade los orígenes permitidos en la API o configura las directivas de CORS de la puerta de enlace.
• Elige el flujo de OAuth 2.0: selecciona el código de autorización (con PKCE para clientes públicos), las credenciales de cliente para aplicaciones daemon o el código de dispositivo, según corresponda.
• Implementa PKCE para clientes públicos: exige Proof Key for Code Exchange en las SPA y en las aplicaciones nativas para evitar la interceptación del código.
• Valida los tokens correctamente: verifica el emisor, la audiencia, la firma, la caducidad y las notificaciones requeridas con las bibliotecas de identidad de Microsoft o con la lógica de validación de JWT.
• Usa las bibliotecas de autenticación de Microsoft (MSAL): prefiérelas para la adquisición, el almacenamiento en caché y la renovación de tokens, así como para su gestión segura en todas las plataformas.
• Configura el acceso condicional y MFA (si es necesario): aplica directivas al registro de la aplicación o a los flujos de inicio de sesión de usuarios para aplicar controles de seguridad.
• Supervisa los inicios de sesión y los registros de auditoría: habilita el registro y revisa los eventos de inicio de sesión, los consentimientos y las operaciones de administración en los registros de Entra ID.
• Aplica el principio de mínimo privilegio: solicita solo los permisos necesarios y prefiere el consentimiento incremental para minimizar la exposición.
• Rota los secretos y certificados periódicamente: implementa la rotación automatizada y alertas para las credenciales que están por caducar.
• Protege el código y el almacenamiento del lado del cliente: evita guardar secretos en las aplicaciones cliente, usa almacenamiento seguro y sigue las mejores prácticas de cada plataforma.
• Prueba los flujos de inicio de sesión y de tokens en desarrollo y preproducción: valida los flujos de autenticación, la duración de los tokens, la lógica de renovación, el manejo de errores y la experiencia de consentimiento.
• Prepara la documentación para usuarios y administradores: incluye los pasos de consentimiento, los permisos necesarios y la guía de solución de problemas.
• Revisa y actualiza el registro de aplicaciones periódicamente: audita permisos, roles, secretos y registros para detectar aplicaciones obsoletas o sin uso.
• Aplica protecciones de red y de API: considera API Management, WAF, la limitación de velocidad y los puntos de conexión de servicio para proteger las API de back-end.

Uso de tokens de acceso de Azure, OAuth y autenticación

¿Qué es la guía de registro de aplicaciones y OAuth y por qué es importante?

Una guía de registro de aplicaciones & OAuth explica cómo registrar una aplicación cliente en un proveedor de identidades (por ejemplo, con Azure) e implementar los flujos de autorización de OAuth 2.0 para que tu aplicación pueda solicitar acceso a recursos protegidos de forma segura. Es fundamental tanto si desarrollas aplicaciones web, aplicaciones de una sola página, aplicaciones de escritorio o back-ends de servidor web, ya que la aplicación necesita un id. de aplicación (application ID) y un id. de cliente (client ID), además de un secreto de cliente (para los clientes confidenciales), para obtener un token de acceso y recibir un token de ID cuando corresponda.

¿Cómo registro una aplicación de Azure y obtengo el id. de aplicación?

Para registrar una aplicación de Azure, ve al Portal de Azure, crea un nuevo registro de aplicación, indica un nombre y los URI de redirección, y anota el id. de cliente (id. de aplicación) que aparece en la información general de la aplicación. Si tu aplicación es un cliente confidencial (servidor web o aplicación web tradicional), crea un secreto de cliente para usarlo junto con el id. de cliente. Esta aplicación registrada se usa en la autorización y para solicitar tokens de acceso a los servicios de Microsoft.

¿Qué flujo de autorización de OAuth 2.0 debo usar para las SPA?

Las aplicaciones de una sola página (SPA) deberían usar el flujo de código de autorización con PKCE (Proof Key for Code Exchange) en lugar del flujo implícito, para garantizar que la aplicación obtenga los tokens de forma segura. El flujo de código con PKCE permite que la aplicación intercambie el código por un token de acceso de forma segura desde un cliente basado en navegador, de modo que las SPA puedan usar OAuth sin exponer secretos de cliente en el navegador.

¿Cómo funciona la solicitud de autorización y qué parámetros son obligatorios?

Una solicitud de autorización se envía al endpoint de autorización del proveedor de identidades e incluye normalmente client_id (id. de la aplicación), response_type (por ejemplo, code), redirect_uri, scope y state. En el caso de las SPA que usan el flujo de código con PKCE, también se incluyen code_challenge y code_challenge_method. El usuario se autentica y da su consentimiento (consentimiento de OAuth), y el servidor de autorización devuelve un código al URI de redirección, que la aplicación puede intercambiar por un token de acceso.

¿Cómo programo el intercambio del código por un token de acceso?

Después de recibir el código de autorización, la aplicación cliente envía una solicitud al endpoint de token que incluye el code, client_id (y client_secret en los clientes confidenciales), redirect_uri y grant_type=authorization_code. En PKCE también se incluye code_verifier. El endpoint de token responde con un token de acceso, un token de ID (cuando se solicita) y, posiblemente, un token de actualización para obtener un nuevo token de acceso cuando el actual caduque.

¿Cómo obtengo un token de acceso y lo uso para llamar a las API?

Obtén un token de acceso completando el flujo de autorización de OAuth 2.0 elegido y llamando al endpoint de token. Una vez que tengas el token de acceso, envíalo en la cabecera Authorization con el esquema Bearer al llamar a servicios de Microsoft u otras API (por ejemplo, Google Calendar o API personalizadas). Valida los tokens en el servidor web o en el lado del recurso para asegurarte de que las solicitudes de la aplicación están autorizadas.

¿Qué hago cuando el token de acceso caduca y cómo obtengo un nuevo token de actualización?

Cuando el token de acceso caduque, usa el token de actualización (si se ha proporcionado) para solicitar un token de acceso al endpoint de token con grant_type=refresh_token. Algunos flujos o proveedores pueden emitir un nuevo token de actualización al renovar; otros pueden reutilizar el mismo. Si no hay token de actualización disponible (clientes públicos o flujos de corta duración), redirige al usuario a tu aplicación para iniciar una nueva solicitud de autorización.

¿Necesito registros de aplicación independientes para las aplicaciones web y para las móviles o de escritorio?

A menudo se necesitan registros de aplicación independientes cuando los tipos de aplicación difieren de forma significativa (por ejemplo, aplicación web tradicional con servidor, SPA y aplicaciones de escritorio), porque los URI de redirección, los secretos de cliente y los flujos permitidos varían. Usar registros independientes permite configurar flujos de autorización y URI de redirección específicos para cada tipo de aplicación.

¿Cuál es la diferencia entre el registro de aplicación cliente y la aplicación en un inquilino?

El registro de aplicación cliente hace referencia a la entrada de registro concreta en el proveedor de identidades (la aplicación de Azure) que contiene la configuración, como los URI de redirección y los secretos. Una aplicación en un inquilino indica que el registro existe en un inquilino concreto de Azure AD y que se le pueden asignar roles y permisos dentro de ese inquilino. Un mismo registro de aplicación puede ser multiinquilino o de un solo inquilino, según tus necesidades.

¿Cómo solicito acceso a los servicios de Microsoft y qué permisos se necesitan?

Solicita acceso especificando en la solicitud de autorización los ámbitos (scopes) que necesita tu aplicación. Para los servicios de Microsoft, configura los permisos de API en el registro de la aplicación de Azure y, a continuación, pide a los usuarios que den su consentimiento (consentimiento de OAuth) o pide a un administrador que conceda el consentimiento para todo el inquilino. La aplicación solicita ámbitos como User.Read o ámbitos de API personalizadas dentro de las solicitudes de la aplicación, y utiliza el token de acceso para llamar a los servicios.

¿Cómo protejo los secretos de cliente y evito filtrar credenciales en las aplicaciones de una sola página?

Las SPA no deben almacenar secretos de cliente, porque el código que se ejecuta en el navegador puede inspeccionarse. Usa el flujo de código de autorización con PKCE para que la aplicación pueda obtener un token de acceso de forma segura sin un secreto de cliente. En las aplicaciones confidenciales (servidor web), guarda el identificador y el secreto de cliente en el lado del servidor, donde no estén expuestos a los usuarios.

¿Cuál es la función del URI de redirección y por qué debe coincidir con el registro de la aplicación?

El URI de redirección es el destino al que el proveedor de identidades envía la respuesta de autorización (código o token). Debe coincidir con el URI de redirección registrado en el registro de aplicación para evitar la secuestración de la respuesta de autorización. Usa una coincidencia exacta o los patrones permitidos que defina el proveedor; si no coinciden, el intercambio de tokens fallará.

¿Cómo hago que los usuarios se autentiquen y reciban un token de id además de un token de acceso?

Para recibir un token de id, solicita el ámbito openid e incluye un response_type que active la emisión del token de id (flujo de código de autorización con openid). El token de id contiene notificaciones de identidad sobre el usuario autenticado. Usa el token de id para iniciar la sesión del usuario en tu aplicación cliente y el token de acceso para llamar a las API posteriores.

¿Qué flujos de autorización específicos se aplican a las aplicaciones web tradicionales frente a las aplicaciones de página única?

Las aplicaciones web tradicionales (del lado del servidor) suelen usar el flujo de código de autorización con credenciales de cliente (client_id y client_secret) e intercambian el código en el servidor web. Las aplicaciones de página única usan la concesión de código de autorización con PKCE y sin secreto de cliente. Las aplicaciones de escritorio también usan PKCE. Elige el flujo según el tipo de aplicación y el lugar donde puedas almacenar los secretos de forma segura.

¿Se puede usar un mismo registro de aplicación para varias aplicaciones cliente o debo crear un registro por cada aplicación?

Puedes usar un único registro de aplicación para varias aplicaciones cliente si comparten la misma configuración y los mismos URI de redirección, pero las buenas prácticas suelen recomendar registros de aplicación separados para aplicaciones distintas, con el fin de aislar los permisos, los URI de redirección y la gestión del ciclo de vida. Ten en cuenta si la aplicación podría necesitar ámbitos de permisos diferentes o un comportamiento de consentimiento de administrador distinto.

¿Cómo valido los tokens en mi servidor web o API?

Tu servidor web o API debe validar la firma, el emisor, la audiencia (identificador de la aplicación o application id) y la caducidad del token de acceso o del token de id. Usa el documento de descubrimiento del proveedor para obtener las claves de firma y sigue las bibliotecas de validación recomendadas para tu plataforma. La validación garantiza que solo se acepten solicitudes de aplicaciones autenticadas y autorizadas.

¿Cuál es el proceso para solicitar un token de acceso para un servicio de backend mediante credenciales de cliente?

Para escenarios de servidor a servidor, registra una aplicación de Azure, concédele permisos de aplicación y, a continuación, usa el flujo de credenciales de cliente: haz una solicitud POST al punto de conexión de token con grant_type=client_credentials, client_id, client_secret y scope o resource. El punto de conexión de token devuelve un token de acceso que el backend puede usar para llamar a servicios de Microsoft o a API protegidas.

¿Cómo gestiono el consentimiento de OAuth y el consentimiento de administrador en aplicaciones multiinquilino?

Cuando tu aplicación está registrada como multiinquilino, los usuarios de otros inquilinos pueden dar su consentimiento a los permisos delegados durante la solicitud de autorización. En el caso de los permisos que requieren consentimiento de administrador, un administrador debe conceder el consentimiento para su inquilino. Incluye instrucciones y una URL de consentimiento para que los administradores de los inquilinos concedan el consentimiento de OAuth a gran escala.

¿Qué pasos de solución de problemas debo seguir si mi solicitud de autorización falla?

Confirma que la aplicación está registrada en el portal de Microsoft, que el URI de redirección coincide, que el client_id y el client_secret son correctos, que los ámbitos son válidos y que el tipo de concesión y los parámetros de PKCE (si se usan) son correctos. Revisa los mensajes de error devueltos por el punto de conexión de autorización o de token y consulta los registros tanto del cliente como del servidor. Stack Overflow y la documentación del proveedor pueden ayudarte con códigos de error específicos.

¿Cómo puedo integrar API de terceros, como Google Calendar, con mi aplicación registrada?

Para integrar Google Calendar u otras API de terceros, implementa los flujos de autorización de OAuth 2.0 que exijan esos proveedores. Tu aplicación debe solicitar los ámbitos correctos para la API de terceros y gestionar ciclos de vida de token independientes. Puede que necesites registros de aplicación cliente separados en cada proveedor y coordinar la obtención de tokens de acceso para cada servicio.

¿Cuándo debo usar el flujo de código de dispositivo u otros flujos especiales para ciertos dispositivos?

Usa el flujo de código de dispositivo para dispositivos con entrada limitada en los que no hay un navegador disponible. Este flujo permite que un usuario visite una URL de verificación en otro dispositivo para autenticarse. Es uno de los flujos de autorización específicos que se admiten junto con el flujo de código de autorización, las credenciales de cliente y los flujos de token de actualización, para adaptarse a distintos tipos de factor de forma de las aplicaciones.