Cette page a été traduite par l'API Cloud Translation.

OAuth

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

OAuth s'est imposé comme le principal protocole d'autorisation pour les API. La version que nous aborderons en détail dans cette rubrique, est défini dans la 2.0 Spécification.

OAuth est un protocole qui permet aux utilisateurs finaux d'applications d'autoriser applications pour qu'elles agissent en leur nom. Les applications le font en obtenant un accès de jetons provenant des fournisseurs d'API. Le fournisseur d'API authentifie l'extrémité de l'application identifiants de l'utilisateur, s'assurer que celui-ci a autorisé l'application, puis émet un jeton d'accès à l'application. Lorsque l'application utilise une API protégée, Apigee Edge vérifie le jeton d'accès pour s'assurer qu'il est valide et qu'il n'a pas expiré. En tant que fournisseur d'API, vous devez exposer des points de terminaison permettant aux applications d'obtenir des jetons d'accès.

Pour faciliter l'utilisation du protocole OAuth, Apigee Edge vous permet de configurer et d'appliquer OAuth à l'aide de règles, sans que vous ayez à à écrire n'importe quel code. Dans cette rubrique, vous apprendrez à protéger vos API, à obtenir l'accès et comment les utiliser pour accéder à des API protégées.

La configuration OAuth par défaut organisation

Pour plus de commodité, toutes les organisations sur Apigee Edge sont livrées avec un ensemble d'authentifications OAuth 2.0 préconfigurées. points de terminaison qui implémentent le type d'attribution des identifiants client. Le client Le type d'octroi des identifiants définit une procédure pour émettre des jetons d'accès en échange de identifiants. Ces identifiants d'application sont simplement la paire clé/code secret client Problèmes Apigee Edge pour chaque application enregistrée dans une organisation. "Client credentials" (Identifiants client) fait référence à la clé client et à la paire secrète elle-même.

Pour en savoir plus sur l'émission d'identifiants aux applications à l'aide de Edge Developer Services, consultez Enregistrer des applications et gérer les clés

Pour cette raison, il est relativement simple de "passer à la vitesse supérieure" votre schéma de sécurité des API à partir de la clé API aux identifiants client OAuth. Les deux schémas utilisent la même clé et le même secret client pour valider l'application cliente. La différence est que les identifiants client fournissent une couche supplémentaire car vous pouvez facilement révoquer un jeton d'accès en cas de besoin, sans que vous ayez à le révoquer la clé client de l'application. Pour utiliser les points de terminaison OAuth par défaut, vous pouvez utiliser n'importe quelle clé client et le secret générés pour que l'application de votre organisation récupère les jetons d'accès à partir du jeton point de terminaison unique. Vous pouvez même activer les identifiants client pour les applications disposant déjà de clés secrets.)

La spécification complète de l'attribution des identifiants client est disponible dans le document OAuth 2.0 Spécification.

Protéger votre API à l'aide d'une règle

Avant de pouvoir utiliser les jetons d'accès, vous devez configurer vos API afin de valider l'accès OAuth de jetons au moment de l'exécution. Pour ce faire, vous configurez un proxy d'API pour valider des jetons d'accès. Cela signifie que chaque fois qu'une application envoie une requête utiliser l'une de vos API, l'application doit présenter un jeton d'accès valide avec la requête API. Apigee Edge gère la complexité liée à la génération, au stockage et à la validation des jetons d'accès. qui sont présentées.

Vous pouvez facilement ajouter la validation OAuth à une API lorsque vous créez un nouveau proxy d'API. Lorsque vous créez un proxy d'API, vous pouvez ajouter des fonctionnalités. En tant que ci-dessous, vous pouvez ajouter une validation des jetons d'accès OAuth 2.0 en sélectionnant la case d'option à côté de l'option Sécuriser avec des jetons d'accès OAuth v2.0. Lorsque vous sélectionnez cette option, des stratégies seront attachées au proxy d'API nouvellement créé, l'une pour vérifier les jetons d'accès et l'autre de supprimer le jeton d'accès une fois qu'il a été validé.

