Français

oauth
sécurité
oidc
authentification

Pourquoi vous devriez déprécier le type de concession Resource Owner Password Credentials (ROPC)

Le type de concession Resource Owner Password Credentials (ROPC) est un flux OAuth 2.0 hérité qui pose des risques de sécurité et devrait être déprécié. Dans cet article, nous indiquerons pourquoi vous devriez éviter d'utiliser le ROPC dans vos applications.

Simeng

Developer

4/24/2024

Arrêtez de perdre des semaines sur l'authentification des utilisateurs

Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.

Commencer

Introduction

Le type de concession Resource Owner Password Credentials (ROPC), aussi connu sous le nom de type de concession par mot de passe, est un flux OAuth 2.0 qui permet à une application d'échanger le nom d'utilisateur et le mot de passe d'un utilisateur contre un jeton d'accès. Il a été introduit pour la première fois dans la spécification OAuth 2.0 comme un moyen de prendre en charge des applications héritées telles que l'authentification de base HTTP ou les applications natives héritées qui ne pouvaient pas utiliser les flux OAuth par jetons plus sécurisés.

Cependant, le type de concession ROPC présente plusieurs risques de sécurité et a été marqué comme un DOIT NE PAS être utilisé dans les meilleures pratiques de sécurité OAuth 2.0.

Récemment, nous avons reçu plusieurs questions de nos clients demandant des conseils ou un support pour implémenter le type de concession ROPC. Dans cet article, nous expliquerons pourquoi vous devriez éviter d'utiliser le type de concession ROPC, en particulier pour vos nouvelles applications.

Type de concession ROPC vs flux de code d'autorisation

Comment fonctionne le type de concession ROPC

Le type de concession ROPC est un flux simple qui échange le nom d'utilisateur et le mot de passe de l'utilisateur contre un jeton d'accès. L'application cliente collecte directement les informations d'identification de l'utilisateur et les envoie directement au serveur d'autorisation. Le serveur d'autorisation valide ensuite les informations d'identification et délivre un jeton d'accès au client.

Comment fonctionne le flux de code d'autorisation

En revanche, le flux de code d'autorisation est le flux OAuth 2.0 recommandé pour les applications web. Il implique plusieurs étapes et redirections entre l'application cliente, le serveur d'autorisation, et le navigateur de l'utilisateur. Le flux de code d'autorisation est plus sécurisé car il ne dévoile pas les informations d'identification de l'utilisateur à l'application cliente.

Les principales différences entre le type de concession ROPC et le flux de code d'autorisation est que ROPC expose les informations d'identification de l'utilisateur à l'application cliente, tandis que le flux de code d'autorisation ne le fait pas. Les informations d'identification de l'utilisateur devraient être gardées confidentiellement au sein du serveur d'autorisation. Chaque fois qu'une application cliente demande une ressource au nom de l'utilisateur, elle devrait rediriger l'utilisateur vers le serveur d'autorisation pour authentifier et autoriser l'application cliente. Cela maintient une quantité minimale de données d'autorisation du côté de l'application cliente.

Risques de sécurité du type de concession ROPC

1. Exposition des informations d'identification de l'utilisateur

Comme nous l'avons mentionné plus tôt, le type de concession ROPC expose les informations d'identification de l'utilisateur à l'application cliente. C'est un risque de sécurité significatif car l'application cliente peut stocker ou enregistrer les informations d'identification de l'utilisateur, et être réautorisée sans que l'utilisateur en soit conscient.

En particulier pour une application cliente publique comme une application mobile ou une application à une seule page, l'application cliente peut être facilement injectée ou rétro-ingénierie pour extraire les informations d'identification de l'utilisateur. Ni une application mobile ni une application à une seule page exécutée sur le navigateur de l'utilisateur ne peuvent conserver les secrets de manière confidentielle. Ainsi, elles ne peuvent pas authentifier l'utilisateur sans exposer les informations d'identification de l'utilisateur.

