Saltar al contenido principal
En esta sección, veremos la solución que estamos implementando, incluidos los detalles sobre la gestión de identidades, los protocolos que se deben usar y el flujo de autenticación necesario.

​
Gestión de identidades

ExampleCo decidió usar Auth0 como su proveedor de Identity as a Service (IDaaS). El motivo de esta decisión fue que la empresa no quería destinar recursos a la capacitación, la implementación y el mantenimiento de la gestión de identidades y accesos. Además, planea ampliar esta solución en el futuro, posiblemente añadiendo una aplicación móvil nativa y una API para enviar registros de horas aprobados a sus sistemas internos. Auth0 ofrece la flexibilidad necesaria para incorporar esos cambios en su arquitectura con un esfuerzo mínimo.
Identity-as-a-Service (“IDaaS”) es un servicio en la nube para la gestión de identidades y accesos. Los servicios que ofrece suelen incluir inicio de sesión único (SSO), identidad federada, gestión de contraseñas y más.

​
Qué protocolo usar

La siguiente decisión tiene que ver con qué protocolo utilizar, con  Connect (OIDC) o .
Auth0 implementa protocolos de identidad probados, comunes y populares, tanto para productos web orientados al consumidor (OAuth 2.0, OAuth 1.0, OpenID) como para entornos empresariales (SAML, WS-Federation, LDAP). Tiene total libertad para usar el que mejor se adapte a las necesidades de su negocio.
OpenID Connect es un protocolo de autenticación basado en la familia de especificaciones de OAuth 2.0. Utiliza () JSON simples que se entregan a través del protocolo OAuth 2.0.

​
OAuth frente a OpenID Connect (OIDC)

OAuth 2.0 y OpenID Connect (OIDC) suelen confundirse como si fueran lo mismo, pero no es así. OAuth 2.0 es un protocolo que le permite autorizar a un sitio web (el consumidor o la aplicación) a acceder a sus datos desde otro sitio web (el servidor de recursos o proveedor). Por ejemplo, quiere autorizar a un sitio web a acceder a algunos archivos de su cuenta de Dropbox. El sitio web le redirigirá a Dropbox, que le preguntará si debe conceder acceso a sus archivos. Si acepta, el sitio web quedará autorizado para acceder a sus archivos de Dropbox. En esencia, OAuth 2.0 trata del acceso y del uso compartido de recursos. OpenID Connect, por otro lado, es una sencilla capa de identidad construida sobre el protocolo OAuth 2.0. Le ofrece un único inicio de sesión para varios sitios. Cada vez que necesite iniciar sesión en un sitio web mediante OIDC, se le redirigirá a su sitio de OpenID, donde iniciará sesión, y luego volverá al sitio web. En esencia, OIDC se centra en la autenticación del usuario.
SAML es un protocolo basado en XML que proporciona tanto autenticación como autorización entre partes de confianza. En comparación con SAML, OpenID Connect es más ligero y más fácil de gestionar. SAML está probado, es potente y flexible, pero para los requisitos de esta aplicación, esa flexibilidad y potencia no son necesarias. La federación de identidades (una de las razones más convincentes para adoptar SAML) tampoco es necesaria aquí. Y si alguna vez llegara a ser un requisito, Auth0 puede gestionarlo fácilmente, del mismo modo que maneja AD (que usa LDAP). Por estas razones, ExampleCo usará OpenID Connect para su implementación.

​
Flujo de autenticación

OpenID Connect admite más de un flujo de autenticación. Dado que en nuestro caso se trata de una aplicación web tradicional, usaremos el Flujo de código de autorización. El flujo es el siguiente:
  1. La aplicación web (denominada cliente en términos de OIDC) inicia la solicitud de autenticación redirigiendo el user-agent (navegador) a Auth0 (el Servidor de autorización en términos de OIDC).
  2. Auth0 autentica al usuario (a través del user-agent). La primera vez que el usuario pase por este flujo, se mostrará una página de consent en la que se enumeran los permisos que se concederán a la aplicación (por ejemplo, publicar mensajes o listar contactos). El usuario inicia sesión en el servicio (a menos que ya haya iniciado sesión) y autoriza el acceso de la aplicación.
  3. Si el usuario concede acceso, Auth0 redirige el user-agent de vuelta a la aplicación junto con un código de autorización en la cadena de consulta.
  4. La aplicación envía el código de autorización a Auth0, junto con las credenciales de la aplicación (client_id y client_secret), y solicita un token.
  5. Auth0 autentica la aplicación (mediante client_id y client_secret) y valida el código de autorización. Si es válido, Auth0 responde con un ID Token.
undefined

​
Modo de respuesta Form Post