De plus, lorsque vous sélectionnez l'option Sécuriser avec des jetons d'accès OAuth v2.0, la case Publier un produit d'API peut être sélectionnée et est automatiquement sélectionnée. Cochez cette case si vous souhaitez générer automatiquement un produit lorsque vous créez la nouvelle API proxy. Le produit généré automatiquement sera créé avec une association au nouveau proxy d'API. Si vous si vous souhaitez associer cette nouvelle API à un produit existant, assurez-vous de supprimer afin de ne pas créer de produit inutile. Pour en savoir plus sur les produits, consultez Qu'est-ce qu'un produit API ?

Si vous devez activer la vérification des jetons d'accès pour le proxy d'API qui existe déjà, il vous suffit d'associer une stratégie de type OAuthV2 à l'API que vous que vous voulez protéger. Les stratégies OAuthV2 fonctionnent en spécifiant une opération. Si vous voulez Pour valider les jetons d'accès, spécifiez l'opération appelée VerifyAccessToken. (Les autres types d'opérations compatibles avec le type de règle OAuthV2 sont GenerateAccessToken et GenerateRefreshToken. Vous découvrirez ces opérations lorsque vous configurerez points de terminaison OAuth).

Règle VerifyOAuthTokens de type OAuthV2

Voici un exemple de stratégie permettant de valider les jetons d'accès. (Les paramètres sont expliqué dans le tableau ci-dessous.)

<OAuthV2 name="VerifyOAuthTokens"> 
  <Operation>VerifyAccessToken</Operation> 
</OAuthV2>

Paramètres de la règle

Nom	Description	Par défaut	Obligatoire ?
`OAuthV2`	Type de règle
`name`	Le nom de la stratégie, référencé dans le point de terminaison du proxy d'API configuration.	N/A	Oui
`Operation`	Opération à exécuter par la règle OAuthV2. En spécifiant VerifyAccessToken, vous configurez la stratégie pour qu'elle vérifie les demandes de jetons d'accès et que l'accès le jeton est valide, n'a pas expiré et est autorisé à utiliser la ressource d'API demandée (URI). Pour effectuer cette vérification, le règlement indique le produit d'API pour lequel l'application est approuvée. consume.)	N/A	Oui

Pour créer cette stratégie dans l'interface utilisateur de gestion, accédez à API > API Proxys

Dans la liste des proxys d'API, sélectionnez weatherapi.

Dans le champ Overview (Aperçu) de l'API weather, sélectionnez le bouton Develop (Développer). vue.

Dans le menu déroulant, sélectionnez Nouvelle règle > OAuth v2.0

Après avoir sélectionné la règle OAuth v2.0, le menu de configuration Nouvelle règle s'affiche. s'affiche.

Donnez un nom descriptif à votre stratégie et assurez-vous de sélectionner Attach Policy (Associer la stratégie) Flow PreFlow et Request en tant que paramètres de rattachement de règles.

Sélectionnez Ajouter pour créer la règle et l'associer à la requête de l'API weatherapi. PreFlow,

Une fois la règle ajoutée, la configuration PreFlow de la requête ci-dessous s'affichera dans la Volet Designer (Concepteur).

Si vous travaillez en local dans un éditeur de texte ou un IDE, vous pouvez joindre la règle à la demande PreFlow du proxy d'API que vous souhaitez protéger:

<PreFlow>
  <Request>
    <Step><Name>VerifyOAuthTokens</Name></Step>
  </Request>
</PreFlow>

En joignant la règle au PreFlow de la demande, vous vous assurez qu'elle est toujours appliquée sur tous les messages de demande.

Vous venez de sécuriser une API avec des identifiants client OAuth 2.0. L'étape suivante consiste à apprendre comment pour obtenir un jeton d'accès et l'utiliser pour accéder à l'API sécurisée.

L'utilisation d'un jeton d'accès pour accéder ressource

Maintenant que l'API weatherapi est sécurisée avec OAuth 2.0, les applications doivent présenter des jetons d'accès pour utiliser l'API. Pour accéder à une ressource protégée, l'application présente un jeton d'accès dans la requête sous la forme "Autorisation" HTTP comme suit:

$ curl -H "Authorization: Bearer ylSkZIjbdWybfs4fUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

Étant donné que l'API dispose d'une stratégie OAuthV2 associée, Apigee Edge vérifiera que le jeton d'accès La valeur présentée est valide, puis accorde l'accès à l'API et renvoie le bulletin météo à l'application à l'origine de la demande.

Mais comment les applications obtiennent-elles des jetons d'accès ? Nous en parlerons dans la section suivante.

Échanger les identifiants client jeton d'accès

Les applications obtiennent des jetons d'accès en présentant leurs paires clé/secret client au jeton point de terminaison unique. Le point de terminaison du jeton est configuré dans le proxy d'API appelé oauth. Les applications doivent donc appeler l'API exposée par l'API oauth. pour obtenir un jeton d'accès. Une fois que l'application dispose d'un jeton d'accès, elle peut appeler le service weatherapi. plusieurs fois, jusqu'à ce que le jeton d'accès expire ou qu'il soit révoqué.

Vous devez maintenant passer à la vitesse supérieure pour vous considérer comme un développeur d'applications. Vous souhaitez appeler la fonction weatherapi. Vous devez donc obtenir un jeton d'accès pour votre application. Vous devez d'abord obtenez une paire de clés et de secrets client (également appelée API clé ou une clé d'application).