Même si le propriétaire de la ressource a une relation de confiance avec l'application cliente, l'application cliente joue un rôle d'homme du milieu dans tout le processus d'authentification, elle pourrait être compromise par un autre acteur malveillant. L'acteur malveillant peut voler les informations d'identification de l'utilisateur et usurper l'identité de l'utilisateur pour accéder aux ressources de l'utilisateur.

Il existe plusieurs façons de voler les informations d'identification de l'utilisateur, en fonction de la posture de sécurité de l'application cliente, comme les enregistreurs de frappe, les attaques par hameçonnage, ou les logiciels malveillants. Sans mentionner que les informations d'identification du client sont transmises sur le réseau à chaque demande d'autorisation. Cela augmente encore plus le risque d'interception des informations d'identification.

Imaginez que vous ayez plusieurs applications utilisant le type de concession ROPC, le risque potentiel d'exposition des informations d'identification est multiplié.

2. Le ROPC ne supporte pas le consentement utilisateur

Le type de concession ROPC ne supporte pas le consentement utilisateur. Lorsque l'application cliente collecte directement les informations d'identification de l'utilisateur, ce dernier n'a pas la possibilité d'examiner et d'approuver l'accès de l'application cliente à ses ressources. C'est une violation de la vie privée et de la confiance de l'utilisateur.

Les utilisateurs devraient avoir le droit de décider quelle application cliente peut accéder à leurs ressources et pour combien de temps. En particulier pour les applications tierces, un mécanisme de consentement utilisateur est essentiel pour protéger les données du propriétaire des ressources et il est essentiel de se conformer aux réglementations de protection des données comme le RGPD.

3. Le ROPC ne supporte pas l'authentification multi-facteur

L'authentification multi-facteur (AMF) est une mise en œuvre de sécurité qui exige de l'utilisateur qu'il fournisse deux ou plusieurs facteurs de vérification pour accéder à ses ressources. Elle ajoute une couche de sécurité supplémentaire au processus d'authentification. Le type de concession ROPC ne supporte pas l'AMF. Au lieu de cela, il limite le processus d'authentification à un seul facteur, et la demande de jeton est uniquement basée sur les informations d'identification de l'utilisateur. Il est impossible de mettre en œuvre des mécanismes d'authentification par défi tels que le SMS OTP, l'email OTP, ou WebAuthn avec le type de concession ROPC.

Le ROPC n'est pas compatible avec les applications modernes

Le type de concession ROPC a été conçu pour prendre en charge les applications héritées qui ne pouvaient pas prendre en charge les systèmes IAM modernes tels que le Single Sign-On (SSO) ou les identités fédérées.

1. Le ROPC n'est pas compatible avec le SSO

Le Single Sign-On (SSO) est une architecture d'authentification moderne qui permet aux utilisateurs de se connecter une fois et d'accéder à plusieurs applications sans effort.

Un IdP centralisé joue un rôle crucial dans l'architecture SSO. Il gère la session d'authentification de l'utilisateur et délivre des jetons aux applications clientes. Les applications clientes n'ont pas besoin de recueillir directement les informations d'identification de l'utilisateur, et les informations d'identification de l'utilisateur sont gardées confidentiellement au sein de l'IdP.

Le type de concession ROPC ne prend pas en charge le SSO. Il exige que l'application cliente recueille directement les informations d'identification de l'utilisateur, ce qui brise l'architecture SSO. Il n'est pas compatible avec les systèmes SSO modernes comme OpenID Connect (OIDC) ou SAML.

2. Le ROPC n'est pas compatible avec les identités fédérées

Semblable à l'architecture SSO, les identités fédérées permettent aux utilisateurs d'utiliser leur identité existante pour accéder à plusieurs applications tierces. Un utilisateur peut associer plusieurs comptes sociaux comme Google, Facebook, ou Twitter à un IdP centralisé, et utiliser ces comptes sociaux pour s'authentifier auprès des applications clientes. Toutes les identités fédérées sont gérées par l'IdP, et les applications clientes ne sont pas informées des détails d'authentification de l'utilisateur sous-jacent.

