Registro de aplicación OpenID Connect

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

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

FoxIDs admite OpenID Connect Discovery, para que su aplicación pueda descubrir el OpenID Provider.

FoxIDs admite OpenID Connect authentication, 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 cuadro de confirmación de logout según la configuración del cliente y si se incluye un ID token en la solicitud de logout.

De forma predeterminada, tanto el ID token como el access token usan el ID del cliente como audience. El recurso predeterminado puede eliminarse del access token en FoxIDs Control.

Los access tokens también pueden emitirse con varias audiences y así dirigirse a varias API definidas en FoxIDs como recursos OAuth 2.0. La aplicación puede entonces llamar a una API y proteger la solicitud con el access token según The OAuth 2.0 Authorization Framework: Bearer Token Usage.

FoxIDs admite tanto secretos de cliente como Proof Key for Code Exchange (PKCE), y PKCE está habilitado de forma predeterminada. Si un cliente está configurado con PKCE y un secret o key, ambos se validan. PKCE y el secret o key del cliente no se validan en el implicit flow.

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 hasta 10 secrets y 4 keys por cliente.

FoxIDs admite el endpoint OpenID Connect UserInfo endpoint.

Guías prácticas:

• Conectar Tailscale

Conectar entornos FoxIDs

• Environment Link para entornos en el mismo tenant.
• OpenID Connect para entornos en el mismo tenant o en tenants diferentes.

Requerir autenticación multi-factor (MFA)

El cliente OpenID Connect puede requerir MFA incluyendo urn:foxids:mfa en el parámetro acr_values. Puede combinarlo con valores más específicos como urn:foxids:link. Consulte solicitar MFA desde aplicaciones.

El parámetro acr_values puede establecerse en el evento OnRedirectToIdentityProvider en Startup.cs:

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

Vea más código en AspNetCoreOidcAuthorizationCodeSample y Startup.cs line 141.

Configuración

Así se configura su aplicación como un registro de aplicación OpenID Connect, Relying Party (RP) o cliente.

El documento discovery 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, el entorno environment-y y con el nombre de cliente application-client1.

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

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

Configurar Authorization Code flow para un cliente confidencial

Un cliente confidencial suele ser una aplicación web del lado del servidor donde el servidor web almacena el secret del cliente.

• Especifique el nombre del cliente en el nombre del registro de aplicación.
• Seleccione los métodos de autenticación permitidos.
• Especifique las URI de redirección.
• Especifique la URI de redirección posterior al logout.
• Seleccione code como response type o, opcionalmente pero no recomendado, code token o code token id_token.
• PKCE no es obligatorio para un cliente confidencial, pero se recomienda para reducir ataques de repetición.
• Especifique un secret.

Configurar Authorization Code flow para un cliente público

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

• Especifique el nombre del cliente en el nombre del registro de aplicación.
• Seleccione los métodos de autenticación permitidos.
• Especifique las URI de redirección.
• Especifique la URI de redirección posterior al logout.
• Seleccione code como response type.
• Use PKCE, que está habilitado de forma predeterminada.

Haga clic en Show advanced para configurar los CORS origins permitidos.

Configurar implicit flow para un cliente público

Un cliente público puede ser un rich client basado en navegador. La aplicación no usa ni PKCE ni secret de cliente.

No se recomienda usar el implicit flow porque es inseguro.

• Especifique el nombre del cliente en el nombre del registro de aplicación.
• Seleccione los métodos de autenticación permitidos.
• Especifique las URI de redirección.
• Especifique la URI de redirección posterior al logout.
• Seleccione token id_token como response type o, opcionalmente, solo token.
• Deshabilite PKCE.
• No especifique un secret.

Cliente y API

Es posible configurar tanto el cliente como la API, es decir, un OAuth 2.0 resource, en el mismo registro de aplicación OpenID Connect. En ese caso, tanto el cliente como la API se definen con el mismo nombre. También puede configurar resource scopes para la API.

Client tab

Resource tab

Resource y scopes

Una API se define como una resource y los scopes se definen bajo esa resource. Esos scopes usan el formato nombre-del-recurso más punto más 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 del recurso, los scopes se definen como una lista de valores de scope.

Los scopes configurados en el cliente se validan frente a los scopes que existen en la API. Si el cliente y la API están configurados en el mismo registro de aplicación, los scopes agregados al cliente se agregan automáticamente al recurso.

Scopes

Los scopes se pueden configurar en la pestaña de configuración del cliente. Puede definir nuevos scopes y el conjunto de claims que se deben emitir para esos scopes en la lista Voluntary claims.

Puede cambiar claims e implementar claim tasks con claim transforms y claim tasks.

Si está creando un nuevo claim, agregue el claim o * a la lista Issue claims, o agregue el claim a la lista Voluntary claims y solicite el scope desde su aplicación.

Se agrega un conjunto de scopes predeterminados a la configuración del cliente y luego puede cambiarse 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 renovando la sesión con refresh tokens hasta que se alcance la duración absoluta de 86.400 segundos.