Vous pouvez obtenir une clé et un code secret client en enregistrant une application dans votre organisation sur Apigee. Périphérie.

Vous pouvez afficher toutes les applications de votre organisation dans l'interface utilisateur de gestion d'Apigee Edge.

La liste des applications enregistrées dans votre organisation s'affiche.

Si aucune application ne s'affiche, découvrez comment enregistrer une application dans la rubrique Enregistrer des applications et gérer l'API. clés.)

Sélectionnez une application dans la liste pour afficher son profil détaillé.

Dans la vue détaillée de l'application que vous avez sélectionnée, notez les champs Consumer Key (Clé client). et Code secret du consommateur. Ces deux valeurs correspondent à la valeur client identifiants que vous utiliserez pour obtenir un jeton d'accès OAuth.

$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps \
-u myname:mypass

Cet appel renvoie une liste d'applications triée par ID d'application.

[ "da496fae-2a04-4a5c-b2d0-709278a6f9db", "50e3e831-175b-4a05-8fb6-05a54701af6e" ]

Vous pouvez récupérer le profil d'une application en effectuant un simple appel GET sur l'ID d'application :

$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps/{app_id} \
-u myname:mypass

Exemple :

$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps/da496fae-2a04-4a5c-b2d0-709278a6f9db \
-u myname:mypass

L'appel d'API renvoie le profil de l'application que vous avez spécifié. Par exemple, un profil d'application pour weatherapp a la représentation JSON suivante:

{
  "accessType" : "read",
  "apiProducts" : [ ],
  "appFamily" : "default",
  "appId" : "da496fae-2a04-4a5c-b2d0-709278a6f9db",
  "attributes" : [ ],
  "callbackUrl" : "http://weatherapp.com",
  "createdAt" : 1380290158713,
  "createdBy" : "noreply_admin@apigee.com",
  "credentials" : [ {
    "apiProducts" : [ {
      "apiproduct" : "PremiumWeatherAPI",
      "status" : "approved"
    } ],
    "attributes" : [ ],
    "consumerKey" : "bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K",
    "consumerSecret" : "hAr4Gn0gA9vAyvI4",
    "expiresAt" : -1,
    "issuedAt" : 1380290161417,
    "scopes" : [ ],
    "status" : "approved"
  } ],
  "developerId" : "5w95xGkpnjzJDBT4",
  "lastModifiedAt" : 1380290158713,
  "lastModifiedBy" : "noreply_admin@apigee.com",
  "name" : "weatherapp",
  "scopes" : [ ],
  "status" : "approved"
}

Notez les valeurs pour consumerKey et consumerSecret. Vous utilisez ces identifiants pour obtenir un jeton d'accès en les présentant comme identifiants d'authentification de base dans une requête HTTP, comme indiqué ci-dessous. Le type d'octroi est présenté en tant que paramètre de requête dans la demande. Veillez à modifier la valeur de la variable {org_name} afin qu'elle reflète le nom de votre organisation. sur Apigee Edge.)

