Descubre todo sobre los esquemas de autenticación con GeneXus
En esta publicación, describiré los nuevos esquemas de autenticación admitidos en GAM.
GAM significa GeneXus Access Manager. Es una funcionalidad incorporada de GeneXus para implementar autenticación y autorización en sus aplicaciones.
Para presentar las herramientas, primero echaremos un vistazo a lo que está pasando en el mundo de la seguridad y la autenticación.
La encuesta de Auth0 sobre esquemas de autenticación disponibles en el mercado revela que:
El 28 % ofrece autenticación multifactor, que es lo mismo que la autenticación de dos factores. Esto significa que el usuario tiene que validar dos factores para ingresar a la aplicación. En general, el primer factor es la contraseña y el segundo factor es un número aleatorio o algo enviado por correo electrónico o SMS.
El 45 % ofrece inicio de sesión único a través de los servicios existentes. Esto es muy bueno para los usuarios finales, ya que las empresas les permiten tener un único usuario y contraseña para acceder a todas sus aplicaciones o productos.
El 21% está ofreciendo autenticación biométrica, principalmente en aplicaciones nativas en dispositivos móviles.
El 31% está ofreciendo autenticación a través de redes sociales. Los más utilizados son Google, Facebook y Twitter.
Por último, el 20% está permitiendo el ingreso de usuarios sin contraseña. Con este método, el usuario no necesita tener una contraseña para ingresar a la aplicación. En cambio, simplemente ingresan una dirección de correo electrónico y el sistema les envía por correo electrónico el código de acceso a esa aplicación. Este código solo es válido por un período de tiempo muy corto.
¿Qué ofrece GeneXus respecto a todos estos esquemas de autenticación?
Veamos qué ofrece GeneXus para configurar cada uno de estos esquemas de autenticación:
OAuth 2.0,
conexión de identificación abierta,
Contraseña de un solo uso, y
Autenticación de dos factores.
Protocolo OAuth 2.0
OAuth 2.0 es el protocolo más utilizado entre los proveedores de identidad como Google, Facebook, Microsoft, etc.
¿Cómo funciona el protocolo OAuth 2.0?
Usemos un ejemplo específico: un usuario final va a navegar por una aplicación y tenemos 3 aplicaciones en Internet (ver imagen a continuación). Estas aplicaciones son 3 bases de conocimiento independientes con su propia base de datos, y cada una tiene habilitado GAM.
Las aplicaciones en ambos extremos son los clientes y la aplicación en el medio es el proveedor de identidad. He nombrado a los clientes “GeneXus.com” y “Download Center”; el Proveedor de Identidad podría ser la “Cuenta GeneXus”.
Cuando el usuario accede a esta aplicación, sabe que un proveedor de identidad realiza la autenticación, por lo que la aplicación se redirige a este proveedor de identidad, que muestra una pantalla de inicio de sesión.
Este es uno de los puntos fuertes, ya que las credenciales solo se ingresan en el proveedor de identidad. No se ingresan en los clientes. El Identity Provider es el encargado de validar estas credenciales y si las valida correctamente responde al cliente, el cual muestra la pantalla de usuario autenticado.
El protocolo OAuth es un poco más complejo que esto; aquí, entre el Proveedor de Identidad y el Cliente hay más intercambio de información. Lo que el proveedor de identidad responde al cliente se denomina código_de_acceso. Con ese código, el cliente solicita el token y luego de obtener el token, solicita información sobre el usuario de ese token. Una vez que tiene toda esa información en su base de datos local, se crea o actualiza el usuario, se crea una sesión y un token local, y ahí termina la autenticación. Detrás de todo está el estándar OAuth 2.0. ¿Qué sucede si, mientras navego por esta aplicación, accedo a otra aplicación que también se autentica con el mismo proveedor de identidad?
El proveedor de identidad detectará que ya está autenticado y responderá directamente con el código de acceso a esta aplicación. Aquí, el usuario también se crea o actualiza y luego se redirige a la pantalla con el usuario autenticado. Tenga en cuenta que esto no solo centraliza la autenticación, sino que también proporciona un inicio de sesión único entre todas las aplicaciones de la empresa.
¿Cuánto trabajo lleva configurar esto en nuestras aplicaciones?
La buena noticia es que con GeneXus no hay que programar nada, solo hacer configuraciones.
En este video doy instrucciones paso a paso para configurar la seguridad con GAM.
Conexión de identificación abierta
OpenID Connect se está convirtiendo en el protocolo más utilizado entre todos los proveedores de identidad. Esto se debe a que OpenID Connect se ejecuta dentro de OAuth 2.0. Podemos decir que lo hace más estandarizado, porque el estándar OAuth 2.0 no incluye cómo obtener la información del usuario.
Por lo tanto, lo que configuró en esta pestaña Información del usuario ya no es necesario cuando usa OpenID Connect. Puede dejar esa URL en blanco. Lo que sucedía antes era que cada proveedor de identidad devolvía la información de usuario que quería el proveedor de identidad.
Ahora hay un estándar y puedes configurarlo en el sector Autorización. Cuando ingrese allí, tendrá una opción para habilitar este protocolo OpenID Connect. Simplemente al habilitarlo, GAM comienza a almacenar una nueva propiedad que devuelve el Proveedor de Identidad llamado ID Token. El GAM lo almacena y lo pone a disposición para su uso. Si necesita realizar una solicitud a ese proveedor de identidad, puede utilizarlo. Sin embargo, para habilitar el 100% del protocolo, debe habilitar la validación, donde dice Validar token de identificación. El token de ID es un token web JSON firmado por el proveedor. Por esta razón, aquí debe confirmar quién es el proveedor del ID Token. Además, debe tener en su servidor local, en una ruta local del servidor, un certificado público de ese proveedor. De esta forma obtienes ese JSON Web Token que, entre otras cosas, tiene la información del usuario autenticado.
Contraseña de un solo uso (OTP)
Es un nuevo tipo de autenticación GAM, al igual que podrías configurar la autenticación con Google o Facebook.
Recuerde que una contraseña de un solo uso es una contraseña que se le proporciona y solo puede usarse una vez por un período corto de tiempo. Puedes elegir su longitud, si la clave generada está compuesta únicamente por números, o si quieres que sea alfanumérica.
Se puede seleccionar la vida útil del código generado automáticamente y muchas otras propiedades de seguridad.
Si está interesado en este método de autenticación, le sugiero que lea la contraseña de un solo uso (OTP) y la autenticación de dos factores (2FA).
Autenticación de dos factores
También se conoce como autenticación multifactor; en ambos casos, siempre se validarán dos factores.
Por lo general, primero se valida una contraseña. Los tenemos disponibles en todos los tipos de autenticación que no hacen una redirección para autenticarse, como Local, Personalizado, Servicio web externo y GAMRemoteRest.
Allí verás estas nuevas propiedades donde podrás habilitar esta funcionalidad. Luego elegirás el segundo tipo de autenticación que vas a utilizar. Serán los Tipos de Autenticación de Contraseña de Un Solo Uso que haya definido en este mismo GAM. Tú defines cómo quieres que se genere este segundo tipo de autenticación, y el tiempo que tendrá el usuario para validar los dos factores de autenticación. En este caso, si los usuarios superan los 900 segundos para validar los dos factores, tienen que volver a validar el primer factor.
Otra propiedad interesante es que puede seleccionar si obligar a todos los usuarios de su aplicación a realizar la autenticación de dos factores. Si no lo selecciona, cada usuario puede seleccionar si quiere usar este método de autenticación o no.
No te pierdas el vídeo 2FA, contraseña de un solo uso, OpenID: Todo sobre los nuevos esquemas de autenticación En él extiendo todos estos conceptos y doy consejos técnicos para que puedas desarrollar tus aplicaciones integradas entre sí y con todas las existentes. esquemas de autenticación. ¡Todo esto es posible con GeneXus 17!