Présentation d'OAuth 2.0

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d'Apigee Edge.

Accueil OAuth : Consultez la page d'accueil OAuth pour obtenir une vue d'ensemble de nos conseils à son sujet.

Cet article offre un bref aperçu d'OAuth 2.0 sur Apigee.

Qu'est-ce que OAuth 2.0 ?

De nombreux livres, blogs et sites sont dédiés à OAuth 2.0. Nous vous recommandons vivement de commencer par consulter la spécification IETF OAuth 2.0. Voici la définition du protocole OAuth 2.0 selon la spécification IETF OAuth 2.0 :

"Le framework d'autorisation OAuth 2.0 permet à une application tierce d'obtenir un accès limité à un service HTTP, soit pour le compte d'un propriétaire de ressource en orchestrant une interaction d'approbation entre le propriétaire de la ressource et le service HTTP, soit en autorisant l'application tierce à obtenir l'accès en son nom."

Vous devez savoir que OAuth 2.0 permet aux applications d'obtenir un accès limité aux ressources protégées d'un utilisateur (pensez à un compte bancaire ou toute autre information sensible à laquelle un utilisateur pourrait souhaiter accéder à partir d'une application) sans que l'utilisateur ait besoin de divulguer ses identifiants de connexion à l'application.

Le flux OAuth 2.0

Voici le flux général du framework de sécurité OAuth 2.0. Nous aborderons ce sujet plus en détail dans cette rubrique, en commençant par un schéma illustrant de manière détaillée le fonctionnement d'OAuth 2.0. Si vous ne connaissez pas les termes utilisés dans ce schéma, lisez cette section pour une présentation rapide.

Flux général du framework de sécurité OAuth 2.0.

Termes que vous devez connaître

  • Client : également appelé application. Il peut s'agir d'une application s'exécutant sur un appareil mobile ou une application Web traditionnelle. L'application envoie des requêtes au serveur de ressources pour les éléments protégés au nom du propriétaire de la ressource. Le propriétaire de la ressource doit autoriser l'application à accéder aux ressources protégées.
  • Propriétaire de la ressource : également appelé utilisateur final. Il s'agit généralement de la personne (ou d'une autre entité) capable d'accorder l'accès à une ressource protégée. Par exemple, si une application doit utiliser des données provenant de l'un de vos sites de réseaux sociaux, vous le propriétaire de la ressource, c'est-à-dire la seule personne pouvant accorder à l'application l'accès à vos données.
  • Serveur de ressources : considérez le serveur de ressources comme un service équivalent à Facebook, Google ou Twitter, un service de RH sur votre intranet, ou encore un service partenaire sur votre extranet B2B. Apigee est un serveur de ressources chaque fois que la validation du jeton OAuth est requise pour traiter les requêtes API. Le serveur de ressources nécessite un type d'autorisation avant de pouvoir diffuser des ressources protégées à l'application.
  • Serveur d'autorisation  : le serveur d'autorisation est mis en œuvre conformément à la spécification OAuth 2.0. Il est responsable de la validation des attributions d'autorisations et l'émission des des jetons d'accès qui permettent à l'application d'accéder aux données de l'utilisateur sur le serveur de ressources. Vous pouvez configurer des points de terminaison de jeton sur Apigee, auquel cas Apigee prend le rôle de serveur d'autorisation.
  • Attribution d'autorisation : autorise l'application à récupérer un jeton d'accès au nom de l'utilisateur final. OAuth 2.0 définit quatre "types d'attribution" spécifiques. Consultez la section Que sont les types d'attribution OAuth 2.0 ?.
  • Jeton d'accès : longue chaîne de caractères servant d'identifiant utilisé pour accéder aux ressources protégées. Consultez la section Qu'est-ce qu'un jeton d'accès ?.
  • Ressource protégée : données appartenant au propriétaire de la ressource. Par exemple, la liste de contacts, les informations de compte ou d'autres données sensibles de l'utilisateur.

Où s'intègre Apigee ?

