Enregistrement d’application OpenID Connect

Un enregistrement d’application OpenID Connect FoxIDs permet à une application web, monopage ou native d’authentifier les utilisateurs via FoxIDs et de recevoir des jetons d’ID et d’accès. L’application est la Relying Party (RP), et FoxIDs est l’OpenID Provider (OP).

Les principales fonctionnalités OpenID Connect comprennent la discovery, Authorization Code Flow, PKCE, les secrets et clés client, le point de terminaison UserInfo, la déconnexion initiée par le RP et le front-channel logout.

Configuration

Dans FoxIDs Control :

1. Sélectionnez l’environnement dans lequel l’application doit être enregistrée.
2. Ouvrez Applications et cliquez sur Add application.
3. Choisissez Web Application, Single Page Application ou Native Application. Ces trois options OpenID Connect sont affichées sans activer Show all options.
4. Saisissez un nom et une URI de redirection, vérifiez les informations d’application générées, puis cliquez sur Create.
5. Copiez tout secret généré avant de fermer le résultat de création. Un secret généré n’est affiché que pendant la création.

Après la création, cliquez sur Change application pour vérifier ou modifier tous les paramètres de l’application. La carte du type d’application fournit une configuration initiale adaptée ; le client OpenID Connect obtenu peut ensuite être ajusté.

Application web (client confidentiel)

Choisissez Web Application pour une application exécutée sur un serveur, par exemple une application ASP.NET Core, Node.js, Java ou PHP. Elle est créée comme client confidentiel avec :

• Authorization Code Flow utilisant le response type code.
• Un secret client généré.
• PKCE désactivé par défaut. Activez Require PKCE après la création lorsque l’application prend en charge PKCE. Cela est recommandé comme protection supplémentaire du code d’autorisation.

Saisissez l’URL de base ou l’URL de rappel de l’application dans Redirect URI. Activez Show advanced pendant la création uniquement si vous devez choisir l’ID client ou configurer une correspondance exacte de l’URL de redirection.

Application monopage (client public)

Choisissez Single Page Application pour une application exécutée dans le navigateur, par exemple React, Angular, Vue ou Blazor WebAssembly. Elle est créée comme client public avec :

• Authorization Code Flow utilisant le response type code.
• PKCE activé par défaut.
• Aucun secret client.
• L’origine de l’URL de redirection ajoutée comme origine CORS autorisée.

Application native (client public)

Choisissez Native Application pour une application mobile ou de bureau installée, par exemple iOS, Android, React Native, .NET MAUI ou Ionic. Elle est créée comme client public avec Authorization Code Flow, PKCE activé par défaut et sans secret client.

L’URI de redirection peut utiliser un schéma propre à l’application, comme myapp://callback, ou une URI HTTPS prise en charge par l’application.

URI de redirection et valeurs absolues

Par défaut, Absolute URIs est désactivé pour les applications web et monopages. L’URL de redirection configurée est alors traitée comme une valeur de base, et les URL de redirection commençant par cette valeur sont acceptées.

Activez Show advanced et Absolute URIs si vous connaissez l’URL exacte de votre application vers laquelle l’utilisateur doit être redirigé après la connexion. Saisissez cette URL exacte dans Redirect URI. Le même paramètre prend en charge des URI exactes propres aux applications natives.

Après la création, les URI de redirection, l’URI de redirection après déconnexion et les origines CORS autorisées peuvent être modifiées dans l’onglet OpenID Connect Client. Laissez Show advanced désactivé sauf si le paramètre nécessaire est avancé.

Implicit Flow

Implicit Flow est conservé pour compatibilité, mais n’est pas recommandé pour les nouvelles applications. Préférez Authorization Code Flow avec PKCE.

Pour configurer un client public existant avec Implicit Flow, cliquez sur Change application, activez Show advanced, remplacez Response types par token id_token ou éventuellement uniquement token, puis désactivez Require PKCE. Les response types peuvent être modifiés dans les mêmes paramètres client avancés lorsqu’une autre combinaison prise en charge est requise.

Points de terminaison de l’application et sécurité du client

Les informations d’application dans FoxIDs Control contiennent l’authority, l’ID client, le point de terminaison discovery, le point de terminaison authorize et le point de terminaison de jeton. Un document discovery OpenID Connect se présente ainsi :

https://foxids.com/tenant-x/environment-y/application-client1(*)/.well-known/openid-configuration

Une application peut autoriser la connexion via plusieurs méthodes d’authentification. Si une méthode d’authentification définit des profils, la méthode de base et chaque profil peuvent être sélectionnés indépendamment. Pour sélectionner une méthode d’authentification dans l’URL d’authority, ajoutez son nom au segment de l’application :

https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration

Lors d’une déconnexion initiée par le RP, le nom de la méthode d’authentification peut être omis lorsque le jeton d’ID est inclus dans la requête.

Issuer propre à l’application

Par défaut, les jetons émis pour l’application utilisent l’issuer de l’environnement :

https://foxids.com/tenant-x/environment-y/

Pour faire correspondre l’issuer à l’authority de l’application, cliquez sur Change application, activez Show advanced, puis activez Use matching issuer and authority with application specific issuer. L’issuer devient alors :

https://foxids.com/tenant-x/environment-y/application-client1(*)

