Utilización de la autenticación basada en OAuth 2.0 para aplicaciones cliente

Open Authorization (OAuth) 2.0 describe varias maneras de las que un propietario de recurso puede otorgar acceso a los recursos protegidos. IBM® Cloud Pak for Business Automation as a Service sólo admite el tipo de concesión de credenciales de contraseña de propietario de recurso (ROPC) para autenticar el acceso de aplicaciones cliente al entorno de nube.

Nota: La autenticación basada en OAuth 2.0 no está activada por defecto en las suscripciones en la nube. Si desea utilizarlo, envíe una solicitud a través del portal de asistencia IBM El enlace externo abre una nueva ventana o pestaña

Tipo de otorgamiento ROPC

En términos de OAuth 2.0 , las aplicaciones cliente de Cloud Pak for Business Automation as a Service son clientes confidenciales. Para el tipo de otorgamiento de ROPC, necesitan un conjunto de credenciales de cliente (que constan de un ID de cliente y un secreto de cliente) y un nombre y una contraseña de usuario propietario de recurso. Para obtener las credenciales de cliente, utilice la API Credentials para generarlas. Para el nombre de usuario y la contraseña, inicie la sesión en el portal de nube como Administrador de cuentas, genere un conjunto de credenciales de servicio y a continuación asígneles los permisos que la aplicación de cliente necesita. Los permisos se utilizan para controlar el acceso basado en señal de OAuth 2.0 a los entornos de nube.

Para más información sobre OAuth y el tipo de subvención ROPC, consulte El marco de autorización OAuth 2.0 El enlace externo abre una nueva ventana o pestaña . Para obtener información sobre la API Credentials , consulte Ejemplo: API REST de credenciales para la autenticación basada en OAuth 2.0 y para obtener credenciales de servicio, consulte Creación y gestión de cuentas de servicio.

Gestión de credenciales de cliente OAuth 2.0

Los clientes OAuth 2.0 deben proporcionar credenciales de cliente para identificar el contexto del cliente que llama. Puede decidir cuántos conjuntos de credenciales necesita. Por ejemplo, puede utilizar un conjunto para todos los clientes de OAuth 2.0 o tener un conjunto de credenciales aparte para cada cliente.

Para utilizar la autenticación OAuth 2.0 en la aplicación cliente, la aplicación debe incluir las interacciones siguientes.

Importante: Las llamadas siguientes pueden devolver un mandato Set-Cookie para las cookies PD-S-SESSION-ID y PD-ID como parte de la respuesta. No utilice estas cookies en llamadas posteriores.

Obtener una señal de acceso de OAuth 2.0.
Utilice el punto final de OAuth 2.0 /token para adquirir una señal de acceso que incluya el cliente (ID de cliente y secreto de cliente) y las credenciales de servicio (nombre de usuario y contraseña). Por ejemplo:
```
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
```
La llamada devuelve la señal de acceso que se va a utilizar las posteriores llamadas de API de operaciones en la nube, una señal de renovación para renovar la señal de acceso y una duración de caducidad para la señal de acceso. Tenga en cuenta que normalmente las señales de acceso son válidas durante horas o minutos, mientras que las señales de renovación pueden ser válidas durante días. El ámbito no está soportado.
```
{"access_token":"CJ7yDymDAfSRz03W7zdX","refresh_token":"fGAv2qzuLnM030Brs8KFaIuY1Kd2P87sLFXI85lH","scope":"","token_type":"bearer","expires_in":1799}*
```
Si la llamada es satisfactoria, se devuelve el código de respuesta HTTP 201. Si las credenciales de cliente o de servicio no son válidas, la llamada devuelve el código de respuesta HTTP BAD_REQUEST (400).
Utilizar la señal para acceder a las APIs de operaciones.
Incluya la señal de acceso devuelta del paso anterior en la cabecera de autorización de la llamada de API de operaciones en la nube. Por ejemplo:
```
curl -k -v -H "Authorization: Bearer CJ7yDymDAfSRz03W7zdX" https://<tenantHost>/baw/dev/rest/bpm/wle/v1/user/current
```
Si la señal de acceso no es válida o ha caducado, la llamada devuelve el código de respuesta HTTP 302.

Renovar la señal de acceso mediante una señal de renovación.

Utilizar el punto final de 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

La llamada devuelve un conjunto de señales nuevo.

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

La llamada devuelve el código de respuesta HTTP BAD_REQUEST (400) si la señal de renovación no es válida o si ya se ha utilizado, o si las credenciales de cliente no son válidas, por ejemplo porque se han suprimido.

Revocar las señales de renovación y acceso al final del proceso de aplicación cliente
Cuando el proceso de la aplicación cliente ha finalizado, se recomienda revocar ambas señales utilizando el punto final de OAuth 2.0 /revoke. Revoque la señal de renovación antes de revocar la señal de acceso.
Por ejemplo, utilice la llamada siguiente para revocar la señal de renovación.
```
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
```
La llamada siempre devuelve un código de respuesta HTTP satisfactorio, por ejemplo 200.
Atención: Después de acceder a una API, la señal de acceso permanece válida hasta que caduca.

Limitaciones

Hay un límite diario definido por el sistema de varios cientos de otorgamientos válidos simultáneos (pares de señales de acceso y renovación). Se hace un seguimiento de los otorgamientos por aplicación cliente y nombre de usuario propietario de recurso. Se espera que el límite de otorgamiento no se alcance nunca. Sin embargo, si ve un mensaje que indica que el límite de otorgamiento se ha alcanzado, compruebe el diseño de creación en las aplicaciones cliente o póngase en contacto con el soporte de IBM.