Enregistrement d’application OpenID Connect

L’enregistrement d’application OpenID Connect FoxIDs vous permet de connecter une application basée sur OpenID Connect.

Votre application devient une Relying Party (RP) et FoxIDs agit comme OpenID Provider (OP).

FoxIDs prend en charge OpenID Connect Discovery où votre application peut découvrir l’OpenID Provider.

FoxIDs prend en charge l’authentification OpenID Connect (login), RP-initiated logout et front-channel logout. Une session est établie lorsque l’utilisateur s’authentifie et l’identifiant de session est inclus dans l’ID token. La session est invalidée lors du logout.
FoxIDs peut afficher un dialogue de confirmation de logout selon la configuration et selon qu’un ID token est inclus ou non dans la requête de logout.

Par défaut, l’ID token et l’access token sont émis avec l’identifiant client comme audience. La ressource par défaut peut être supprimée de l’access token dans FoxIDs Control. Les access tokens peuvent être émis avec une liste d’audiences et ainsi être émis pour plusieurs API définies dans FoxIDs comme ressources OAuth 2.0.
L’application peut ensuite appeler une API en sécurisant l’appel avec l’access token en utilisant The OAuth 2.0 Authorization Framework: Bearer Token Usage.

FoxIDs prend en charge à la fois le client secret et Proof Key for Code Exchange (PKCE), et exige PKCE par défaut. Si un client est configuré avec PKCE et un secret ou une clé, les deux seront validés. PKCE et le secret ou la clé client ne sont pas validés dans le flux implicite.

La méthode d’authentification client par défaut est client secret post et peut être modifiée en client secret basic ou private key JWT. La méthode d’authentification client none est prise en charge avec PKCE.

Un maximum de 10 secrets et 4 clés peut être configuré par client.

FoxIDs prend en charge l’endpoint UserInfo OpenID Connect.

Guides pratiques :

• Connecter deux environnements FoxIDs dans le même tenant ou dans des tenants différents avec OpenID Connect
• Connecter deux environnements FoxIDs dans le même tenant avec un Environment Link

Il est recommandé d’utiliser le flux OpenID Connect Authorization Code avec PKCE, car il est considéré comme un flux sécurisé.

Exiger l’authentification multifacteur (MFA)

Le client OpenID Connect peut exiger l’authentification multifacteur en spécifiant la valeur urn:foxids:mfa dans le paramètre AcrValues.

Le paramètre AcrValues peut être défini dans l’événement OnRedirectToIdentityProvider dans Startup.cs:

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

Voir plus de code dans AspNetCoreOidcAuthorizationCodeSample et Startup.cs line 141.

Configuration

Comment configurer votre application comme un client / Relaying Party (RP) d’enregistrement d’application OpenID Connect.

Le document de découverte FoxIDs du client est https://foxids.com/tenant-x/environment-y/application-client1/.well-known/openid-configuration
si le client est configuré dans le tenant tenant-x et l’environnement environment-y avec le nom de client d’enregistrement d’application application-client1.

Un client d’enregistrement d’application peut éventuellement supporter la connexion via plusieurs méthodes d’authentification en ajoutant le nom de la méthode d’authentification à l’URL.
Un nom de méthode d’authentification, par exemple login, peut être ajouté à l’URL de découverte comme ceci https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration

Pendant le RP-initiated logout, le nom de la méthode d’authentification peut être omis dans l’URL si l’ID Token est fourni dans la requête.

Configurer le flux Authorization Code pour un client confidentiel

Un client confidentiel peut être une application web où la sécurité est gérée par le serveur web qui stocke également le client secret.

• Spécifiez le nom du client dans le nom d’enregistrement de l’application.
• Sélectionnez les méthodes d’authentification autorisées.
• Spécifiez les URI de redirection.
• Spécifiez l’URI de redirection post logout.
• Sélectionnez code comme type de réponse ou, possible mais non recommandé, code token ou code token id_token.
• Il n’est pas obligatoire d’utiliser PKCE dans un client confidentiel, mais c’est recommandé pour atténuer les attaques de relecture.
• Spécifiez un secret.

Configurer le flux Authorization Code pour un client public

Un client public peut être un client riche basé sur navigateur, un client Blazor ou une application mobile. L’application doit utiliser PKCE et pas de client secret.

• Spécifiez le nom du client dans le nom d’enregistrement de l’application.
• Sélectionnez les méthodes d’authentification autorisées.
• Spécifiez les URI de redirection.
• Spécifiez l’URI de redirection post logout.
• Sélectionnez code comme type de réponse.
• Utilisez PKCE, activé par défaut.

Cliquez sur "Show advanced" pour configurer les origines CORS autorisées.

Configurer le flux Implicit Code pour un client public

Un client public peut être une application web où la sécurité est gérée par le serveur web ou un client riche basé sur navigateur. L’application n’utilise ni PKCE ni client secret.
Il n’est pas recommandé d’utiliser le flux Implicit Code car il est non sécurisé.

• Spécifiez le nom du client dans le nom d’enregistrement de l’application.
• Sélectionnez les méthodes d’authentification autorisées.
• Spécifiez les URI de redirection.
• Spécifiez l’URI de redirection post logout.
• Sélectionnez token id_token comme type de réponse ou uniquement token si possible.
• Désactivez PKCE.
• Ne spécifiez pas de secret.

Client et API

Il est possible de configurer à la fois le client et l’API (ressource OAuth 2.0) dans la même configuration d’enregistrement d’application OpenID Connect, où le client et l’API sont définis avec le même nom. En outre, il est possible de configurer les portées de ressource pour l’API.

Onglet Client

Onglet Ressource

Ressource et portées

Une API est définie comme une ressource dans laquelle il est possible de définir des portées. Ces portées sont définies comme nom de ressource point portée, par exemple application-api1.read1 ou application-api1.read2.

Dans l’onglet de configuration client, les portées sont définies sous le champ du nom de ressource.

Dans l’onglet de configuration des ressources, les portées sont définies comme une liste de valeurs de portée.

Les portées configurées dans le client sont validées si les portées existent sur l’API. Si le client et l’API sont configurés dans la même configuration d’enregistrement d’application, les portées ajoutées au client sont automatiquement ajoutées à la ressource.

Portées

Les portées peuvent être configurées dans l’onglet de configuration client. Il est possible de définir de nouvelles portées et un ensemble de revendications qui doivent être émises pour les portées dans la liste Voluntary claims.

Vous pouvez modifier les revendications et effectuer des tâches de revendications avec transformations de revendications et tâches de revendications.

Si vous créez une nouvelle revendication, ajoutez la revendication ou * à la liste Issue claims ou ajoutez la revendication à la liste Voluntary claims et demandez la portée depuis votre application.

Un ensemble de portées par défaut est ajouté à la configuration client et peut ensuite être modifié ou supprimé.

Durée de vie du token

La durée de vie du token est configurée pour l’ID token, l’access token et le refresh token.

Dans cet exemple, chaque refresh token est valide pendant 36 000 secondes. L’application peut continuer à actualiser la session avec des refresh tokens jusqu’à atteindre la durée de vie absolue de 86 400 secondes.