Créer une requête pour obtenir un jeton d'accès

Dans la requête suivante, remplacez la valeur de votre consumerKey par client_id Remplacez la valeur du consumerSecret associé par client_secret

$ curl https://{org_name}-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K&client_secret=hAr4Gn0gA9vAyvI4'

Les services d'API vérifient la clé et le code secret client, puis génèrent une réponse contenant le jeton d'accès pour cette application:

{
  "issued_at" : "1380892555397",
  "application_name" : "957aa73f-25c2-4ead-8021-adc01f0d2c6b",
  "scope" : "",
  "status" : "approved",
  "api_product_list" : "[oauth-test]",
  "expires_in" : "3599",
  "developer.email" : "tesla@weathersample.com",
  "organization_id" : "0",
  "client_id" : "bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K",
  "access_token" : "ylSkZIjbdWybfs4fUQe9BqP0LH5Z",
  "organization_name" : "rqa",
  "refresh_token_expires_in" : "0",
  "refresh_count" : "0"
}

Notez la valeur access_token dans la réponse ci-dessus. Il s'agit du jeton d'accès que l'application utilisera pour obtenir un accès en exécution aux ressources protégées. Le jeton d'accès de cette application est ylSkZIjbdWybfs4fUQe9BqP0LH5Z

Vous disposez désormais d'un jeton d'accès valide, ylSkZIjbdWybfs4fUQe9BqP0LH5Z, que vous pouvez utiliser pour accéder à des API protégées.

Utiliser la configuration OAuth par défaut

Chaque organisation (même une organisation bénéficiant d'un essai sans frais) sur Apigee Edge est provisionnée avec un jeton OAuth point de terminaison unique. Le point de terminaison est préconfiguré avec des stratégies dans le proxy d'API appelées oauth. Vous pouvez commencer à utiliser le point de terminaison du jeton dès que vous créez un compte sur Apigee Edge.

Le point de terminaison OAuth par défaut expose l'URI de point de terminaison suivant:

/oauth/client_credential/accesstoken

Publiez cet URI pour les développeurs qui ont besoin d'obtenir des jetons d'accès. Les développeurs d'applications configurent à ses applications d'appeler ce point de terminaison, en présentant leur clé client et leur code secret pour obtenir l'accès de jetons.

Le point de terminaison du jeton d'identifiants clients par défaut est exposé sur le réseau à l'URL suivante :

https://{org_name}-{env_name}.apigee.net/oauth/client_credential/accesstoken

Par exemple, si le nom de votre organisation est "apimakers", l'URL se présentera comme suit :

https://apimakers-test.apigee.net/oauth/client_credential/accesstoken

Il s'agit de l'URL que les développeurs appellent pour obtenir des jetons d'accès.

Conseil : Par défaut, les points de terminaison OAuth prêts à l'emploi sont uniquement déployés dans l'environnement de test. Pour qu'ils soient disponibles dans prod, vous devez déployer explicitement le proxy d'API appelé oauth sur prod.

Configurations OAuth en trois étapes

Configurations OAuth à trois acteurs (code d'autorisation, autorisation implicite et autorisation de mot de passe types), vous, le fournisseur d'API, devez authentifier les utilisateurs finaux de l'application. Chaque organisation authentifie les utilisateurs de différentes manières, une personnalisation des règles ou un codage est nécessaire pour intégrer OAuth à votre magasin d'utilisateurs. Par exemple, tous vos utilisateurs peuvent être stockés dans dans un annuaire LDAP ou un autre magasin d'utilisateurs. Pour mettre en place l'authentification OAuth à trois acteurs, devez intégrer une vérification de ce magasin d'utilisateurs dans le flux OAuth global.

OAuth 1.0a

Pour en savoir plus sur les règles OAuth 1.0a, consultez Stratégie OAuth 1.0a.

Obtenir de l'aide

Pour obtenir de l'aide, consultez la page Apigee Service client :