Registro de aplicación OpenID Connect
Un registro de aplicación OpenID Connect de FoxIDs permite que una aplicación web, de página única o nativa autentique usuarios mediante FoxIDs y reciba tokens de ID y de acceso. La aplicación es el Relying Party (RP) y FoxIDs es el OpenID Provider (OP).
Entre las principales capacidades de OpenID Connect se incluyen discovery, Authorization Code Flow, PKCE, secretos y claves de cliente, el endpoint UserInfo, el cierre de sesión iniciado por el RP y front-channel logout.
Configuración
En FoxIDs Control:
- Seleccione el entorno en el que debe registrarse la aplicación.
- Abra Applications y haga clic en Add application.
- Elija Web Application, Single Page Application o Native Application. Estas tres opciones de OpenID Connect se muestran sin activar Show all options.
- Introduzca un nombre y una URI de redirección, revise la información generada de la aplicación y haga clic en Create.
- Copie cualquier secreto generado antes de cerrar el resultado de creación. Un secreto generado solo se muestra durante la creación.
Después de crearla, haga clic en Change application para revisar o modificar toda la configuración. La tarjeta del tipo de aplicación proporciona una configuración inicial adecuada; el cliente OpenID Connect resultante puede ajustarse posteriormente.
Aplicación web (cliente confidencial)
Elija Web Application para una aplicación que se ejecute en un servidor, como una aplicación ASP.NET Core, Node.js, Java o PHP. Se crea como cliente confidencial con:
- Authorization Code Flow con el response type
code. - Un secreto de cliente generado.
- PKCE desactivado de forma predeterminada. Active Require PKCE después de la creación cuando la aplicación admita PKCE. Se recomienda como protección adicional del código de autorización.
Introduzca la URL base o de callback de la aplicación como Redirect URI. Active Show advanced durante la creación solo si necesita elegir el ID de cliente o configurar la coincidencia exacta de la URL de redirección.
Aplicación de página única (cliente público)
Elija Single Page Application para una aplicación que se ejecute en el navegador, como React, Angular, Vue o Blazor WebAssembly. Se crea como cliente público con:
- Authorization Code Flow con el response type
code. - PKCE activado de forma predeterminada.
- Sin secreto de cliente.
- El origen de la URL de redirección añadido como origen CORS permitido.
Aplicación nativa (cliente público)
Elija Native Application para una aplicación móvil o de escritorio instalada, como iOS, Android, React Native, .NET MAUI o Ionic. Se crea como cliente público con Authorization Code Flow, PKCE activado de forma predeterminada y sin secreto de cliente.
La URI de redirección puede usar un esquema específico de la aplicación, como myapp://callback, o una URI HTTPS compatible con la aplicación.
URI de redirección y valores absolutos
De forma predeterminada, Absolute URIs está desactivado para aplicaciones web y de página única. La URL de redirección configurada se trata entonces como un valor base y se aceptan las URL de redirección que comiencen por ese valor.
Active Show advanced y Absolute URIs si conoce la URL exacta de la aplicación a la que se debe redirigir al usuario después de iniciar sesión. Introduzca esa URL exacta como Redirect URI. La misma opción admite URI exactas específicas de aplicaciones nativas.
Después de la creación, las URI de redirección, la URI de redirección posterior al cierre de sesión y los orígenes CORS permitidos se pueden modificar en la pestaña OpenID Connect Client. Mantenga Show advanced desactivado salvo que la opción necesaria sea avanzada.
Implicit Flow
Implicit Flow se mantiene por compatibilidad, pero no se recomienda para aplicaciones nuevas. Es preferible Authorization Code Flow con PKCE.
Para configurar un cliente público existente para Implicit Flow, haga clic en Change application, active Show advanced, cambie Response types a token id_token u opcionalmente solo token y desactive Require PKCE. Los response types pueden modificarse en las mismas opciones avanzadas del cliente cuando se requiera otra combinación compatible.
Endpoints de la aplicación y seguridad del cliente
La información de la aplicación en FoxIDs Control incluye la authority, el ID de cliente, el endpoint discovery, el endpoint authorize y el endpoint de token. Un documento discovery de OpenID Connect tiene esta forma:
https://foxids.com/tenant-x/environment-y/application-client1(*)/.well-known/openid-configuration
Una aplicación puede permitir el inicio de sesión mediante varios métodos de autenticación. Si un método de autenticación define perfiles, el método base y cada perfil pueden seleccionarse de forma independiente. Para seleccionar un método de autenticación en la URL de authority, añada su nombre al segmento de la aplicación:
https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration
Durante el cierre de sesión iniciado por el RP, el nombre del método de autenticación puede omitirse cuando el token de ID se incluye en la solicitud.
Issuer específico de la aplicación
De forma predeterminada, los tokens emitidos para la aplicación usan el issuer del entorno:
https://foxids.com/tenant-x/environment-y/
Para que el issuer coincida con la authority de la aplicación, haga clic en Change application, active Show advanced y habilite Use matching issuer and authority with application specific issuer. El issuer pasa a ser:
https://foxids.com/tenant-x/environment-y/application-client1(*)
El issuer específico de la aplicación cambia cuando cambian los métodos de autenticación seleccionados en la URL de authority. Para las API, el issuer depende por tanto de la aplicación que realiza la llamada. Token exchange solo es posible entre configuraciones con métodos de autenticación correspondientes.
Seguridad del cliente
Los clientes públicos, incluidas las aplicaciones de página única y nativas, no pueden almacenar credenciales de cliente de forma segura. Configúrelos sin secreto de cliente y use Authorization Code Flow con PKCE.
Los clientes confidenciales se autentican en el endpoint de token. El método predeterminado de autenticación de cliente es client secret post. Active Show advanced para cambiarlo a client secret basic o private key JWT. PKCE también se recomienda cuando el cliente confidencial lo admita. Si se configuran tanto PKCE como un secreto o una clave de cliente, FoxIDs valida ambos.
El método de autenticación de cliente none es compatible con PKCE. Se pueden configurar hasta 10 secretos y 4 claves para un cliente. Almacene los secretos de cliente y las claves privadas de forma segura y rótelos cuando sea necesario.
FoxIDs establece una sesión cuando el usuario se autentica e incluye su ID de sesión en el token de ID. La sesión se invalida al cerrar sesión. Según la configuración del cliente y si la solicitud de cierre de sesión contiene un token de ID, FoxIDs puede mostrar un cuadro de confirmación de cierre de sesión.
Cliente y API
Un registro de aplicación OpenID Connect puede contener tanto el cliente como su recurso OAuth 2.0. El ID de cliente es entonces también el nombre del recurso de API.
El siguiente ejemplo configura oidc-web-app como cliente OpenID Connect y API:
- Haga clic en Change application y active Show advanced.
- Cambie el tipo de registro de aplicación a OpenID Connect Client and OAuth 2.0 Resource.
- En la pestaña OpenID Connect Client, mantenga seleccionado Default resource 'oidc-web-app' for the application itself.
- Añada los scopes
readywritedebajo del recurso predeterminado.
En la pestaña OAuth 2.0 Resource, defina los mismos scopes read y write que expone la API.
Recurso y scopes
Una API puede registrarse por separado como recurso OAuth 2.0. En este ejemplo, el cliente oidc-web-app llama a una Orders API independiente con el nombre de recurso orders-api.
En la pestaña OpenID Connect Client del cliente:
- Desmarque Default resource 'oidc-web-app' for the application itself, porque este cliente no actúa como su propia API.
- Añada el recurso
orders-api. - Añada los scopes
readywritebajo ese recurso.
Los valores completos de scope solicitados por el cliente son orders-api:read y orders-api:write.
En el registro de la Orders API, defina read y write en la pestaña OAuth 2.0 Resource.
Los scopes solicitados por un cliente se validan con los scopes configurados en la API. Si el cliente y la API están en el mismo registro de aplicación, los scopes añadidos bajo el recurso predeterminado del cliente se añaden automáticamente al recurso.
De forma predeterminada, el ID de cliente es la audience tanto del token de ID como del token de acceso. Los scopes de recursos configurados añaden audiences de API al token de acceso, y un token de acceso puede dirigirse a varios recursos de API.
Scopes y claims
Los scopes de OpenID Connect se configuran en la pestaña OpenID Connect Client. Los scopes predeterminados offline_access, profile, email, address y phone se pueden modificar o eliminar. Para cada scope, Voluntary claims controla qué claims se emiten cuando el cliente solicita ese scope.
Active Show advanced para configurar Issue claims. Añada un claim específico o añada * para emitir todos los claims disponibles en el token de acceso. Mantenga Include in ID token desactivado para *; de lo contrario, todos los claims disponibles se copian en el token de ID, lo que puede hacerlo excesivamente grande y causar problemas en los flows donde el token de ID se envía durante el cierre de sesión.
También puede añadir un claim a Voluntary claims de un scope y solicitar ese scope desde la aplicación. Los claims individuales pueden incluirse en el token de ID cuando la aplicación los necesite allí. Los claims también pueden modificarse con transformaciones y tareas de claims.
Duración de los tokens
Haga clic en Change application y active Show advanced para configurar las duraciones del código de autorización, el token de ID, el token de acceso 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 hasta alcanzar la duración absoluta del refresh token de 86 400 segundos.
Requerir autenticación multifactor (MFA)
Un cliente OpenID Connect puede requerir MFA incluyendo urn:foxids:mfa en el parámetro acr_values. Se puede combinar con valores más específicos, como urn:foxids:link. Consulte solicitar MFA desde aplicaciones.
El parámetro acr_values se puede establecer en el evento OnRedirectToIdentityProvider de Startup.cs:
options.Events.OnRedirectToIdentityProvider = (context) =>
{
context.ProtocolMessage.AcrValues = "urn:foxids:mfa";
return Task.FromResult(string.Empty);
};
Consulte AspNetCoreOidcAuthorizationCodeSample y su configuración de Startup.cs.
Guías prácticas
- Conectar Tailscale