Registro de aplicación OpenID Connect

El registro de aplicación OpenID Connect de FoxIDs te permite conectar una aplicación basada en OpenID Connect.

Tu aplicación se convierte en un Relying Party (RP) y FoxIDs actúa como OpenID Provider (OP).

FoxIDs admite OpenID Connect Discovery donde tu aplicación puede descubrir el OpenID Provider.

FoxIDs admite autenticación OpenID Connect (login), RP-initiated logout y front-channel logout. Se establece una sesión cuando el usuario se autentica y el identificador de sesión se incluye en el ID token. La sesión se invalida al cerrar sesión.
FoxIDs puede mostrar un diálogo de confirmación de logout según la configuración y según si se incluye o no un ID token en la solicitud de logout.

Por defecto, tanto el ID token como el access token se emiten con el client id del cliente como audiencia. El recurso predeterminado puede eliminarse del access token en FoxIDs Control. Los access tokens pueden emitirse con una lista de audiencias y así emitirse para múltiples APIs definidas en FoxIDs como recursos OAuth 2.0.
La aplicación puede entonces llamar a una API asegurando la llamada con el access token usando The OAuth 2.0 Authorization Framework: Bearer Token Usage.

FoxIDs admite tanto client secret como Proof Key for Code Exchange (PKCE), y requiere PKCE por defecto. Si un cliente está configurado con PKCE y un secreto o clave, ambos se validarán. PKCE y el secreto o la clave de cliente no se validan en el flujo implícito.

El método de autenticación de cliente predeterminado es client secret post y puede cambiarse a client secret basic o private key JWT. El método de autenticación de cliente none es compatible con PKCE.

Se pueden configurar como máximo 10 secretos y 4 claves por cliente.

FoxIDs admite el endpoint UserInfo OpenID Connect.

Guías prácticas:

• Conectar dos entornos FoxIDs en el mismo tenant o en tenants diferentes con OpenID Connect
• Conectar dos entornos FoxIDs en el mismo tenant con un Environment Link

Se recomienda usar el flujo OpenID Connect Authorization Code con PKCE, ya que se considera un flujo seguro.

Requerir autenticación multifactor (MFA)

El cliente OpenID Connect puede requerir autenticación multifactor especificando el valor urn:foxids:mfa en el parámetro AcrValues.

El parámetro AcrValues se puede establecer en el evento OnRedirectToIdentityProvider en Startup.cs:

options.Events.OnRedirectToIdentityProvider = (context) =>
{
    // Para requerir MFA
    context.ProtocolMessage.AcrValues = "urn:foxids:mfa";
    return Task.FromResult(string.Empty);
};

Consulta más código en AspNetCoreOidcAuthorizationCodeSample y Startup.cs línea 141.

Configuración

Cómo configurar tu aplicación como un cliente / Relaying Party (RP) en el registro de aplicación OpenID Connect.

El documento de descubrimiento de FoxIDs del cliente es https://foxids.com/tenant-x/environment-y/application-client1/.well-known/openid-configuration
si el cliente está configurado en el tenant tenant-x y el entorno environment-y con el nombre de cliente de registro de aplicación application-client1.

Un cliente de registro de aplicación puede admitir inicio de sesión mediante varios métodos de autenticación añadiendo el nombre del método de autenticación a la URL.
Un nombre de método de autenticación, por ejemplo login, puede añadirse a la URL de descubrimiento así https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration

Durante el RP-initiated logout el nombre del método de autenticación puede omitirse en la URL si se proporciona el ID Token en la solicitud.

Configurar el flujo Authorization Code para un cliente confidencial

Un cliente confidencial puede ser una aplicación web donde la seguridad es gestionada por el servidor web que también almacena el client secret.

• Especifica el nombre del cliente en el nombre del registro de la aplicación.
• Selecciona los métodos de autenticación permitidos.
• Especifica las URI de redirección.
• Especifica la URI de redirección post logout.
• Selecciona code como tipo de respuesta o, posible pero no recomendado, code token o code token id_token.
• No es obligatorio usar PKCE en un cliente confidencial, pero se recomienda para mitigar ataques de repetición.
• Especifica un secreto.

Configurar el flujo Authorization Code para un cliente público

Un cliente público puede ser un cliente rico basado en navegador, un cliente Blazor o una app móvil. La aplicación debe usar PKCE y no un client secret.

• Especifica el nombre del cliente en el nombre del registro de la aplicación.
• Selecciona los métodos de autenticación permitidos.
• Especifica las URI de redirección.
• Especifica la URI de redirección post logout.
• Selecciona code como tipo de respuesta.
• Usa PKCE, habilitado por defecto.

Haz clic en "Show advanced" para configurar los orígenes CORS permitidos.

Configurar el flujo Implicit Code para un cliente público

Un cliente público puede ser una aplicación web donde la seguridad es gestionada por el servidor web o un cliente rico basado en navegador. La aplicación no usa ni PKCE ni client secret.
No se recomienda usar el flujo Implicit Code porque es inseguro.

• Especifica el nombre del cliente en el nombre del registro de la aplicación.
• Selecciona los métodos de autenticación permitidos.
• Especifica las URI de redirección.
• Especifica la URI de redirección post logout.
• Selecciona token id_token como tipo de respuesta o solo token si es posible.
• Deshabilita PKCE.
• No especifiques un secreto.

Cliente y API

Es posible configurar tanto el cliente como la API (recurso OAuth 2.0) en la misma configuración de registro de aplicación OpenID Connect, donde tanto el cliente como la API se definen con el mismo nombre. Además, es posible configurar los scopes de recurso para la API.

Pestaña Client

Pestaña Resource

Recurso y scopes

Una API se define como un recurso bajo el cual es posible definir scopes. Estos scopes se definen como nombre de recurso punto scope, por ejemplo application-api1.read1 o application-api1.read2.

En la pestaña de configuración del cliente, los scopes se definen debajo del campo de nombre del recurso.

En la pestaña de configuración de recursos, los scopes se definen como una lista de valores de scope.

Los scopes configurados en el cliente se validan si existen en la API. Si el cliente y la API están configurados en la misma configuración de registro de aplicación, los scopes añadidos al cliente se agregan automáticamente al recurso.

Scopes

Los scopes pueden configurarse en la pestaña de configuración del cliente. Es posible definir nuevos scopes y un conjunto de reclamaciones que deben emitirse para los scopes en la lista Voluntary claims.

Puedes cambiar las reclamaciones y realizar tareas de reclamaciones con transformaciones de reclamaciones y tareas de reclamaciones.

Si estás creando una nueva reclamación, añade la reclamación o * a la lista Issue claims o añade la reclamación a la lista Voluntary claims y solicita el scope desde tu aplicación.

Un conjunto de scopes predeterminados se añade a la configuración del cliente y luego puede modificarse o eliminarse.

Duración del token

La duración del token se configura para el ID token, el access token y el refresh token.

En este ejemplo, cada refresh token es válido durante 36 000 segundos. La aplicación puede seguir actualizando la sesión con refresh tokens hasta alcanzar la duración de vida absoluta de 86 400 segundos.