Les API donnent accès aux applications et aux données des entreprises. Ces accès sont précieux pour les employés, les partenaires, les clients mais aussi les hackers ! Cet article vous explique comment sécuriser vos API avec OAuth2.
La sécurité des API passe par le contrôle des accès. Chaque utilisateur, logiciel ou application est identifié pour être autorisé à consommer les ressources des API. Les méthodes d’authentification les mieux adaptés aux API REST sont OAuth2 & OpenId Connect.
Qu’est-ce que OAuth2 ?
Pour définir le concept : « OAuth est un protocole libre, créé par Blaine Cook et Chris Messina, qui permet d’autoriser un site web, un logiciel ou une application (dite « consommateur ») à utiliser l’API sécurisée d’un autre site web (dit « fournisseur ») pour le compte d’un utilisateur. OAuth n’est pas un protocole d’authentification, mais de « délégation d’autorisation ».
OAuth2 permet de mettre en place une délégation d’autorisation pour accorder à une application tierce (client application) avec un accès limité sur une ressource (ressource server), avec le consentement du propriétaire de celle-ci (ressource owner).
Les rôles OAuth2
OAuth2 définit 4 rôles distincts :
- Resource Owner : L’utilisateur qui a les privilèges sur les données (ex : votre compte bancaire)
- Resource Server : Le serveur qui stocke les données d’une manière sécurisée (ex : le serveur de votre banque)
- Client Application : L’application consommatrice de la ressource (ex : application mobile)
- Authorization Server : Le serveur qui délivre les access token à l’application cliente.
L’utilisation de OAuth2
Le fonctionnement général d’une ressource ou API sécurisée par OAuth2 est le suivant :
- Authentification :
- L’application cliente demande au serveur d’autorisation un jeton (= Access Token) en échange de son identifiant (clientId) et éventuellement son secret (clientSecret). C’est aussi à cette étape que l’utilisateur peut être authentifié
- Le serveur d’autorisation vérifie les données de l’application (et de l’utilisateur s’il y en a un)
- Il délivre à l’application cliente un Access Token qui servira de preuve d’authentification
- Consommation de la ressource (une fois que l’application cliente a obtenu son Access Token)
- Dans une autre requête, l’application transmet l’Access Token au serveur de ressources
- Le serveur de ressources vérifie que l’Access Token est valide et que ses privilèges sont suffisants pour accéder à la ressource
- Le serveur de ressources envoie les données de la ressource à l’application cliente
Pour éviter de demander régulièrement à l’utilisateur de saisir son login et mot de passe, OAuth2 prévoit le renouvellement de l’Access Token à l’aide d’un Refresh Token. OAuth2 prévoie aussi la révocation du Token (à utiliser par exemple à la déconnexion de l’utilisateur).
OAuth2 a défini 4 cinématiques pour répondre à différents cas d’usage. Nous allons expliquer le fonctionnement de chacune.
Authorization Code Grant
L’Authorization Code Grant permet une authentification de l’utilisateur final (ou Ressource Owner) et de l’application consommatrice (ou Client), sans communiquer les identifiants (compte utilisateur et mot de passe) de l’utilisateur final.
Ce mode d’authentification est le plus sécurisé. Il nécessite d’avoir une mire d’authentification et permet de bloquer un utilisateur en cas d’accès frauduleux.Il est à privilégier pour l’autorisation des clients tiers en capacité de conserver un « client_secret », par exemple les applications web exécutées sur le serveur.
Implicit Grant
L’Implicit Grant permet une authentification de l’utilisateur final (ou Ressource Owner) et de l’application consommatrice, sans communiquer les identifiants (login et mot de passe) de l’utilisateur final.
Ce mode d’authentification est moins sécurisé que le l’Authorization Code Grant car il n’utilise pas de mire d’authentification. Il est à privilégier pour les applications qui ne peuvent pas stocker un client_secret, par exemple les applications Javascript.
Password Grant
Le Resource Owner Password Grant permet une authentification de l’utilisateur final (ou Ressource Owner) et de l’application consommatrice (ou Client). Cependant, le Client connait les identifiants de l’utilisateur final.
Ce mode d’authentification est conçu pour les applications consommatrices de confiance en mesure de stocker un secret. Il est donc adapté aux applications web exécutées sur un serveur interne ou par un partenaire de confiance. Il peut être utilisé afin de réduction du nombre d’appels nécessitant l’Authorization Code Grant.
Client Credentials Grant
Le Client Credential Grant permet une authentification de l’application consommatrice (ou Client). L’identité de l’utilisateur final n’est pas connue.
Ce mode d’authentification est conçu pour les applications consommatrices de confiance en mesure de stocker un secret. Il est donc adapté aux applications web exécutées sur un serveur tant que l’authentification se fait au niveau de l’application et pas de l’utilisateur final.
Qu’est-ce que OpenId Connect ?
OpenId Connect (ou OIDC) consiste en une simple couche d’identification basée sur OAuth 2.0. Ce protocole permet de vérifier l’identité d’un utilisateur auprès d’un serveur d’autorisation afin d’obtenir des informations sur cet utilisateur. Les opérations sont réalisées via des web services REST et les données sont échangées au format JSON. OpenID Connect a été conçu pour répondre aux limites de OAuth2 dans le domaine de l’authentification forte. L’objectif est de permettre à des sites tiers d’obtenir une identité de façon plus sécurisée que ne peut le faire OAuth2.
Un accès via un token OAuth2 est mis en place quand un contexte utilisateur est nécessaire. Par exemple, dans les applications mobiles où l’utilisateur et l’application peuvent accéder à un ensemble de ressources prédéfinies telles que des informations personnelles de l’utilisateur ou autres données en provenance du Système d’Information.
Maintenant que vous savez comment sécuriser vos API, il ne vous reste plus qu’à les exposer en tout sécurité!
Vous avez des question sur OAuth2 ou comment sécuriser vos API ? Vous souhaitez être accompagnés ? Contactez-nous
Publié le 22/10/20
Partagez cet article :