Exploration de la configuration d'OpenID Connect : Champs clés et leurs utilisations

Dans le monde numérique actuel, l'authentification est devenue un composant central de la sécurisation des sites web et des applications. OpenID Connect (OIDC), une couche d'authentification construite sur le protocole OAuth 2.0, offre un moyen standardisé et simple d'authentifier les identités.

Cependant, intégrer correctement l'OIDC peut être intimidant, surtout pour les nouveaux venus. Un bon point de départ consiste souvent en le fichier de configuration OIDC, généralement disponible à l'URL {authServerUrl}/.well-known/openid-configuration, qui contient tous les détails nécessaires pour implémenter les services OIDC.

Ce guide a pour objectif de clarifier les champs clés de cette configuration, pour aider les développeurs à saisir leur importance et les applications pratiques afin d'intégrer plus efficacement l'OIDC dans leurs projets.

Analyse des champs de configuration OIDC#

La configuration OIDC est un fichier JSON similaire au suivant :

Ensuite, nous examinerons en profondeur certains des champs clés.

authorization_endpoint#

Lors de l'intégration des services OIDC, la première étape consiste généralement à gérer les demandes de connexion des utilisateurs au sein de l'application. Ce processus inclut la redirection des utilisateurs vers le authorization_endpoint du serveur d'autorisation. Cet endpoint est l'adresse du serveur où les requêtes d'autorisation sont envoyées, guidant les utilisateurs vers la page de connexion pour l'authentification.

Lors de l'envoi d'une requête à l'authorization_endpoint, celle-ci doit être configurée avec des paramètres de requête supplémentaires pour chaque autorisation :

• response_type : Spécifie le type d'autorisation retourné. Cela inclut typiquement "code" (pour le flux de code d'autorisation), "token" (pour le flux implicite) et "id_token token" ou "code id_token" (pour le flux hybride), qui peuvent être trouvés dans le champ response_types_supported de la configuration OIDC.
• client_id : Un identifiant unique attribué à l'application par le serveur d'autorisation lors de l'enregistrement de l'application. Cet ID est utilisé par le serveur d'autorisation pour reconnaître l'application cliente initiant la requête.
• scope : Définit l'étendue d'accès demandée, spécifiant les ressources ou les informations utilisateur accessibles. Les étendues courantes incluent "openid" (obligatoire), "profile", et "email", parmi d'autres. Vous pouvez trouver les étendues prises en charge dans le champ scopes_supported de la configuration OIDC ; différentes étendues doivent être séparées par des espaces.
• redirect_uri : Après la connexion ou l'autorisation, le serveur d'autorisation redirige l'utilisateur vers l'URI fourni par l'application. Cet URI doit correspondre strictement à l'URI fourni lors de l'enregistrement de l'application.
• state : Une chaîne générée aléatoirement utilisée pour protéger le client contre les attaques par falsification de requêtes intersites. La cohérence de l'état entre la demande d'autorisation et le rappel doit être maintenue pour assurer la sécurité.

Ces paramètres permettent aux développeurs de contrôler précisément le comportement des requêtes d'autorisation OIDC, garantissant qu'elles sont sécurisées et répondent aux besoins de l'application.

Après avoir complété la requête à l'authorization_endpoint et passé l'authentification, les utilisateurs sont redirigés vers redirect_uri, spécifié, qui inclura un paramètre de requête très crucial—code. Ce code d'autorisation est fourni par le serveur d'autorisation et est le résultat de l'utilisateur s'authentifiant et autorisant l'application à accéder à ses informations sur le serveur d'autorisation.

token_endpoint#

token_endpoint est l'endpoint du serveur utilisé par le serveur d'autorisation pour échanger le code d'autorisation susmentionné contre des jetons d'accès et de rafraîchissement. Dans le flux de code d'autorisation OAuth 2.0, cette étape est cruciale car elle implique de convertir le code d'autorisation obtenu en véritables jetons d'accès, que l'application peut utiliser pour accéder aux ressources protégées de l'utilisateur.

Voici comment échanger le code d'autorisation contre des jetons d'accès est implémenté (notez que cet exemple utilise la méthode d'authentification client_secret_post. Pour d'autres méthodes d'authentification prises en charge, consultez l'analyse ultérieure du champ <BreakAllBlock>token_endpoint_auth_methods_supported</BreakAllBlock>):

Dans ce code, nous envoyons d'abord une requête à l'token_endpoint en utilisant la méthode POST. Le type de contenu est défini sur application/x-www-form-urlencoded, ce qui est requis par la plupart des serveurs d'autorisation. Le corps de la requête inclut les paramètres suivants :

• code : Le code d'autorisation obtenu du serveur d'autorisation, qui est retourné via le redirectUri après que l'utilisateur a complété l'autorisation.
• redirect_uri : Le même URI de redirection utilisé pour obtenir le code d'autorisation, utilisé pour vérifier la légitimité de la requête.
• client_id : L'identifiant client de l'application, utilisé pour identifier l'application faisant la requête.
• client_secret : Le secret client de l'application, utilisé pour vérifier l'identité de l'application.
• grant_type : Spécifie le type d'autorisation, en utilisant "authorization_code" ici, ce qui indique que le jeton d'accès est obtenu via le code d'autorisation.

Cette fonction est exécutée de manière asynchrone et retourne un objet JSON contenant le jeton d'accès, que l'application peut utiliser pour demander des données utilisateur ou réaliser d'autres opérations.