Le type de concession ROPC, quant à lui, exige que l'application cliente collecte directement les informations d'identification de l'utilisateur. Cela limite la capacité de l'application cliente à prendre en charge les identités fédérées et expose les données d'identité de l'utilisateur à l'application cliente.

Conclusion

Le type de concession Resource Owner Password Credentials (ROPC) est un flux OAuth 2.0 hérité qui présente des risques de sécurité significatifs et devrait être déprécié. Il expose les informations d'identification de l'utilisateur à l'application cliente, ne prend pas en charge les mécanismes de sécurité modernes tels que l'AMF ou le SSO. Nous recommandons vivement d'éviter d'utiliser le type de concession ROPC pour vos applications. Si vous avez des systèmes d'authentification hérités qui dépendent du type de concession ROPC, envisagez de migrer vers des flux OAuth 2.0 plus sécurisés comme le flux de code d'autorisation ou le flux de concession des informations d'identification du client.

Contactez-nous si vous avez besoin d'aide pour intégrer un service d'authentification et d'autorisation d'utilisateurs sécurisé dans vos applications, ou pour migrer d'un système d'authentification basé sur mot de passe hérité vers un flux OAuth 2.0 plus sécurisé. Nous sommes là pour vous aider à construire des applications modernes et sécurisées.

Introduction#

Type de concession ROPC vs flux de code d'autorisation#

Comment fonctionne le type de concession ROPC#

Comment fonctionne le flux de code d'autorisation#

Risques de sécurité du type de concession ROPC#

1. Exposition des informations d'identification de l'utilisateur#

2. Le ROPC ne supporte pas le consentement utilisateur#

3. Le ROPC ne supporte pas l'authentification multi-facteur#

Le ROPC n'est pas compatible avec les applications modernes#

1. Le ROPC n'est pas compatible avec le SSO#

2. Le ROPC n'est pas compatible avec les identités fédérées#

Conclusion#

Introduction#

Type de concession ROPC vs flux de code d'autorisation#

Comment fonctionne le type de concession ROPC#

Comment fonctionne le flux de code d'autorisation#

Risques de sécurité du type de concession ROPC#

1. Exposition des informations d'identification de l'utilisateur#

2. Le ROPC ne supporte pas le consentement utilisateur#

3. Le ROPC ne supporte pas l'authentification multi-facteur#

Le ROPC n'est pas compatible avec les applications modernes#

1. Le ROPC n'est pas compatible avec le SSO#

2. Le ROPC n'est pas compatible avec les identités fédérées#

Conclusion#

Introduction

Type de concession ROPC vs flux de code d'autorisation

Comment fonctionne le type de concession ROPC

Comment fonctionne le flux de code d'autorisation

Risques de sécurité du type de concession ROPC

1. Exposition des informations d'identification de l'utilisateur

2. Le ROPC ne supporte pas le consentement utilisateur

3. Le ROPC ne supporte pas l'authentification multi-facteur

Le ROPC n'est pas compatible avec les applications modernes

1. Le ROPC n'est pas compatible avec le SSO

2. Le ROPC n'est pas compatible avec les identités fédérées

Conclusion

Introduction

Type de concession ROPC vs flux de code d'autorisation

Comment fonctionne le type de concession ROPC

Comment fonctionne le flux de code d'autorisation

Risques de sécurité du type de concession ROPC

1. Exposition des informations d'identification de l'utilisateur

2. Le ROPC ne supporte pas le consentement utilisateur

3. Le ROPC ne supporte pas l'authentification multi-facteur

Le ROPC n'est pas compatible avec les applications modernes

1. Le ROPC n'est pas compatible avec le SSO

2. Le ROPC n'est pas compatible avec les identités fédérées

Conclusion