Un serveur d'autorisation émet un jeton d'accès qu'un serveur de ressources accepte dans des conditions définies. Le client peut agir pour un utilisateur après autorisation déléguée ou pour son propre compte dans un flux machine-à-machine.
OAuth définit des rôles et des flux de protocole plutôt qu'un format de jeton unique ou un modèle de permission universel. Pour les applications orientées utilisateur, la pratique de sécurité actuelle privilégie le flux à code d'autorisation avec Proof Key for Code Exchange (PKCE). Les implémentations doivent lier les réponses au bon client et à la bonne URI de redirection, protéger les codes d'autorisation et les jetons de rafraîchissement, et garantir que les jetons d'accès ne sont acceptés que par les serveurs de ressources auxquels ils sont destinés.
Points clés
Rôles fondamentauxDistinguer le propriétaire de la ressource, le client, le serveur d'autorisation et le serveur de ressources ; documenter les cas où un composant joue plus d'un rôle.
Contrôles des jetonsRestreindre l'audience, la portée, la durée de vie et le stockage ; valider les jetons complètement ; renouveler ou révoquer les jetons de rafraîchissement lorsque c'est approprié ; et éviter d'exposer les jetons de porteur dans les URL ou les journaux.
Choix de flux actuelsSuivre la meilleure pratique de sécurité OAuth actuelle : les clients ne devraient pas utiliser le grant implicite sauf si ses risques spécifiés d'injection et de fuite sont mitigés, et ne doivent pas utiliser le grant de type resource owner password credentials.
Limite importanteOAuth 2.0 ne définit pas l'authentification de l'utilisateur et ne prouve pas qui utilise un jeton d'accès. Un jeton valide ne remplace pas non plus l'autorisation au niveau des objets, des fonctions ou des transactions au sein du serveur de ressources.