Conceptos básicos de autenticación y autorización

La autenticación y la autorización juegan un papel importante en la mayoría de los conjuntos de aplicaciones. Esta página proporciona una descripción general de los conceptos y la terminología. Será útil si es nuevo en el tema o si desea refrescarse. Si está seguro de su comprensión general, puede pasar a aprender cómo funcionan la autenticación y la autorización en CXone.

Cuando los usuarios inician sesión en cualquier paquete de aplicaciones, incluidos CXone, estos dos pasos suelen ocurrir en el orden que se muestra:

  • Autenticación—¿Es el usuario quien dice ser?
  • Autorización—¿Debería el usuario autenticado tener el acceso que ha solicitado?

Todos los usuarios deben estar autenticados y autorizados antes de poder acceder CXone.

Los usuarios pueden ser personas o aplicaciones. Por ejemplo, los chatbots y los asistentes virtuales a menudo se ejecutan mediante una cuenta de usuario. La mayoría de los conjuntos de aplicaciones utilizan los mismos procesos para usuarios humanos y virtuales. En estas páginas de ayuda en línea sobre autenticación y autorización, hemos utilizado el términousuario para aplicar tanto a las personas como a las aplicaciones. Si hay diferencias, se explican claramente.

Desde el punto de vista del usuario, simplemente están iniciando sesión. La autenticación y la autorización ocurren detrás de escena para que su inicio de sesión sea exitoso. Al comienzo de un inicio de sesión, los usuarios no están autenticados. Esto significa que el sistema no conoce su identidad. Al final del inicio de sesión, ambos están autenticados y autorizados. Esto significa que el sistema sabe quiénes son y qué acceso deben tener.

Un sistema hace lo siguiente para autenticar y autorizar a los usuarios:

  1. Determina qué proceso de autenticación usar si se admite más de uno. Muchos sistemas admiten varios métodos. Por ejemplo, los sistemas pueden identificar a los usuarios con un nombre de usuario y contraseña, a través de inicio de sesión único, o a través autenticación multifactor (MFA). Generalmente, los usuarios eligen de una lista de opciones de autenticación en la página de inicio de sesión, pero los sistemas pueden requerir un proceso específico cuando sea necesario.

  2. Recopila credenciales de autenticación (por ejemplo, solicitando a los usuarios su nombre de usuario y contraseña).

  3. Verifica las credenciales mediante un proveedor de identidad. Un proveedor de identidad es un sistema independiente que mantiene información sobre los usuarios y su identidad, incluidas sus credenciales.

  4. Autoriza al individuo o programa autenticado. Una vez que los usuarios están autenticados, el sistema utiliza un servidor de autorización para otorgar acceso al usuario. El sistema otorga acceso al usuario en función de su rol y permisos. El sistema solo otorga al usuario acceso a las funciones para las que tiene permiso de ver o usar.

Terminología relacionada con la autenticación

Proveedor de identidad

Los proveedores de identidad (IdP) son sistemas que establecen la identidad de un usuario. Opciones:

  • Interno: parte del sistema en el que el usuario inicia sesión. Por ejemplo, un usuario que inicia sesión en Facebook utiliza el IdP de Facebook para autenticarse en la aplicación de Facebook.
  • Externo—Separado del sistema en el que el usuario inicia sesión. Por ejemplo, un usuario inicia sesión en una aplicación de teléfono inteligente mediante la autenticación de IdP de Facebook.

Los IdP pueden estar alojados o basados en la nube. Microsoft ADFS y Shibboleth son IdP alojados comunes. Microsoft Azure AD Okta y Ping se encuentran entre los muchos IdP en la nube.

Protocolos de autenticación

Los protocolos de autenticación establecen la comunicación entre las aplicaciones y los IdP, o entre diferentes IdP. OpenID Connect y SAML 2.0 son ejemplos de protocolos de autenticación. Algunos protocolos de autenticación ofrecen funciones adicionales, como el cifrado, pero las aplicaciones pueden o no usar estas funciones. Cuando un sistema utiliza un IdP integrado, los protocolos de autenticación no se tienen en cuenta.

Flujo de autenticación

La mayoría de los IdP externos admiten uno o ambos de los siguientes flujos para el proceso de autenticación:

  • Iniciado por SP: La autenticación la inicia el proveedor de servicios o la aplicación. El usuario ingresa las credenciales y la aplicación se comunica con un IdP externo para verificar la identidad. Este es el flujo más común.
  • iniciado por IdP: Los usuarios inician sesión en el IdP primero y luego el IdP inicia aplicaciones después de verificar al usuario.

Administración de identidad federada

La gestión de identidad federada a veces se denomina FIM o federación. Es un término genérico para el proceso de usar un único IdP externo para proporcionar autenticación para una o más aplicaciones. La federación generalmente tiene un límite de tiempo de alguna manera. Por ejemplo, un usuario puede iniciar sesión una vez cuando comienza a trabajar. Esto los autentica en todas las aplicaciones que usan cada día. Sin embargo, tendrían que volver a iniciar sesión al día siguiente para volver a autenticarse, incluso si no cerraron la sesión el día anterior.

Inicio de sesión único

El inicio de sesión único (SSO) se utiliza para proporcionar acceso a varias aplicaciones o sistemas en función de un inicio de sesión. Por ejemplo, un usuario inicia sesión en Microsoft 365 y obtiene acceso a todas las aplicaciones de Microsoft que su empresa ha autorizado para él. A veces, el término SSO se usa para federación, aunque los dos conceptos no son exactamente iguales.

Autenticación de factores múltiples

La autenticación multifactor (MFA) agrega otro nivel de seguridad a la autenticación básica de nombre de usuario/contraseña. MFA requiere que el usuario ingrese un código, responda una pregunta o use un token antes de que el IdP considere que su identidad está verificada.

Confianza

En la autenticación, la confianza se refiere a la información o el conocimiento compartido por una aplicación o sistema y un IdP externo. Este conocimiento establece una relación entre los dos para que cada uno sepa que puede confiar en la comunicación precisa y veraz del otro. La forma en que se establece la confianza difiere según el protocolo de autenticación. Los siguientes ejemplos se basan en OpenID Connect y SAML 2.0.

OpenID Connect

Confiar en OpenID Connect se basa en el emisor. Un emisor es un valor que parece una URL. Establece su proveedor de identidad. Por ejemplo, Google admite OpenID Connect y el emisor es https://accounts.google.com.

Según el emisor, hay varios elementos de configuración adicionales. por ejemplo, en OpenID Connect la confianza se establece mediante la firma de certificados públicos/privados. Utiliza un estándar de la industria llamado JWKS. Por lo tanto, parte de la configuración determina cómo se obtienen estos certificados públicos.

La mayoría de los proveedores de identidad admiten el descubrimiento de esta información agregando /.well-known/openid-configuration al emisor. El documento de descubrimiento de Google se encuentra en https://accounts.google.com/.well-known/openid-configuration.

SAML 2.0

En SAML 2.0, la confianza se basa en un identificador de entidad. A diferencia de OpenID Connect, no existe una relación fuerte entre el identificador de entidad y otros valores de configuración. Hay varios parámetros de configuración que se utilizan para establecer la confianza con SAML 2.0:

  • Identificador de entidad—Valor establecido por la aplicación o sistema para verificar su identidad

  • URL de punto final—Valor determinado por el IdP externo en el que recibe las solicitudes de autenticación

  • URL de afirmación—Valor determinado por la aplicación o el sistema al que el IdP externo envía respuestas de autenticación

  • Certificado—Usado por el IdP externo para firmar la respuesta