userinfo_endpoint#

userinfo_endpoint est l'endpoint du serveur utilisé par le serveur d'autorisation pour obtenir des informations détaillées sur les utilisateurs authentifiés. Après que les utilisateurs ont autorisé avec succès et obtenu des jetons d'accès via l'token_endpoint, l'application peut demander cet endpoint pour accéder aux informations du profil de l'utilisateur, comme le nom d'utilisateur et l'adresse e-mail. Les informations spécifiques obtenues dépendent de l'scope spécifié par l'utilisateur dans la demande d'authentification.

Dans cette fonction, nous utilisons d'abord la méthode GET pour requérir l'userinfo_endpoint, en incluant le champ Authorization dans l'en-tête de la requête composés de token_type et accessToken. C'est une opération standard selon la spécification OAuth 2.0, garantissant la récupération sécurisée des informations utilisateur. De plus, l'étendue des informations utilisateur accessibles via le jeton d'accès dépend complètement des valeurs de paramètres de portée scope adoptées par l'utilisateur au début de la demande d'autorisation. Par exemple, si la portée email est utilisée, la réponse doit inclure l'adresse e-mail de l'utilisateur.

issuer & jwks_uri#

L'issuer identifie l'URL du serveur d'autorisation, tandis que jwks_uri fournit l'URI pour le JSON Web Key Set (JWKS), qui est un ensemble de clés publiques utilisées pour vérifier les signatures JWT. Vérifier l'issuer du JWT et sa signature sont des étapes de base pour garantir la sécurité des jetons, mais dans

des scénarios réels, le processus de vérification comprend également généralement la vérification de la période de validité du jeton, de son audience, de l'étendue de l'autorisation et d'autres champs importants.

Le code suivant démontre principalement comment utiliser issuer et jwks_uri ensemble pour vérifier un JWT :

scopes_supported & claims_supported#

Les champs claims_supported et scopes_supported déclarent les attributs utilisateur (claims) et les portées d'accès (scopes) pris en charge par le serveur d'autorisation. Ils aident les clients à comprendre quels attributs utilisateur et quelles portées d'accès sont pris en charge par le serveur d'autorisation, permettant ainsi aux clients de construire efficacement des demandes d'autorisation et de saisir les réponses.

Lors de la construction d'une demande d'autorisation, les clients peuvent spécifier l'scope requis en fonction des besoins de l'application. Scope définit les ressources et opérations auxquelles le client demande l'accès, comme openid, email, profile, et d'autres.

Il est important de noter que les claims spécifiques accessibles dans chaque demande d'autorisation varient en fonction des valeurs de portée spécifiées au début de la demande d'authentification. Par exemple, la portée email donne accès à l'adresse e-mail de l'utilisateur, tandis que la portée téléphone donne accès à son numéro de téléphone. Par conséquent, les clients doivent choisir soigneusement l'étendue pertinente pour correspondre aux besoins de l'application lorsqu'ils rédigent une demande d'autorisation, en veillant à pouvoir récupérer les attributs utilisateur nécessaires :

token_endpoint_auth_methods_supported

#

Le champ

indique les méthodes d'authentification prises en charge par l'endpoint de jeton. Ces méthodes sont utilisées par le client pour s'authentifier auprès du serveur d'autorisation lors de l'échange du code d'autorisation contre des jetons d'accès.

Lors de l'authentification en utilisant l'endpoint de jeton, les méthodes d'authentification courantes incluent client_secret_post, client_secret_basic et client_secret_jwt.

• client_secret_post : Le client utilise son identifiant client et son client secret pour construire un corps de requête encodé en formulaire, qui est envoyé en tant qu'une partie du corps de la requête. Nous avons déjà vu un exemple de cette méthode dans la section token_endpoint ci-dessus.

• client_secret_basic : Le client utilise son identifiant client et son client secret pour construire un en-tête d'authentification basic, qui est ajouté à l'en-tête de la requête.

• client_secret_jwt : Le client utilise un JWT (JSON Web Token) comme assertion client pour s'authentifier. Ce JWT contient l'identifiant client et certaines meta-données supplémentaires et est signé en utilisant le secret client. Après avoir reçu la requête, le serveur d'autorisation vérifie l'identité du client en validant la signature du JWT.

Dans les applications pratiques, les clients doivent choisir la méthode d'authentification appropriée en fonction des méthodes prises en charge par le serveur d'autorisation, et s'assurer que les informations d'authentification sont correctement ajoutées à la requête pour échanger de manière sécurisée le code d'autorisation contre des jetons d'accès.

Résumé#

Nous avons maintenant exploré les champs clés dans la configuration OIDC, en se concentrant sur leurs objectifs et applications. Comprendre ces détails améliorera votre compréhension d'OpenID Connect, vous permettant de l'intégrer et de l'utiliser plus efficacement dans vos projets. Armé de ces connaissances, vous êtes mieux équipé pour exploiter pleinement le potentiel de l'OIDC pour des solutions d'authentification utilisateur plus sécurisées et efficaces.

Logto comme un service d'authentification construit sur l'OIDC, qui offre une suite complète de SDKs dans divers langages ainsi que de nombreux tutoriels d'intégration, vous permet d'intégrer les connexions OAuth/OIDC à vos applications en quelques minutes seulement. Si vous cherchez un service OIDC fiable et facile à utiliser, essayez Logto dès aujourd'hui !