Utilisation de l'authentification de type OAuth 2.0 pour les applications client

L'authentification OAuth (Open Authorization) 2.0 décrit plusieurs méthodes permettant à un propriétaire de ressource d'octroyer un accès à ses ressources protégées. IBM® Cloud Pak for Business Automation as a Service ne prend en charge que le type de subvention ROPC (resource owner password credentials) pour l'authentification de l'accès de l'application client à l'environnement cloud.

Remarque: L'authentification basée sur OAuth 2.0 n'est pas activée par défaut sur les abonnements de cloud. Si vous souhaitez l'utiliser, soumettez une demande via le portail d'assistance IBM.

Type d'octroi ROPC

Dans les termes d'OAuth 2.0 , les applications client Cloud Pak for Business Automation as a Service sont des clients confidentiels. Pour le type d'octroi ROPC, un ensemble de données d'identification client (composées d'un ID et d'un secret client) est requis ainsi qu'un nom d'utilisateur de propriétaire de ressource et un mot de passe. Utilisez l'API Credentials pour générer les données d'identification client. Pour le nom d'utilisateur et le mot de passe, connectez-vous au portail cloud en tant qu'administrateur de compte, générez un ensemble de données d'identification de service, puis affectez-lui les droits requis par l'application client. Les droits permettent de contrôler l'accès par jeton OAuth 2.0 aux environnements de cloud.

Pour plus d'informations sur OAuth et le type de subvention du ROPC, voir le cadre d'autorisation OAuth 2.0. Pour plus d'informations sur l'API Credentials, voir Exemple : Credentials REST API pour l'authentification basée sur OAuth 2.0 et pour obtenir les informations d'identification des services, voir Création et gestion des comptes de service.

Gestion des données d'identification client OAuth 2.0

Les clients OAuth 2.0 doivent fournir des données d'identification client afin d'identifier le contexte client d'appel. Vous décidez du nombre d'ensembles de données d'identification dont vous avez besoin. Par exemple, vous pouvez utiliser un ensemble pour tous les clients OAuth 2.0 ou avoir un ensemble distinct de données d'identification pour chaque client.

Pour que vous puissiez utiliser l'authentification OAuth 2.0 dans votre application client, cette dernière doit inclure les interactions ci-après.

Important: Les appels suivants peuvent renvoyer une commande Set-Cookie pour les cookies PD-S-SESSION-ID et PD-ID dans le cadre de la réponse. Ne les utilisez pas dans les appels qui suivent.

Obtention d'un jeton d'accès OAuth.
Utilisez le nœud final OAuth 2.0 /token pour acquérir un jeton d'accès comprenant les données d'identification du client (ID client et secret client) et du service (nom d'utilisateur et mot de passe). Par exemple :
```
curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' 
-d grant_type=password -d client_id=<clientId> -d client_secret=<clientSecret>
-d username=<serviceCredId> -d password=<svcCredSecret>
https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/token
```
L'appel renvoie le jeton d'accès à utiliser dans les appels API d'opérations de cloud suivants, un jeton permettant d'actualiser le jeton d'accès et une durée d'expiration pour le jeton d'accès. Gardez à l'esprit que les jetons d'accès sont généralement valides pendant plusieurs minutes ou heures alors que les jetons d'actualisation peuvent être valides pendant plusieurs jours. Aucune extension n'est prise en charge.
```
{"access_token":"CJ7yDymDAfSRz03W7zdX","refresh_token":"fGAv2qzuLnM030Brs8KFaIuY1Kd2P87sLFXI85lH","scope":"","token_type":"bearer","expires_in":1799}*
```
Si l'appel aboutit, le code de réponse HTTP 201 est renvoyé. Si les données d'identification du client ou du service ne sont pas valides, l'appel renvoie le code de réponse HTTP BAD_REQUEST (400).
Utilisez le jeton pour accéder aux API des opérations cloud.
Incluez le jeton d'accès renvoyé à l'étape précédente dans l'en-tête d'autorisation de l'appel API d'opérations de cloud. Par exemple :
```
curl -k -v -H "Authorization: Bearer CJ7yDymDAfSRz03W7zdX" https://<tenantHost>/baw/dev/rest/bpm/wle/v1/user/current
```
Si le jeton d'accès n'est pas valide ou s'il est arrivé à expiration, l'appel renvoie le code réponse HTTP 302.

Actualisez le jeton d'accès en utilisant un jeton d'actualisation.

Utilisez le nœud final OAuth 2.0 /token.

curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' 
-d grant_type=refresh_token -d refresh_token=fGU3UjAHG0XKTdnInU8ihqTLf48XJIzQtRUjNFVo
-d client_id=<clientId> -d client_secret=<clientSecret>
https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/token

L'appel renvoie un nouvel ensemble de jetons.

{"access_token":"DkhN7gg7mk2gsBjGi8ay","refresh_token":"ToY13V2yfoYaeVbBjTwFLhzwX7GiKd7Y801VfjGC","scope":"","token_type":"bearer","expires_in":1799}

L'appel renvoie le code de réponse HTTP BAD_REQUEST (400) si le jeton d'actualisation n'est pas valide ou a déjà été utilisé, ou si les données d'identification du client ne sont pas valides, par exemple, car elles ont été supprimées.

Révoquez le jeton d'actualisation et le jeton d'accès à la fin du traitement de l'application client
Lorsque le traitement de l'application client est terminé, il est judicieux de révoquer les deux jetons à l'aide du nœud final OAuth 2.0 /revoke. Révoquez le jeton d'actualisation avant de révoquer le jeton d'accès.
Par exemple, utilisez l'appel suivant pour révoquer le jeton d'actualisation :
```
curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' 
-d client_id=<clientId> -d client_secret=<clientSecret>
-d token=ToY13V2yfoYaeVbBjTwFLhzwX7GiKd7Y801VfjGC
https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/revoke
```
L'appel renvoie toujours un code réponse HTTP de succès, par exemple 200.
Attention: Après l'accès à une API, le jeton d'accès reste valide jusqu'à son expiration.

Limitations

Il existe une limite quotidienne définie par le système de plusieurs centaines d'octrois valides simultanés (paires de jetons d'accès et d'actualisation). Les octrois sont suivis par application client et nom d'utilisateur du propriétaire de la ressource. En théorie, la limite d'octrois ne devrait jamais être atteinte. Toutefois, si un message indique que la limite d'octrois a été atteinte, vérifiez la conception de la création d'octrois dans vos applications client ou contactez le support IBM.