Azure Active Directory frente a Okta

Escrito por Sean Blanton en February 17, 2023

Comparte este artículo

A medida que más organizaciones de las tecnologías de la información (TI) cambian su infraestructura de administración de la identidad a la cloud, la competencia por encontrar soluciones de manejo de identidad SaaS se intensifica. En el entorno del inicio de sesión único (SSO) dentro de la web, por lo general es el Azure Active Directory (Azure AD o AAD) versus Okta.

De hecho, Microsoft y Okta comparten un poco de historia entre sí, con fuertes declaraciones y acusaciones que se remontan a través de los años. Curiosamente, mientras ambas compiten en el mercado de la Identidad-como-un-Servicio (IDaaS) o el mercado de las aplicaciones web SSO, ambas partes también dependen en gran medida del Microsoft Active Directory para funcionar en un alto nivel.

Mientras son competidores donde se superponen en el SSO de la aplicación web y la autenticación multi-factor (MFA o 2FA), divergen en gran manera en diferentes rutas más allá de su similitud. Después de la competencia frente a frente  en el inicio de sesión único dentro de la aplicación web y en la 2FA, son dos  herramientas separadas que satisfacen diferentes necesidades para los administradores de las TI. Actualmente, compararemos y contrastaremos Azure AD con Okta; y exploraremos donde reside su intensa competencia.

Azure AD: Piense en una Extensión del Active Directory, No en un Reemplazo

Muchas organizaciones de TI están inicialmente confundidas por la similitud de sus nombres y se cree que el Azure Active Directory se trata del reemplazo de los servicios de directorio basado en la cloud para el Active Directory, pero este no es el caso. El Active Directory se sigue alojando localmente, mientras que Azure AD se ha diseñado para ser el sistema de gestión de usuario basado en la cloud para la infraestructura en la cloud y las aplicaciones en la web.

Esto se demuestra por el hecho de que Azure AD no cuenta con la capacidad de base para autenticar usuarios localmente o en sistemas remotos incluyendo Windows® (sin Windows 10), ordenadores Mac® y Linux®, infraestructura de la cloud albergada en AWS® o GCP® (la Plataforma de la cloud en Google), los recursos locales de la red (VPNs, WiFi), los servidores de archivos locales basados en Samba y por lo general cualquier otra cosa que opere fuera del ecosistema de Microsoft Azure (fuera de las aplicaciones de la web). 

La función principal de Azure AD es de ser la infraestructura de autenticación de usuario para Azure, el servicio de computación en la cloud de Microsoft que compite con AWS y GCP, Microsoft 365, y una solución de sesión única en la web. Está diseñado en gran manera para servidores Windows e infraestructuras basadas en Windows alojadas en Azure, con la finalidad de Microsoft de cambiar la infraestructura local de sus clientes a su centro de datos (Azure). Microsoft emplea esto en gran medida para competir con AWS, para contener el éxodo del volumen de trabajo de los servidores de Windows lejos de ellos.

Esto significa que a pesar de que el Azure Active Directory pueda ser un avance significativo hacia un sistema de gestión de usuario basado en la cloud, todavía vincula a las organizaciones a Microsoft; incluso la propia arquitectura de referencia de Microsoft requiere un AD local (y el puente de tecnología de Azure AD Connect) para que un AAD para administrar los recursos locales y sistemas no basados en Windows 10.

Como resultado, la mayoría de las organizaciones utilizan una instancia de Active Directory local para administrar su infraestructura local, mientras siguen gestionando una solución adicional de identidad (Azure AD) por su infraestructura de cloud Azure. Ambas se conectan a través de otra solución de Microsoft llamada Conectividad Azure AD (Azure AD Connect).

No Se Olviden de Okta

Al llegar al amplio ámbito de identidad y acceso de gestión (IAM) y más específicamente al IDaaS, las soluciones de aplicaciones web SSO se encuentran como prioridad en la mente de los administradores de TI referente a la migración a la cloud. Okta, la cual se hizo pública en 2017, fue una de las primeras aplicaciones web basadas en la cloud para soluciones SSO en el mercado. Las soluciones de aplicaciones web SSO, comúnmente referidas como las plataformas de primera generación de Identidad-como-un-Servicio (IDaaS), resultan populares debido al amplio uso de las aplicaciones web tales como: Slack, GitHub, Salesforce, y miles de otras.

Si bien Okta resulta como la plataforma líder de aplicaciones web SSO, de acuerdo a Okta se encuentra emparejada con un proveedor principal local, el cual ha sido históricamente el Active Directory, alrededor del 95% de las veces. Mientras que el enfoque de este multi producto puede funcionar, con certeza genera retos, incluyendo el alto costo. Incluso crea una extraña dinámica para Okta donde compiten con Microsoft con respecto a AAD, pero trabajan juntos con organizaciones de TI donde Okta y el Active Directory se encuentran presentes. No es de extrañar que Okta considera a Microsoft como su mayor competidor y que cuando se encuentran presente en las cuentas intentan bloquearlas con acuerdos a largo plazo para que los clientes no puedan cambiarlos con facilidad.

