Explorando la configuración de OpenID Connect: Campos clave y sus usos

En el mundo digital de hoy, la autenticación se ha convertido en un componente central para asegurar sitios web y aplicaciones. OpenID Connect (OIDC), una capa de autenticación construida sobre el protocolo OAuth 2.0, ofrece una forma estandarizada y sencilla de autenticar identidades.

Sin embargo, integrar correctamente OIDC puede ser desalentador, especialmente para los recién llegados. Un buen punto de partida suele ser el archivo de configuración de OIDC, que generalmente se encuentra en la URL {authServerUrl}/.well-known/openid-configuration, y que contiene todos los detalles necesarios para implementar servicios OIDC.

Esta guía tiene como objetivo aclarar los campos clave dentro de esta configuración, ayudando a los desarrolladores a comprender su importancia y aplicaciones prácticas para integrar mejor OIDC en sus proyectos.

Analizando los campos de configuración de OIDC#

La configuración de OIDC es un archivo JSON similar al siguiente:

A continuación, profundizaremos en algunos de los campos clave.

authorization_endpoint#

Cuando se integran servicios OIDC, el primer paso generalmente implica manejar las solicitudes de inicio de sesión de los usuarios dentro de la aplicación. Este proceso incluye redirigir a los usuarios al authorization_endpoint del servidor de autorización. Este endpoint es la dirección del servidor donde se envían las solicitudes de autorización, guiando a los usuarios a la página de inicio de sesión para la autenticación.

Al realizar una solicitud al authorization_endpoint, se debe configurar con parámetros adicionales de consulta para cada autorización:

• response_type: Especifica el tipo de autorización devuelta. Esto típicamente incluye "code" (para el flujo de código de autorización), "token" (para el flujo implícito), y "id_token token" o "code id_token" (para el flujo híbrido), que se puede encontrar en el campo response_types_supported de la configuración OIDC.
• client_id: Un identificador único asignado a la aplicación por el servidor de autorización cuando la aplicación se registra. Este ID es utilizado por el servidor de autorización para reconocer la solicitud iniciada por la aplicación cliente.
• scope: Define el alcance del acceso solicitado, especificando los recursos o información del usuario a los que se podrá acceder. Los ámbitos comunes incluyen "openid" (obligatorio), "profile" y "email", entre otros. Puede encontrar los ámbitos compatibles en el campo scopes_supported de la configuración OIDC; los diferentes ámbitos deben separarse por espacios.
• redirect_uri: Después del inicio de sesión o la autorización, el servidor de autorización redirige al usuario de vuelta a la URI proporcionada por la aplicación. Esta URI debe coincidir exactamente con la URI proporcionada durante el registro de la aplicación.
• state: Una cadena generada aleatoriamente que se utiliza para proteger al cliente de ataques de falsificación de solicitudes entre sitios. Se debe mantener la consistencia del estado entre la solicitud de autorización y la devolución de llamada para garantizar la seguridad.

Estos parámetros permiten a los desarrolladores controlar con precisión el comportamiento de las solicitudes de autorización OIDC, asegurando que sean seguras y cumplan con las necesidades de la aplicación.

Después de completar la solicitud al authorization_endpoint y pasar por la autenticación, los usuarios son redirigidos al redirect_uri especificado, que incluirá un parámetro de consulta muy crucial—code. Este código de autorización es proporcionado por el servidor de autorización y es el resultado de que el usuario ha autenticado y autorizado a la aplicación para que acceda a su información en el servidor de autorización.

token_endpoint#

token_endpoint es el endpoint del servidor utilizado por el servidor de autorización para intercambiar el código de autorización mencionado anteriormente por tokens de acceso y de refresco. En el flujo de código de autorización OAuth 2.0, este paso es crucial ya que implica convertir el código de autorización obtenido en tokens de acceso reales, que la aplicación puede utilizar para acceder a los recursos protegidos del usuario.

A continuación, se muestra cómo se implementa el intercambio del código de autorización por tokens de acceso (tenga en cuenta que este ejemplo utiliza el método de autenticación client_secret_post. Para otros métodos de autenticación compatibles, consulte el análisis posterior del campo

):

En este código, primero enviamos una solicitud al token_endpoint utilizando el método POST. El tipo de contenido se establece como application/x-www-form-urlencoded, que es requerido por la mayoría de los servidores de autorización. El cuerpo de la solicitud incluye los siguientes parámetros:

• code: El código de autorización obtenido del servidor de autorización, que se devuelve a través del redirectUri después de que el usuario complete la autorización.
• redirect_uri: La misma URI de redirección utilizada para obtener el código de autorización, utilizada para verificar la legitimidad de la solicitud.
• client_id: El identificador del cliente de la aplicación, utilizado para identificar la aplicación que realiza la solicitud.
• client_secret: El secreto del cliente de la aplicación, utilizado para verificar la identidad de la aplicación.
• grant_type: Especifica el tipo de autorización, utilizando aquí "authorization_code", lo que indica que el token de acceso se obtiene a través del código de autorización.

