Type d'autorisation Password Credentials dans OAuth 2.0

Le type d'autorisation Password Credentials, souvent appelé flux "Resource Owner Password Credentials" (ROPC), est un moyen pour les utilisateurs de fournir directement leur nom d'utilisateur et leur mot de passe pour obtenir un token d'accès. Les recommandations de sécurité actuelles (RFC 9700) indiquent que ce type d'autorisation NE DOIT PAS être utilisé, car l'application cliente voit le mot de passe de l'utilisateur. Il existe encore dans d'anciens systèmes, vous pouvez donc le rencontrer en en testant un.

Ce que vous saisissez dans LoadFocus

Dans un test de charge, définissez Type d'autorisation sur OAuth 2.0 et Grant Type sur Password Credentials. Le formulaire comporte ces champs :

• Token Name : un libellé pour vous. Il n'est pas envoyé au serveur.
• Access Token URL : le point de terminaison de token du fournisseur.
• Username, Password : le compte pour lequel le token est demandé. Utilisez un compte de test dédié, pas un compte personnel.
• Client ID, Client Secret, Scope, Audience : tels que délivrés par votre fournisseur ou convenus avec lui (Audience est propre à chaque fournisseur).

Avant le début du test, LoadFocus envoie une requête POST en HTTPS à l'Access Token URL, avec les champs ci-dessus comme corps JSON, et lit access_token dans la réponse JSON. La RFC 6749 décrit un corps encodé en formulaire : si votre fournisseur rejette la requête, vérifiez donc si son point de terminaison de token accepte le JSON.

Comment fonctionne Password Credentials ?

1. Saisie de l'utilisateur :

• L'utilisateur fournit son nom d'utilisateur et son mot de passe directement à l'application cliente.

2. Demande du token :

• Le client envoie ensuite ces identifiants au point de terminaison de token du serveur d'autorisation. Cette requête inclut également généralement le client_id et le client_secret du client, bien que certaines implémentations puissent ne pas exiger le secret client pour ce flux.

3. Réponse du token :

• Si les identifiants sont valides, le serveur d'autorisation répond avec un token d'accès (et éventuellement un token de rafraîchissement). Le client peut ensuite utiliser ce token pour effectuer des requêtes au nom de l'utilisateur auprès du serveur de ressources.

Comment configurer Password Credentials ?

1. Enregistrer votre application :

• Comme pour les autres flux OAuth 2.0, commencez par enregistrer votre application auprès du fournisseur OAuth 2.0. Vous recevrez généralement un client_id et un client_secret après l'enregistrement.

2. Mécanisme de saisie :

• Implémentez un mécanisme dans votre application cliente où les utilisateurs peuvent saisir leur nom d'utilisateur et leur mot de passe. Cela pourrait être un simple formulaire de connexion.

3. Requête de token :

• Lorsque les utilisateurs fournissent leurs identifiants, votre application doit effectuer une requête POST au point de terminaison de token du serveur d'autorisation. Cette requête doit inclure le grant_type (défini sur "password"), le username, le password, le client_id et éventuellement le client_secret. Assurez-vous que cette requête est effectuée de manière sécurisée en utilisant HTTPS.

4. Gérer la réponse du token :

• Si les identifiants sont corrects, le serveur d'autorisation répondra avec un token d'accès, que votre application doit stocker de manière sécurisée. Optionnellement, vous pourriez également recevoir un token de rafraîchissement, qui peut être utilisé pour obtenir de nouveaux tokens d'accès lorsque celui en cours expire.

5. Utiliser le token :

• Comme avec les autres types d'autorisation, une fois que vous avez un token d'accès, vous pouvez l'utiliser pour effectuer des requêtes autorisées au serveur de ressources au nom de l'utilisateur.

6. Renouvellement du token :

• Si vous avez reçu un token de rafraîchissement et que le token d'accès expire, utilisez le token de rafraîchissement pour obtenir un nouveau token d'accès sans redemander les identifiants à l'utilisateur.

Considérations :

• Préoccupations de sécurité : Ce type d'autorisation implique le partage du mot de passe réel avec le client, ce qui représente un risque de sécurité important. Il est essentiel de s'assurer que le client est entièrement digne de confiance.

• Ne pas l'utiliser pour de nouveaux systèmes : la RFC 9700 indique que ce type d'autorisation NE DOIT PAS être utilisé. Si vous maîtrisez le système, passez au type Authorization Code (avec PKCE), ou à Client Credentials pour les appels de service à service.

Conclusion :

Le type d'autorisation Password Credentials est simple, mais il expose le mot de passe de l'utilisateur au client et les recommandations actuelles déconseillent de l'utiliser. Ne l'utilisez dans un test que si le système testé l'exige encore, et limitez les identifiants à un compte de test dédié.