Quelles sont les différences entre les clients publics et confidentiels ?

Lorsque vous utilisez Logto pour créer une application, vous remarquerez qu'il existe plusieurs types d'applications différents parmi lesquels choisir, notamment Application Monopage (SPA), Application Native et Application Web Traditionnelle. Intuitivement, par le nom, il est clair qu'une Application Native fonctionne sur des systèmes d'exploitation couramment trouvés sur des appareils comme les téléphones. Cependant, que sont exactement une SPA et une Application Web Traditionnelle ? Pourquoi devons-nous distinguer entre ces différents types d'applications ? Cet article révélera les réponses à ces questions.

Avant de commencer, nous devons fournir une brève introduction à certains concepts.

Qu'est-ce qu'OAuth ?#

OAuth est une norme ouverte pour la délégation d'accès, qui est généralement utilisée comme un moyen pour les utilisateurs d'Internet d'accorder aux sites Web ou aux applications un accès à leurs informations sur d'autres sites Web sans fournir leurs mots de passe.

Au cours de la dernière décennie, il est progressivement devenu le processus d'autorisation standard et a été largement accepté par la plupart des entreprises telles que Google, Meta, Microsoft, etc. La version actuellement utilisée est OAuth 2.0.

Dans le contexte d'OAuth, l'application que nous avons mentionnée plus tôt est appelée Client. Ils peuvent faire des demandes de ressources protégées, à condition qu'ils aient obtenu l'autorisation du propriétaire de la ressource (généralement les utilisateurs finaux).

Clients publics et clients confidentiels#

OAuth définit deux types de clients, en fonction de leur capacité à maintenir la confidentialité des informations d'identification du client.

Client confidentiel#

Un client capable de maintenir la confidentialité de ses informations d'identification (par exemple, un client implémenté sur un serveur sécurisé avec un accès restreint aux informations d'identification du client) ou capable d'une authentification sécurisée du client par d'autres moyens.

Client public#

Un client incapable de maintenir la confidentialité de ses informations d'identification (par exemple, un client s'exécutant sur l'appareil du propriétaire de la ressource, comme une application native ou une application Web) et également incapable de s'authentifier en toute sécurité en tant que client par d'autres moyens.

SPA, application native et application Web traditionnelle#

Avec les connaissances de base mentionnées ci-dessus, examinons ce que signifient SPA, Application Native et Application Web Traditionnelle dans le contexte de Logto, ainsi que s'ils sont considérés comme des clients publics ou confidentiels.

SPA#

Le code côté client d'une SPA est téléchargé à partir d'un serveur Web et exécuté dans l'agent utilisateur (comme un navigateur Web) du propriétaire de la ressource sur son appareil. Les données de protocole et les informations d'identification sont facilement accessibles (et souvent visibles) par le propriétaire de la ressource.

Application native#

Une application native est installée et exécutée sur l'appareil du propriétaire de la ressource. Les données de protocole et les informations d'identification sont accessibles au propriétaire de la ressource. Il est généralement supposé que toute information d'identification d'authentification client contenue dans l'application peut être extraite.

Application Web traditionnelle#

Une application Web traditionnelle est un client qui s'exécute sur un serveur Web. Le propriétaire de la ressource accède au client via une interface utilisateur HTML présentée dans l'agent utilisateur sur leur appareil. Les informations d'identification du client ainsi que les tokens d'accès émis au client sont stockés sur le serveur Web et ne sont pas exposés ni accessibles au propriétaire de la ressource.

Donc, nous pouvons voir clairement que SPA et l'application native sont des clients publics, tandis que l'application Web traditionnelle est un client confidentiel.

Vous pouvez constater que lors de la création d'une SPA ou d'une application native dans Logto, il n'y a pas de secret d'application, tandis qu'une application Web traditionnelle a à la fois un ID d'application et un secret d'application. Cela est dû au fait que le secret d'un client public ne peut pas être garanti comme étant sécurisé.

Comment fonctionne un client dans le flux d'autorisation OAuth ?#

Lorsque vous développez des applications OAuth, la première étape consiste à enregistrer le client auprès du fournisseur de services OAuth. L'enregistrement du client implique de fournir des détails sur l'application, tels que son nom et l'URI de redirection. Ensuite, le fournisseur de services OAuth génère un ID client et un secret client, qui sont considérés comme les informations d'identification de l'application.

L'ID client est considéré comme une information publique et est partagé avec l'utilisateur pendant le processus OAuth. Il est généralement inclus dans l'URL d'autorisation et visible pour les utilisateurs finaux.

D'un autre côté, le secret client sert de mot de passe pour l'application et doit être tenu secret. Il est utilisé dans le processus OAuth pour échanger le code d'autorisation (en supposant qu'il s'agit du flux de code d'autorisation) pour obtenir le token d'accès. L'existence de secrets clients garantit que seules les applications enregistrées peuvent achever l'échange de tokens d'accès.

Introduction à la Preuve de Clé pour Échange de Code (PKCE)#

Comme mentionné précédemment, les secrets clients des clients publics ne peuvent pas être garantis comme étant sécurisés, et les attaquants peuvent obtenir les informations d'identification des clients et se faire passer pour des clients pour accéder à des ressources protégées, ce qui est inacceptable dans n'importe quelle situation.

PKCE (Preuve de Clé pour Échange de Code) résout ce problème en générant temporairement un vérificateur de code au début de chaque flux d'autorisation, qui est stocké localement et haché pour générer un défi de code qui est envoyé au serveur d'autorisation. Le vérificateur de code est à nouveau envoyé au serveur d'autorisation lors de l'échange du token d'accès. Le serveur d'autorisation vérifie que le vérificateur de code et le défi de code correspondent, ce qui garantit que le client public n'a pas été usurpé.

Le vérificateur de code dans PKCE fonctionne en fait comme un secret client dynamique. Sa sécurité est assurée par l'irréversibilité de l'algorithme de hachage.

Récapitulatif#

Dans cet article, nous avons discuté des concepts de clients confidentiels et de clients publics dans OAuth. Nous avons appris que les clients confidentiels ont la capacité de garder des secrets et de stocker des informations sensibles en toute sécurité, tandis que les clients publics en sont incapables. Nous avons examiné des exemples des deux types de clients, y compris les applications Web traditionnelles, SPA, et les applications natives, dans le contexte des pratiques produit de Logto.

Nous avons également discuté du processus d'enregistrement des clients dans OAuth et des rôles de l'ID client et du secret client.

De plus, nous avons constaté que les clients publics font face à des limitations en matière de stockage sécurisé des secrets clients. Pour surmonter cette limitation, nous avons introduit PKCE (Preuve de Clé pour Échange de Code), une extension OAuth qui permet aux clients publics d'échanger de manière sécurisée les codes d'autorisation sans avoir besoin de secret client.

Notre produit, Logto, est une solution CIAM complète qui suit les meilleures pratiques des protocoles OAuth et OIDC pour assurer la sécurité à chaque étape, y compris l'adoption de l'utilisation de PKCE pour protéger la sécurité des clients publics.