MIS CURSOS
ABAP Standard
Cliente OAuth 2.0 en SAP BTP: guía práctica
Un cliente OAuth 2.0 en SAP BTP permite que aplicaciones y servicios soliciten acceso sin compartir contraseñas de usuario. Esta guía explica los elementos del flujo, el uso de tokens y las precauciones necesarias para una integración segura.
Implementar un cliente OAuth 2.0 en ABAP permitirá conectar de forma segura a servicios web que requieran autenticación OAuth. A continuación, le proporcionamos los elementos necesarios de cómo se podría implementar un cliente OAuth 2.0 en ABAP:
Contenido
Caso I – Cliente OAuth con perfil disponible en ABAP
El sistema ABAP dispone de algunos tipos de perfiles para el cliente OAuth 2.0 predefinidos que se podrían usar sin la necesidad de crear un tipo adicional.
Entre los tipos disponible mencionamos los siguientes:
- ABAP
- CANARY(NEO)
- GITHUB
- HANA_CLOUD_PLATFORM
- ILMAZURE
- JAM
- LCM_ICRTS
- LCM_MSTEAMS
- SUCCESSFACTORS
- /BSNAGT/IAS_APP2APP
- /PMO/MUC_RE_NATHAN
Para Caso I iremos a utilizar el perfil DEFAULT como ejemplo, empezando con la creación del perfil OAuth 2.0.
OAuth 2.0 Client Profile
Desde la SE80 se crea el perfil del cliente OAuth 2.0
Asignamos el tipo DEFAULT y el nombre del perfil.
Aparte, es posible asignar el alcance del perfil desde la pestaña SCOPE si se desea limitar su uso para ciertas operaciones. Para este caso no agregaremos ningún alcance adicional.
OAuth 2.0 Client
Desde la transacción OA2C_CONFIG crearemos el cliente OAuth 2.0. Esta transacción abre en el navegador el servicio con el mismo nombre OA2C_CONFIG disponible en la ruta /sap/bc/webdynpro/sap/oa2c_config.
A continuación crearemos el cliente OAuth 2.0 utilizando el anterior perfil para un escenario cuyo tipo de acceso es por Client Credentials.
¿Qué se necesita?
- Authorization Endpoint
- Token Endpoint
En la configuración se proporcionará la url del servicio de autenticación que permite obtener el Token de acceso que después se utilizará en la llamada al servicio que se desea consumir.
Para este ejemplo utilizaremos el endpoint de un servicio REST expuesto en BTP y que tiene habilitado el OAuth 2.0, cuyo token endpoint es: https://5f73f9cftrial.authentication.us10.hana.ondemand.com/oauth/token
Con la opción Create empezamos la configuración seleccionado el perfil creado en el anterior paso e indicando junto con el nombre (que puede ser el mismo que el perfil) el cliente ID del endpoint que nos permite obtener el Token.
En la sección de la configuración general se indica el Client Secret.
En la configuración del servidor de autorización se agrega el endpoint del Token.
Continuamos con la configuración del acceso.
Para el SSL Client PSE elegimos ANONYM SSL Client.
Observación: El equipo basis se encargará de configurar los certificados necesarios para el perfil Anonymous.
Caso II – Cliente OAuth con perfil personalizado
OAuth 2.0 Client Service Provider Types
Para los flujos OAuth cuyo tipo de perfil no existe en ABAP, se deben crear el tipo. Ejecutando la transacción OA2C_TYPES es posible crear el tipo personalizado o custom.
BADI implementación – Service Provider Type
Se debe crear una clase ABAP que hereda de la clase estándar CL_OA2C_SPECIFICS_ABSTRACT. Se redefine el método IF_OA2C_SPECIFICS~GET_ENDPOINT_SETTINGS para agregar los endpoints.
Implementamos el código que permite asignar los endpoints del servidor de autorización.
La redefinición e implementación del método IF_OA2C_SPECIFICS~GET_SUPPORTED_GRANT_TYPES permite redefinir los tipos de acceso soportados (grant types).
El método IF_OA2C_SPECIFICS~GET_CONFIG_EXTENSION permite redefinir la extensión de la configuración.
El método IF_OA2C_SPECIFICS~GET_AC_AUTH_REQU_PARAM_NAMES permite redefinir los parámetros de la petición. Estos parámetros se deberían obtener de la misma entidad que permite obtener el Token.
Desde la transacción SE80 se puede abrir el paquete SOAUTH2_CLIENT_EXTENSIONS que contiene el punto de extensión OA2C_SPECIFICS. Agregamos la implementación.
Se indica el nombre y la descripción de la implementación.
Se asigna la implementación de la BAdI, la clase de implementación creada anteriormente y la definición de la BAdI.
En el siguiente paso se agrega el filtro con el nombre del tipo de OAuth creado en el primer paso:
Se activa la implementación de la BAdI.
BADI implementación – Configuración de la Extensión
En segundo lugar, es necesario implementar una clase que se utilizará para completar correctamente los parámetros adicionales de OAuth 2.0 específicos. La clase debe implementar la interfaz IF_OA2C_CONFIG_EXTENSION.
En la implementación del método if_oa2c_config_extension~get_ac_auth_requ_params se agregan los parámetros necesarios para obtener el token.
Se activa la clase y se procede con la implementación de la BAdI.
Se indica el nombre y la descripción de la implementación.
Se asigna la implementación de la BAdI, la clase de implementación creada anteriormente y la definición de la BAdI.
En el siguiente paso se agrega el filtro con el nombre del tipo de OAuth creado en el primer paso:
OAuth 2.0 Client Profile
Se crea el perfil OAuth en base al tipo anteriormente creado, usando la transacción SE80.
Asignamos el tipo personalizado y el nombre del perfil.
Guardamos el perfil.
OAuth 2.0 Client
Desde la transacción OA2C_CONFIG crearemos el cliente OAuth 2.0.
Configuración general:
Configuración del servidor de autorización:
Configuración de acceso:
ABAP Consumo REST con perfil OAuth 2.0
Para este escenario iremos a utilizar un servicio REST expuesto en BTP que tiene habilitado el flujo OAuth 2.0 para su consumo. Además iremos a utilizar el cliente OAuth que se ha configurado previamente (tr. OA2C_CONFIG).
Obtenemos la instancia del cliente HTTP en base al endpoint del servicio REST a consumir.
Se indica el método invocado.
A la anterior instancia se inyecta el token en base al perfil y configuración OAuth 2.0
Se establece el método HTTP que se va a invocar y se realiza la petición.
Se recupera la respuesta y los datos.
ABAP Consumo REST sin perfil OAuth 2.0
Es posible realizar la llamada al servicio REST que requiere el token OAuth 2.0 utilizando la clase estándar CL_HTTP_CLIENT para invocar las dos peticiones, primero al servidor de autorización que devuelve el token y después al endpoint del servicio agregando el token en la cabecera.
Se crea la instancia HTTP para el endpoint del servidor de autorización que devuelve el token.
Se establece el método POST y se agregan los parámetros de cabecera.
Las credenciales CLIENT_ID y CLIENT_SECRET se van a enviar en la cabecera de la petición con el parámetros Authorization de la siguiente forma: Basic CLIENT_ID:CLIENT_SECRET (en base 64). Para este ejemplo no se agrega la lógica de cómo convertir en ABAP el ID del cliente más el SECRET separado por dos puntos, simplemente usamos el valor ya convertido.
Se envía la petición.
Se recupera la respuesta que contendrá el token.
Se procede con la deserialización de la respuesta para manipular la información del token en una estructura ABAP.
Se obtiene la instancia del cliente HTTP que se usará para realizar la petición al servicio REST.
Para este ejemplo se invoca el método GET.
Se recibe la respuesta.
En modo debug se puede observar el cuerpo de la respuesta.
Preguntas frecuentes
¿Qué es un cliente OAuth 2.0?
Es una aplicación registrada que solicita tokens para acceder a recursos protegidos según un flujo y unos permisos previamente definidos.
¿Dónde deben almacenarse el client ID y el client secret?
En un almacén de secretos o servicio de credenciales, con acceso mínimo y rotación periódica; nunca deben quedar expuestos en el frontend.
