Autorisation OAuth 2.0
OAuth 2.0 est un framework d'autorisation (RFC 6749) permettant d'accorder l'accès à des ressources protégées. Il permet aux applications tierces d'accéder aux données des utilisateurs sans exposer les identifiants de l'utilisateur. Au lieu de partager des mots de passe, les services fournissent des tokens.
Si votre fournisseur émet des jetons d'accès JWT, le décodeur JWT gratuit montre ce que contient un jeton, comme ses scopes et son expiration.
Contexte
Imaginez que vous souhaitiez utiliser une application tierce qui a besoin d'accéder aux données de votre compte Google. Vous ne voudriez pas fournir à cette application tierce votre nom d'utilisateur et mot de passe Google, n'est-ce pas ? C'est là qu'OAuth intervient. Il vous permet d'accorder à cette application l'accès à vos données Google sans partager vos identifiants Google.
Bases d'OAuth 2.0
OAuth 2.0 se concentre sur la simplicité pour le développeur client tout en fournissant des flux d'autorisation spécifiques pour les applications web, les applications de bureau, les téléphones mobiles et les appareils domestiques. Voici une décomposition simplifiée :
Propriétaire de la ressource : L'utilisateur qui autorise une application à accéder à son compte. L'accès de l'application au compte de l'utilisateur est limité au "scope" de l'autorisation accordée (par exemple, lecture ou écriture d'un type spécifique de données).
Client : L'application qui souhaite accéder au compte de l'utilisateur. Avant de pouvoir le faire, elle doit être autorisée par l'utilisateur et l'autorisation doit être validée par l'API.
Serveur de ressources : Le serveur hébergeant les comptes utilisateur. Il peut accepter et répondre aux requêtes de ressources protégées en utilisant des tokens d'accès.
Serveur d'autorisation : Ce serveur vérifie l'identité de l'utilisateur puis émet des tokens d'accès à l'application.
Flux OAuth 2.0
Il existe plusieurs "flux" ou "types d'autorisation" pour différents types d'applications et cas d'utilisation :
Authorization Code (pour les applications exécutées sur un serveur web) : C'est le flux le plus courant, en particulier pour les applications web. Il implique de rediriger l'utilisateur vers le service, où il se connecte. Après la connexion, il est redirigé vers l'application avec un code d'autorisation, que l'application peut échanger contre un token d'accès.
Implicit (obsolète, pour les applications exécutées dans un navigateur) : Le token d'accès est renvoyé immédiatement, sans étape d'échange de code d'autorisation. Les recommandations de sécurité actuelles (RFC 9700) le déconseillent ; utilisez plutôt le flux Authorization Code lorsque c'est possible.
Resource Owner Password Credentials (obsolète) : L'application envoie directement le nom d'utilisateur et le mot de passe de l'utilisateur au serveur d'autorisation. Cela va à l'encontre de l'objectif d'OAuth (l'application voit le mot de passe) et les recommandations de sécurité actuelles (RFC 9700) déconseillent de l'utiliser pour de nouveaux systèmes.
Client Credentials : Aucun utilisateur n'intervient. Le client s'authentifie lui-même pour obtenir un token, par exemple un service en arrière-plan qui appelle une API.
Tokens
Au lieu d'utiliser les identifiants de l'utilisateur, OAuth 2.0 utilise des tokens. Il en existe deux types :
Token d'accès : Permet à l'application d'effectuer des requêtes API au nom de l'utilisateur. Il a généralement une courte durée de vie.
Token de rafraîchissement : Facultatif. Peut être utilisé pour obtenir un nouveau token d'accès lorsque celui-ci a expiré, afin que l'utilisateur n'ait pas à se reconnecter.
Sécurité
OAuth 2.0 repose sur TLS pour protéger les tokens et les identifiants entre le client, le serveur d'autorisation et le serveur de ressources. Les tokens d'accès sont généralement des bearer tokens : celui qui en possède un peut l'utiliser. Des durées de vie courtes et des scopes étroits limitent les dégâts en cas de fuite, alors gardez les tokens hors des logs et des URL.
OAuth 2.0 dans LoadFocus
Pour tester en charge une API protégée par OAuth 2.0, ouvrez Plus d'options dans le formulaire de nouveau test, cliquez sur Autorisation (s'applique à chaque requête), définissez Type d'autorisation sur OAuth 2.0 et choisissez le Grant Type utilisé par votre API : Authorization Code, Implicit, Password Credentials, Client Credentials ou Refresh Token. Si vous ne savez pas lequel, lisez Qu'est-ce qu'un type d'autorisation (Grant Type) ?. Chaque type a son propre guide, par exemple Client Credentials et Authorization Code.