L’issuer propre à l’application change lorsque les méthodes d’authentification sélectionnées dans l’URL d’authority changent. Pour les API, l’issuer dépend donc de l’application appelante. Token exchange n’est possible qu’entre des configurations ayant des méthodes d’authentification correspondantes.

Sécurité du client

Les clients publics, notamment les applications monopages et natives, ne peuvent pas conserver des informations d’identification client en toute sécurité. Configurez-les sans secret client et utilisez Authorization Code Flow avec PKCE.

Les clients confidentiels s’authentifient au point de terminaison de jeton. La méthode d’authentification client par défaut est client secret post. Activez Show advanced pour la remplacer par client secret basic ou private key JWT. PKCE est également recommandé lorsque le client confidentiel le prend en charge. Si PKCE et un secret ou une clé client sont configurés, FoxIDs valide les deux.

La méthode d’authentification client none est prise en charge avec PKCE. Jusqu’à 10 secrets et 4 clés peuvent être configurés pour un client. Stockez les secrets client et les clés privées de façon sécurisée et renouvelez-les si nécessaire.

FoxIDs établit une session lorsque l’utilisateur s’authentifie et inclut son ID de session dans le jeton d’ID. La session est invalidée lors de la déconnexion. Selon la configuration du client et la présence d’un jeton d’ID dans la requête de déconnexion, FoxIDs peut afficher une boîte de dialogue de confirmation de déconnexion.

Client et API

Un enregistrement d’application OpenID Connect peut contenir à la fois le client et sa ressource OAuth 2.0. L’ID client est alors également le nom de la ressource API.

L’exemple suivant configure oidc-web-app à la fois comme client OpenID Connect et comme API :

1. Cliquez sur Change application et activez Show advanced.
2. Remplacez le type d’enregistrement par OpenID Connect Client and OAuth 2.0 Resource.
3. Dans l’onglet OpenID Connect Client, conservez Default resource 'oidc-web-app' for the application itself sélectionné.
4. Ajoutez les scopes read et write sous la ressource par défaut.

Dans l’onglet OAuth 2.0 Resource, définissez les mêmes scopes read et write que ceux exposés par l’API.

Ressource et scopes

Une API peut à la place être enregistrée séparément comme ressource OAuth 2.0. Dans cet exemple, le client oidc-web-app appelle une API Orders distincte dont le nom de ressource est orders-api.

Dans l’onglet OpenID Connect Client du client :

1. Désélectionnez Default resource 'oidc-web-app' for the application itself, car ce client n’agit pas comme sa propre API.
2. Ajoutez la ressource orders-api.
3. Ajoutez les scopes read et write sous cette ressource.

Les valeurs complètes des scopes demandés par le client sont orders-api:read et orders-api:write.

Dans l’enregistrement de l’API Orders, définissez read et write dans l’onglet OAuth 2.0 Resource.

Les scopes demandés par un client sont validés par rapport aux scopes configurés sur l’API. Si le client et l’API appartiennent au même enregistrement d’application, les scopes ajoutés sous la ressource par défaut du client sont automatiquement ajoutés à la ressource.

Par défaut, l’ID client est l’audience du jeton d’ID et du jeton d’accès. Les scopes de ressource configurés ajoutent des audiences d’API au jeton d’accès, et un jeton d’accès peut cibler plusieurs ressources API.

Scopes et claims

Les scopes OpenID Connect sont configurés dans l’onglet OpenID Connect Client. Les scopes par défaut offline_access, profile, email, address et phone peuvent être modifiés ou supprimés. Pour chaque scope, Voluntary claims détermine les claims émis lorsque le client demande ce scope.

Activez Show advanced pour configurer Issue claims. Ajoutez un claim précis, ou ajoutez * pour émettre tous les claims disponibles dans le jeton d’accès. Laissez Include in ID token désactivé pour *. Sinon, tous les claims disponibles sont copiés dans le jeton d’ID, ce qui peut le rendre excessivement volumineux et provoquer des problèmes dans les flows où le jeton d’ID est envoyé lors de la déconnexion.

Vous pouvez aussi ajouter un claim à Voluntary claims d’un scope et demander ce scope depuis l’application. Des claims individuels peuvent être inclus dans le jeton d’ID lorsque l’application en a besoin. Les claims peuvent également être modifiés avec des transformations et tâches de claims.

Durée de vie des jetons

Cliquez sur Change application et activez Show advanced pour configurer les durées de vie du code d’autorisation, du jeton d’ID, du jeton d’accès et du refresh token.

Dans cet exemple, chaque refresh token est valide pendant 36 000 secondes. L’application peut continuer à actualiser la session jusqu’à ce que la durée de vie absolue du refresh token de 86 400 secondes soit atteinte.

Exiger l’authentification multifacteur (MFA)

Un client OpenID Connect peut exiger la MFA en incluant urn:foxids:mfa dans le paramètre acr_values. Il peut être combiné avec des valeurs plus spécifiques, comme urn:foxids:link. Consultez demander la MFA depuis les applications.

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

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

Consultez AspNetCoreOidcAuthorizationCodeSample et sa configuration Startup.cs.

Guides pratiques

• Connecter Tailscale

Documentation associée

• OpenID Connect
• Ressources et API OAuth 2.0
• Authentification multifacteur
• Connecter des environnements avec Environment Link
• Connecter des environnements avec OpenID Connect
• Claims et mappage de claims