Esta función se ejecuta de forma asíncrona y devuelve un objeto JSON que contiene el token de acceso, que la aplicación puede utilizar para solicitar datos del usuario o realizar otras operaciones.

userinfo_endpoint#

userinfo_endpoint es el endpoint del servidor utilizado por el servidor de autorización para obtener información detallada sobre los usuarios autenticados. Después de que los usuarios autoricen con éxito y obtengan tokens de acceso a través del token_endpoint, la aplicación puede solicitar este endpoint para acceder a la información del perfil del usuario, como el nombre de usuario y la dirección de correo electrónico. La información específica obtenida depende del scope especificado por el usuario en la solicitud de autenticación.

En esta función, primero utilizamos el método GET para solicitar el userinfo_endpoint, incluyendo el campo Authorization en el encabezado de la solicitud compuesto por el token_type y el accessToken. Esto es una operación estándar según la especificación de OAuth 2.0, asegurando la obtención segura de la información del usuario. Además, el alcance de la información del usuario a la que se accede a través del token de acceso depende completamente de los valores del parámetro scope adoptados por el usuario durante la iniciación de la autorización. Por ejemplo, si se utiliza el scope email, la respuesta debería incluir la dirección de correo electrónico del usuario.

issuer & jwks_uri#

El issuer identifica la URL del servidor de autorización, mientras que el jwks_uri proporciona la URI para el JSON Web Key Set (JWKS), que es un conjunto de claves públicas utilizadas para verificar las firmas de JWT. Verificar el issuer y la firma del JWT son pasos básicos para garantizar la seguridad del token, pero en escenarios reales el proceso de verificación generalmente también incluye comprobar el periodo de validez del token, la audiencia, el scope de autorización y otros campos importantes.

El siguiente código principalmente muestra cómo utilizar el issuer y el jwks_uri juntos para verificar un JWT:

scopes_supported & claims_supported#

Los campos claims_supported y scopes_supported declaran los atributos del usuario (claims) y los ámbitos de acceso (scopes) soportados por el servidor de autorización. Ayudan a los clientes a entender qué atributos del usuario y qué ámbitos de acceso son soportados por el servidor de autorización, permitiendo a los clientes construir solicitudes de autorización y analizar respuestas de manera efectiva.

Al construir una solicitud de autorización, los clientes pueden especificar el scope necesario basado en las necesidades de la aplicación. El Scope define los recursos y las operaciones a los que el cliente solicita acceso, como openid, email, profile, y otros.

Es importante tener en cuenta que los claims específicos accesibles en cada solicitud de autorización varían según los valores del scope especificados al inicio de la solicitud de autenticación. Por ejemplo, el scope de email otorga acceso a la dirección de correo electrónico del usuario, mientras que el scope de phone proporciona acceso a su número de teléfono. Por lo tanto, los clientes deben elegir cuidadosamente el scope relevante según las necesidades de la aplicación al redactar una solicitud de autorización, asegurando que puedan recuperar los atributos del usuario necesarios:

token_endpoint_auth_methods_supported

#

El campo

indica los métodos de autenticación soportados por el endpoint de token. Estos métodos son utilizados por el cliente para autenticarse con el servidor de autorización al intercambiar el código de autorización por tokens de acceso.

Al autenticarse utilizando el endpoint de token, los métodos de autenticación comunes incluyen client_secret_post, client_secret_basic, y client_secret_jwt.

• client_secret_post: El cliente utiliza su identificador de cliente y su secreto para construir un cuerpo codificado en un formulario, que se envía como parte del cuerpo de la solicitud. Ya hemos visto un ejemplo de este método en la sección token_endpoint anterior.

• client_secret_basic: El cliente utiliza su identificador de cliente y su secreto para construir un encabezado de autenticación básica, que se agrega al encabezado de la solicitud.

• client_secret_jwt: El cliente utiliza un JWT (JSON Web Token) como una afirmación de cliente para autenticarse. Este JWT contiene el identificador de cliente y algunos metadatos adicionales y está firmado usando el secreto del cliente. Después de recibir la solicitud, el servidor de autorización verifica la identidad del cliente validando la firma del JWT.

En aplicaciones prácticas, los clientes necesitan seleccionar el método de autenticación apropiado basado en los métodos soportados por el servidor de autorización, y asegurar que la información de autenticación se agregue correctamente a la solicitud para intercambiar de forma segura el código de autorización por tokens de acceso.

Resumen#

Ahora hemos explorado los campos clave en la configuración de OIDC, enfocándonos en sus propósitos y aplicaciones. Comprender estos detalles mejorará tu entendimiento de OpenID Connect, capacitándote para integrarlo y utilizarlo de manera más efectiva en tus proyectos. Armado con este conocimiento, estás mejor preparado para aprovechar el potencial completo de OIDC para soluciones de autenticación de usuarios más seguras y eficientes.

Logto, como un servicio de autenticación construido sobre OIDC, que ofrece una suite completa de SDKs en varios lenguajes junto con numerosos tutoriales de integración, te permite integrar de manera fluida inicios de sesión OAuth / OIDC en tus aplicaciones en solo minutos. Si buscas un servicio OIDC confiable y fácil de usar, prueba Logto hoy mismo!