Dónde se Cruzan las Soluciones

Ahora que ya entendemos que Azure AD provee una gestión de usuario para Azure, M365 y SSO para elegir aplicaciones web y Okta resulta el principal proveedor de aplicación web SSO, podemos investigar en donde chocan estos dos puntos de solución.

La superposición entre ambas se debe al hecho de que Azure AD, a diferencia del Active Directory, ha implementado habilidades dentro de la aplicación web SSO y un autenticador de multi factor. De hecho, el Azure Active Directory rivaliza con proveedores de aplicaciones web SSO tales como Okta dentro del mercado, y han generado que Google los incluya en su propia solución SSO, la solución de gestión de Identidad de la cloud en Google (sin mencionar que incluso Amazon ha ingresado recientemente en el mercado de aplicaciones web SSO). Por supuesto, las razones detrás del interés por parte de Microsoft, Google y Amazon no se encuentran en dominar el mercado de SSO, sino en mantener cautivas a las organizaciones con sus identidades y en última instancia emplear esa influencia para venderles otros servicios. Una vez que una identidad ha sido encerrada dentro de Azure AD o el área de trabajo de Google (“Google Workspace”), resulta más difícil para el cliente sacarlas para emplear soluciones que no sean de Microsoft o Google, y de esta manera los clientes terminan por defecto utilizando más soluciones de Microsoft y Google, lo cual es, al fin y al cabo, el intento principal de aquellas organizaciones.

Okta, por supuesto, se centra principalmente en el SSO de aplicaciones web, por lo que tiene sentido que los administradores de TI comparen Azure AD y Okta, aunque los servicios de Azure AD van más allá del SSO. Tal como muchos administradores de TI se dan cuenta rápidamente, Azure AD y Okta son sólo piezas del rompecabezas general de gestión de identidades que están tratando de resolver. Por ejemplo, ¿cómo controlan las organizaciones el acceso a los sistemas macOS y Linux, a las aplicaciones locales, a las redes VPN y WiFi locales, y a otras cosas más con solo AAD u Okta como plataforma de gestión de identidades?

Con el deseo de cambiar a una gestión de la identidad basada en la cloud, el lugar donde los administradores de TI necesitan comenzar es encontrando un reemplazo para el Active Directory, o un proveedor de identidad basado en la cloud. El proveedor de identidad funciona como la plataforma base desde la cual las organizaciones TI construyen su enfoque IAM. Tanto a AAD como a Okta se les dificulta ser el IdP principal, aunque ambas están dispuestas a intentar. Azure AD vinculará tus identidades a dispositivos con Windows 10 para atraerte, mientras que Okta le restará importancia a los dispositivos, dado que a pesar de todo, el mundo funciona gracias a las aplicaciones web, ¿no?

Sin embargo, las organizaciones deberían empezar por los cimientos. Una vez que los cimientos están establecidos con un directorio en la cloud, puede tener sentido considerar una solución de SSO para aplicaciones web, o dependiendo de las necesidades de la organización, puede no ser necesario. Una base sólida y abierta garantizará que una organización pueda conectar a sus usuarios a cualquier cosa que necesiten, ya sea un dispositivo macOS, un servidor Linux de AWS o un servidor de archivos Samba local. Esta flexibilidad es fundamental a la hora de considerar el enfoque correcto de gestión de identidades en general.

Un Enfoque Moderno con la Plataforma de Directorio JumpCloud

Reinventamos el enfoque del servicio de directorio en la cloud. Esta plataforma de gestión de identidades en la cloud integra el SSO de aplicaciones web y la autenticación multi-factor (MFA) con la gestión segura del acceso de los usuarios a los sistemas, aplicaciones web, redes WiFi y VPN, aplicaciones heredadas, así como archivos en la cloud o locales, todo ello utilizando un directorio en la cloud. De hecho, la Plataforma de Directorio JumpCloud está construida utilizando los principios de Seguridad de Zero Trust, por lo que puede aprovechar esos conceptos para un acceso seguro y sin fricciones a los recursos de TI. El resultado es que no necesita considerar soluciones adicionales como Azure AD u Okta (o incluso soluciones de gestión de sistemas / MDM tales como Intune). Por supuesto, JumpCloud se integra estrechamente con AAD o Google Workspace para que pueda aprovisionar / desaprovisionar el acceso a estas plataformas de productividad críticas. Además, JumpCloud es una plataforma de control de acceso y gestión de dispositivos unificado desde la cloud, pero para prácticamente cualquier tipo de recurso.

Regístrese hoy para una prueba gratuita de 30 días.

Sean Blanton

Sean Blanton is the Director of Content at JumpCloud and has spent the past decade in the wide world of security, networking and IT and Infosec administration. When not at work Sean enjoys spending time with his young kids and geeking out on table top games.

Continúa Aprendiendo con nuestro Newsletter