Otra opción es usar OAuth 2.0 Form Post Response Mode con response_type=id_token&response_mode=form_post. Debido al parámetro de solicitud response_type=id_token, la respuesta contiene el ID Token directamente, en lugar del código de autorización, mientras que response_mode=form_post codifica el ID Token, junto con el resto de los parámetros de la Authorization Response, como valores de formulario HTML que se envían automáticamente en el User Agent. De esta manera, puede tener un flujo de autenticación optimizado (sin necesidad de intercambiar el código por un ID Token); sin embargo, debe asegurarse de que la tecnología que está usando para implementar la aplicación lo admita (el middleware de ASP.NET Core sí lo admite). Para obtener más detalles, consulte la especificación de OAuth 2.0 Form Post Response Mode.
El ID Token (normalmente denominado id_token en ejemplos de código) es un JSON Web Token (JWT) que contiene datos de identidad. La aplicación lo consume y se usa para obtener información del usuario, como su nombre, correo electrónico, etc., normalmente para mostrarla en la interfaz de usuario.

​
Más sobre los tokens

Los tokens son cadenas alfanuméricas que se usan en la autenticación basada en tokens. Permiten que los usuarios se autentiquen una vez con un username y una contraseña, y reciban a cambio un token que pueden usar a partir de ese momento. Tienen una duración limitada.Los JSON Web Tokens (JWTs) son tokens que cumplen con el estándar JSON Web Token y contienen información sobre una identidad en forma de claim. Son autocontenidos, en el sentido de que no es necesario que el receptor llame a un servidor para validar el token. Los JWT se pueden firmar usando un secreto (con el algoritmo HMAC) o un par de claves pública/privada mediante RSA. Puede encontrar más información sobre JWT aquí.El ID Token, que es un JWT, cumple con un estándar del sector (IETF RFC 7519) y contiene tres partes: un encabezado, un cuerpo y una firma.
  • El encabezado contiene el tipo de token y el algoritmo hash usado en el contenido del token.
  • El cuerpo, también llamado carga útil, contiene claims de identidad sobre un usuario. Hay algunos claims con nombres registrados para elementos como el emisor del token, el sujeto del token (sobre quién tratan los claims) y el momento de emisión. Se puede agregar cualquier cantidad de claims adicionales con otros nombres, aunque se debe tener cuidado de mantener el JWT dentro de las limitaciones de tamaño de las URL del navegador.
  • La firma la utiliza el receptor de un JWT para validar la integridad de la información transmitida en el JWT.

​
Cómo validar un ID Token

La validación de un ID Token requiere varios pasos:
  1. Si el ID Token está cifrado, descífrelo con las claves y los algoritmos que especificó la aplicación.
  2. El identificador del emisor del proveedor de OpenID debe coincidir con el valor del claim iss (emisor).
  3. El claim aud (audiencia) debe contener el valor client_id de la aplicación. El ID Token debe rechazarse si no incluye a la aplicación como una audiencia válida o si contiene audiencias adicionales en las que la aplicación no confía.
  4. Si el ID Token contiene varias audiencias, la aplicación debe verificar que haya un claim azp.
  5. Si hay un claim azp (parte autorizada), la aplicación debe verificar que su client_id coincida con el valor del claim.
  6. La aplicación debe validar la firma de los ID Token de acuerdo con JWS, mediante el algoritmo especificado en el parámetro de encabezado JWT alg. La aplicación debe usar las claves proporcionadas por el emisor.
  7. El valor de alg debe ser el valor predeterminado RS256 o el algoritmo enviado por la aplicación en el parámetro id_token_signed_response_alg durante el registro.
  8. Si el parámetro de encabezado JWT alg usa un algoritmo basado en MAC, como HS256, HS384 o HS512, los octetos de la representación UTF-8 de client_secret correspondiente al client_id contenido en el claim aud (audiencia) se usan como clave para validar la firma. En el caso de algoritmos basados en MAC, el comportamiento no está especificado si aud tiene varios valores o si hay un valor azp distinto del valor de aud.
  9. La hora actual debe ser anterior a la hora representada por el claim exp.
  10. El claim iat puede usarse para rechazar tokens que se emitieron con demasiada diferencia respecto de la hora actual, lo que limita el tiempo durante el cual es necesario almacenar valores nonce para evitar ataques. El rango aceptable depende de la aplicación.
  11. Si se envió un valor nonce en la solicitud de autenticación, debe haber un claim nonce y se debe comprobar su valor para verificar que sea el mismo que se envió en la solicitud de autenticación. La aplicación debe comprobar el valor nonce para detectar ataques de repetición. El método preciso para detectar ataques de repetición depende de la aplicación.
  12. Si se solicitó el claim acr, la aplicación debe comprobar que el valor del claim declarado sea adecuado.
  13. Si se solicitó el claim auth_time, ya sea mediante una solicitud específica de este claim o usando el parámetro max_age, la aplicación debe comprobar el valor del claim auth_time y solicitar reautenticación si determina que ha transcurrido demasiado tiempo desde la última autenticación del usuario final.
Si almacena ID Token en su servidor, debe hacerlo de forma segura.