Vous pouvez protéger n'importe quelle API transmise par proxy via Apigee avec OAuth 2.0. Apigee inclut une mise en œuvre de serveur d'autorisation et, à ce titre, peut générer et valider des jetons d'accès. Les développeurs commencent par enregistrer leurs applications avec Apigee. Les applications enregistrées peuvent demander des jetons d'accès via l'une des quatre interactions de type d'attribution.

Apigee fournit une règle OAuthV2 multiforme qui met en œuvre les détails de chaque type d'attribution, facilitant ainsi la configuration d'OAuth sur Apigee. Par exemple, vous pouvez configurer une règle qui reçoit une requête de jeton d'accès, évalue tous les identifiants requis et renvoie un jeton d'accès si les identifiants sont valides.

Notez que tous les serveurs de ressources que votre proxy d'API sécurisé appelle doivent être protégés par un pare-feu (autrement dit, les ressources ne doivent pas être accessibles par un moyen autre que le proxy d'API ou une autre API bien sécurisée).

Que sont les types d'attribution OAuth 2.0 ?

Considérez les types d'attribution comme des chemins ou des interactions gérés par une application afin d'obtenir un jeton d'accès. Chaque type d'attribution répond à un ou plusieurs cas d'utilisation. Vous devez sélectionner les types d'attribution à utiliser en fonction de vos propres besoins. En règle générale, chaque type d'attribution présente des avantages et des inconvénients, et vous devez peser le pour et le contre en fonction de vos cas d'utilisation et activités. Il est important de considérer la fiabilité des applications qui accéderont à vos données. En règle générale, les applications tierces sont moins fiables que les applications développées et utilisées au sein d'une entreprise.

Apigee est compatible avec les quatre principaux types d'attribution OAuth 2.0 :

  • code d'autorisation : considéré comme le type d'attribution le plus sécurisé. Avant que le serveur d'autorisation puisse émettre un jeton d'accès, l'application doit d'abord recevoir un code d'autorisation du serveur de ressources. Vous voyez ce flux chaque fois que votre application ouvre un navigateur sur la page de connexion du serveur de ressources et vous invite à vous connecter à votre compte réel (par exemple, Facebook ou Twitter).

