Inscription d'application OpenID Connect

L'inscription d'application OpenID Connect de 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, afin que votre application puisse découvrir l'OpenID Provider.

FoxIDs prend en charge OpenID Connect authentication, RP-initiated logout et front-channel logout. Une session est créée 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 une boîte de dialogue de confirmation de logout selon la configuration du client et selon qu'un ID token est inclus dans la requête de logout.

Par défaut, l'ID token et l'access token utilisent tous deux l'ID client comme audience. La ressource par défaut peut être supprimée de l'access token dans FoxIDs Control.

Les access tokens peuvent aussi être émis avec plusieurs audiences et donc cibler plusieurs API définies dans FoxIDs comme ressources OAuth 2.0. L'application peut alors appeler une API et sécuriser la requête avec l'access token conformément à The OAuth 2.0 Authorization Framework: Bearer Token Usage.

FoxIDs prend en charge à la fois les secrets client et Proof Key for Code Exchange (PKCE), et PKCE est activé par défaut. Si un client est configuré avec PKCE et un secret ou une clé, les deux sont validés. PKCE et secret ou clé client ne sont pas validés dans l'implicit flow.

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

Jusqu'à 10 secrets et 4 clés peuvent être configurés par client.

FoxIDs prend en charge l'endpoint OpenID Connect UserInfo endpoint.

Guides pratiques :

• Connecter Tailscale

Connecter des environnements FoxIDs

• Environment Link pour des environnements dans le même tenant.
• OpenID Connect pour des environnements dans le même tenant ou dans des tenants différents.

Exiger l'authentification multi-facteur (MFA)

Le client OpenID Connect peut exiger la MFA en incluant urn:foxids:mfa dans le paramètre acr_values. Vous pouvez le combiner avec des valeurs plus spécifiques comme urn:foxids:link. Voir demander la MFA depuis les applications.

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

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

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

Configuration

Voici comment configurer votre application comme inscription d'application OpenID Connect, Relying Party (RP) ou client.

Le document discovery 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, l'environnement environment-y et avec le nom de client application-client1.

Un client d'inscription d'application peut prendre en charge la connexion via plusieurs méthodes d'authentification en ajoutant le nom de la méthode d'authentification à l'URL. Par exemple, un nom de méthode d'authentification comme login peut être ajouté à l'URL discovery comme ceci : https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration

Lors du 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 Authorization Code flow pour un client confidentiel

Un client confidentiel est généralement une application web côté serveur dans laquelle le serveur web stocke le secret client.

• Indiquez le nom du client dans le nom de l'inscription d'application.
• Sélectionnez les méthodes d'authentification autorisées.
• Indiquez les URI de redirection.
• Indiquez l'URI de redirection post-logout.
• Sélectionnez code comme response type ou, éventuellement mais non recommandé, code token ou code token id_token.
• PKCE n'est pas obligatoire pour un client confidentiel, mais il est recommandé pour limiter les attaques par rejeu.
• Indiquez un secret.

Configurer Authorization Code flow pour un client public

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

• Indiquez le nom du client dans le nom de l'inscription d'application.
• Sélectionnez les méthodes d'authentification autorisées.
• Indiquez les URI de redirection.
• Indiquez l'URI de redirection post-logout.
• Sélectionnez code comme response type.
• Utilisez PKCE, activé par défaut.

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

Configurer implicit flow pour un client public

Un client public peut être un rich client basé sur navigateur. L'application n'utilise ni PKCE ni secret client.

Il n'est pas recommandé d'utiliser l'implicit flow, car il n'est pas sûr.

• Indiquez le nom du client dans le nom de l'inscription d'application.
• Sélectionnez les méthodes d'authentification autorisées.
• Indiquez les URI de redirection.
• Indiquez l'URI de redirection post-logout.
• Sélectionnez token id_token comme response type ou, éventuellement, seulement token.
• Désactivez PKCE.
• N'indiquez pas de secret.

Client et API

Il est possible de configurer à la fois le client et l'API, c'est-à-dire une OAuth 2.0 resource, dans la même inscription d'application OpenID Connect. Dans ce cas, le client et l'API sont définis avec le même nom. Vous pouvez aussi configurer des resource scopes pour l'API.

Client tab

Resource tab

Resource et scopes

Une API est définie comme une resource et des scopes sont définis sous cette resource. Ces scopes utilisent le format nom-de-resource plus point plus scope, par exemple application-api1.read1 ou application-api1.read2.

Dans l'onglet de configuration du client, les scopes sont définis sous le champ du nom de la resource.

Dans l'onglet de configuration de la resource, les scopes sont définis comme une liste de valeurs de scope.

Les scopes configurés sur le client sont validés par rapport aux scopes qui existent sur l'API. Si le client et l'API sont configurés dans la même inscription d'application, les scopes ajoutés au client sont automatiquement ajoutés à la resource.

Scopes

Les scopes peuvent être configurés dans l'onglet de configuration du client. Vous pouvez définir de nouveaux scopes et l'ensemble des claims à émettre pour ces scopes dans la liste Voluntary claims.

Vous pouvez modifier les claims et implémenter des claim tasks avec claim transforms et claim tasks.

Si vous créez un nouveau claim, ajoutez le claim ou * à la liste Issue claims, ou ajoutez le claim à la liste Voluntary claims et demandez le scope depuis votre application.

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

Durée de vie du jeton

La durée de vie du jeton 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 à renouveler la session avec des refresh tokens jusqu'à ce que la durée de vie absolue de 86 400 secondes soit atteinte.