Si vous parvenez à vous connecter, l'application reçoit un code d'autorisation permettant de négocier un jeton d'accès avec le serveur d'autorisation. En règle générale, ce type d'attribution est utilisé lorsque l'application réside sur un serveur plutôt que sur le client. Ce type d'attribution est considéré comme hautement sécurisé, car l'application cliente ne gère ni ne voit jamais le nom d'utilisateur ou le mot de passe de l'utilisateur pour le serveur de ressources (par exemple, l'application ne voit jamais et ne gère jamais vos identifiants Twitter). Ce flux de type d'attribution est également appelé autorisation OAuth à trois acteurs.

  • implicite : considéré comme une version simplifiée du code d'autorisation. En règle générale, ce type d'attribution est utilisé lorsque l'application réside sur le client. Par exemple, le code de l'application est mis en œuvre dans un navigateur à l'aide de JavaScript ou d'un autre langage de script (au lieu de résider et de s'exécuter sur un serveur Web distinct). Dans ce flux de type d'attribution, le serveur d'autorisation renvoie un jeton d'accès directement lorsque l'utilisateur est authentifié, au lieu d'émettre d'abord un code d'autorisation. Les attributions implicites peuvent améliorer la réactivité des applications dans certains cas, mais cet avantage doit être mesuré face aux conséquences potentielles sur la sécurité, comme décrit dans la spécification IETF.
  • Identifiants de mots de passe des propriétaires de ressources : dans ce flux, le client reçoit un jeton d'accès lorsque le nom d'utilisateur/mot de passe de l'utilisateur est validé par le serveur d'autorisation. Ce flux est recommandé pour les applications hautement approuvées. L'avantage de ce flux sur, par exemple, l'authentification de base, est que l'utilisateur ne présente son nom d'utilisateur/mot de passe qu'une seule fois. Dès lors, le jeton d'accès est utilisé.
  • identifiants client : envisageables dans les cas où l'application cliente agit en son propre nom. Autrement dit, le client est également le propriétaire de la ressource. Ce type d'attribution est généralement utilisé lorsque l'application doit accéder à un service de stockage de données backend, par exemple. L'application doit utiliser le service pour fonctionner, autrement le service est opaque pour l'utilisateur final. Avec ce type d'attribution, une application peut recevoir un jeton d'accès en présentant l'ID client et les clés secrètes du client au serveur d'autorisation. Aucune autre étape n'est requise. Apigee fournit une solution d'identifiants client prête à l'emploi, facile à mettre en œuvre pour n'importe quel proxy d'API.

Qu'est-ce qu'un jeton d'accès ?

Un jeton d'accès est une longue chaîne de caractères servant d'identifiants utilisés pour accéder aux ressources protégées. Les jetons de ressource (également appelés jetons de support) sont transmis dans les en-têtes d'autorisation, comme suit :

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

Le serveur de ressources comprend que le jeton d'accès se substitue aux identifiants tels que le nom d'utilisateur et le mot de passe. En outre, les jetons d'accès peuvent être émis avec des restrictions, de sorte que l'application puisse par exemple lire, mais pas écrire ou supprimer des données sur le serveur de ressources. Notez qu'un jeton d'accès peut être révoqué si, par exemple, l'application est compromise. Dans ce cas, vous devez obtenir un nouveau jeton d'accès pour continuer à utiliser l'application. Toutefois, il n'est pas nécessaire de modifier votre nom d'utilisateur ou votre mot de passe sur le serveur de ressources protégées (par exemple, Facebook ou Twitter).

Les jetons d'accès possèdent généralement un délai d'expiration (pour des raisons de sécurité). Certains types d'autorisations permettent au serveur d'autorisation d'émettre un jeton d'actualisation, ce qui permet à l'application de récupérer un nouveau jeton d'accès lorsque l'ancien est arrivé à expiration. Pour en savoir plus sur les jetons d'accès et d'actualisation, consultez la spécification IETF OAuth 2.0.

Accès limité via des champs d'application

Grâce au mécanisme de champs d'application, OAuth 2.0 peut accorder à une application un accès limité aux ressources protégées. Par exemple, une application peut avoir accès uniquement à des ressources spécifiques, être en mesure de mettre à jour des ressources ou disposer uniquement d'un accès en lecture seule. Sous les flux OAuth d'autorisation OAUTH à trois acteurs, l'utilisateur spécifie généralement le niveau d'accès via une page d'autorisation (par exemple, une page Web où l'utilisateur sélectionne le niveau d'accès avec une case à cocher ou un autre mécanisme).

Enregistrer une application

Tous les clients (applications) doivent s'enregistrer auprès du serveur d'autorisation OAuth 2.0 depuis lequel ils ont l'intention de demander des jetons d'accès. Lorsque vous enregistrez une application, vous recevez un ensemble de clés. L'une est une clé publique appelée "identifiant du client", et l'autre est une clé secrète appelée "code secret du client". Sans ces clés, une application ne peut pas émettre de demandes de codes d'autorisation ni de jetons d'accès au serveur d'autorisation. Notez que même si la spécification OAuth IETF appelle ces clés "ID du client" et "code secret du client", l'interface utilisateur d'Apigee les appelle "ID du consommateur" et "code secret du consommateur". Ils sont équivalents.

Résumé des cas d'utilisation d'OAuth 2.0

Le flux de type d'attribution OAuth 2.0 que vous avez choisi de mettre en œuvre dépend de votre cas d'utilisation spécifique, car certains types d'autorisations sont plus sécurisés que d'autres. Le choix des types d'attribution dépend de la fiabilité de l'application cliente et nécessite une attention toute particulière, comme décrit dans le tableau suivant :

Cas d'utilisation Fiabilité Types d'attribution d'autorisation OAuth 2.0 suggérés Description
B2B (extranet), intranet, autre

Applications hautement fiables, écrites par un développeur interne ou des développeurs ayant une relation commerciale de confiance avec le fournisseur d'API.

Applications qui ont besoin d'accéder aux ressources en leur propre nom.
  • Identifiants client
  • En règle générale, l'application est également le propriétaire des ressources
  • Nécessite l'ID client et les clés secrètes du client
  • Nécessite que l'application soit enregistrée auprès du fournisseur de services
Sites intranet, portails

Applications fiables écrites par des développeurs internes ou des tiers de confiance.

Un bon exemple consiste à se connecter au site de RH de votre entreprise pour sélectionner des assurances, soumettre des avis ou modifier des informations personnelles.
  • Mot de passe
  • Implicite
  • Requiert l'ID et le code secret du client, ainsi que le nom d'utilisateur et le mot de passe
  • Nécessite que l'application soit enregistrée auprès du fournisseur de services
Applications accessibles au public Les applications non approuvées sont écrites par des développeurs tiers qui n'ont pas de relation commerciale de confiance avec le fournisseur d'API. Par exemple, les développeurs inscrits à des programmes d'API publics ne doivent généralement pas être approuvés.
  • Code d'autorisation
  • Nécessite que l'utilisateur se connecte à un fournisseur de ressources tiers (par exemple, Twitter, Facebook)
  • L'application ne voit jamais le nom d'utilisateur et le mot de passe de l'utilisateur
  • Nécessite que l'application soit enregistrée auprès du fournisseur de services
B2C Un utilisateur final individuel (utilisateur mobile) est impliqué, et les identifiants utilisateur sont stockés sur l'appareil mobile.
  • Implicite
  • Nécessite que l'application soit enregistrée auprès du fournisseur de services.
  • Les identifiants utilisateur sont stockés sur l'appareil qui exécute l'application.

Différences entre sécurité OAuth 2.0 et clés API

La validation des clés API nécessite qu'une application envoie une clé à Apigee. La clé doit être une clé client valide provenant d'une application de développeur Apigee associée au proxy d'API. Si, pour une raison quelconque, vous devez révoquer l'autorisation d'une application cliente pour appeler un proxy, vous devez révoquer cette clé client. Les applications clientes utilisant cette clé ne pourront pas non plus accéder au proxy d'API. En revanche, un jeton OAuth peut être révoqué à tout moment sans révoquer les clés de l'application. L'application peut simplement demander un nouveau jeton au nom de l'utilisateur et, si un jeton est accordé, l'application peut continuer à utiliser le proxy d'API.

Une autre différence entre une clé API et un jeton est qu'un jeton peut inclure des attributs de métadonnées que vous pouvez récupérer et utiliser ultérieurement. Par exemple, vous pouvez stocker l'ID de l'utilisateur effectuant l'appel d'API et l'utiliser pour personnaliser les appels au service cible du backend.

Pour en savoir plus sur la validation des clés API, consultez la section Clés API. Pour en savoir plus sur l'utilisation des attributs personnalisés avec des jetons OAuth, consultez la section Personnaliser les jetons et les codes d'autorisation.

Impact de l'expiration et des délais de purge des jetons sur le stockage sur disque

Lorsque vous générez un nouveau jeton OAuth avec la stratégie OAuthV2, vous pouvez définir un délai d'expiration pour le jeton à l'aide de l'attribut ExpiresIn. Par défaut, les jetons sont supprimés de l'espace de stockage trois jours après leur expiration. Si vous définissez un délai d'expiration long, par exemple 48 heures, vous pouvez constater une augmentation inattendue de l'espace disque utilisé par Cassandra. Pour éviter d'utiliser trop d'espace disque, vous pouvez définir une durée d'expiration plus courte (une heure est recommandée) et/ou une configuration qui remplace le délai post-expiration de trois jours par une période plus courte.

Les clients Apigee hybrid peuvent modifier le délai de purge par défaut en définissant la configuration suivante dans leur fichier de remplacement:

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "SECONDS"

Où SECONDS correspond au nombre de secondes pendant lesquelles Apigee attendra de purger les jetons après leur expiration. Veillez à inclure cette strophe exactement comme elle est écrite, y compris les guillemets.

Par exemple, pour définir le délai de purge sur une heure après l'expiration:

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "3600"

Ressources recommandées

Lecture

Consultez la section En savoir plus sur OAuth 2.0.