En Detalle

Client Credential Grant es tipo de subvención (flujo) de OAUTH2, donde el cliente envía un client Id y un client secret, y el servidor de autorización retorna un token de autorización, y con este token se puede acceder al recurso protegido.

Las siguientes imagenes ilustran el proceso.

Referente a los roles de OAUTH, en este tipo de grant se excluye el usuario (o propietario del recurso) y pueden encontrase implementaciones en que el servidor de autorización y el recurso (servidor del recurso) tengan el mismo servidor (rol).

Implementación

Cuando se desea implementar este tipo de grant, el cliente tiene que registrarse en el servidor de autorización (Usualmente el administrador del servidor de autorización realiza esta tarea) y como resultado se genera el client Id y el client secret. Se podria ver el client Id como un nombre de usuario (de una persona) y el client secret como la constraseña, esta información es enviada al cliente y cuando este los utiliza se retorna su correspondiente token de acceso para que pueda acceder al recurso.

Recomendaciones de Seguridad

El client secret debe considerarse información confidencial, ya que cualquiera que tenga esta información podra facilmente suplantar al cliente original.

Se recomienda cambiar el client secret cada cierto tiempo para incrementar la seguridad, ya que una contraseña antigua corre el riesgo de ser compartida por accidente o puede ser decifrada con el suficiente tiempo.

Nunca versionar (en repositorios de codigo fuente como git) el client Id y mucho menos el client secret, ni siquiera en repositorios privados (donde otras personas de la compañia tengan acceso).

Esta implementación de OAUTH se debe realizar solo cuando el cliente pueda garantizar la seguridad del client secret, esto quiere decir que aplicaciones moviles, aplicaciones puramente javascript no lo deben realizar, para esas situaciones existen otros tipos de grant en OAUTH que permiten obtener el token de acceso sin comprometer la seguridad, por esta razón esta implementación usualmente se realizan de servidor a servidor.

Ejercicio Práctico

Vamos a realizar un ejercicio para demostrar lo explicado, en este ejercicio vamos a utilizar Salesforce como servidor de autorización y servidor del recurso, y postman como cliente.

Preparación

Postman

Es un cliente HTTP que nos permite realizas peticiones con todos los verbos (GET, POST, etc), facil de usar y muy potente, este puede ser descargado desde su página oficial en https://www.postman.com/

Cabe decir que se puede utilizar cualquier otro cliente.

Salesforce

Salesforce es una plataforma en la nube que tiene varia soluciones pre-establecidas y adicionalmente permite crear cualquier aplicación que desemos usando simplemente el mouse o de forma mas programaticas usando código fuente (APEX, LWC etc). Esta suele tener un precio por licencias deacuerdo a la cantidad de usuarios y la solución pre-establecia que se desee usar, sin embargo para los desarrolladores tiene una edicion llamada developer que permite desarrollar y utilizar todo su potencial (con obvias limitaciones como la cantidad de usuarios) de forma gratuita. Salesforce permite implementar el flujo Client Credentials de una forma muy sencilla.

Creando una instancia de desarrollador

Para crear una instancia developer basta con acceder al siguiente enlace https://developer.salesforce.com/signup y completar el formulario. Es importante mencionar que el nombre de usuario tiene forma de correo electrónico pero no es el correo, usualmente es el mismo correo con una adicion extra separada por un punto. ejemplo. si mi correo es cristian@justaservice.com mi usuario para esta instancia del ejercicio puede ser cristian@justaservice.com.cc donde cc significaria client credentials.

una vez completado el formulario nos llegará un correo informandonos que la instancia de salesforce esta lista para se usada (esto toma un par de minutos) y un enlace a la propia instancia que nos permitira asignar una contraseña y acceder a la instancia.

Ejecución

En la documentación de salesforce nos explican como realizar este proceso https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_client_credentials_flow.htm&type=5

sin embargo veamoslo paso a paso y con ayudas visuales para un mejor entendimiento.

Creando el Client Id y el Client Secret

Para implementar la solución, primero es necesario crear el clientId y el client secret en el servidor de autorización; como lo hemos dicho, para nuestro caso seria Salesforce.

Iniciamos sesion en nuestra instancia de desarrollador, si no tenemos el enlace de la instancia propiamente, podemos acceder a https://login.salesforce.com/ e ingresar nuestro nombre de usuario y contraseña.

Vamos a configuracion

luego en la parte izquierda de la pantalla en caja de busqueda escribimos gestor de aplicación

seleccionamos el boton “nueva aplicación conectada”

Completamos la información basica con nuestros datos

En la siguiente sección seleccionamos “Activar Configuración de OAUTH” y se nos desplegará otras opciones. cabe aclarar que para el flujo de Client Credetial no se necesita una URL de devolución de llamada pero en salesforce es obligatorio, por lo que podemos llenarla con cualquier dirección o simplemente activamos el checkbox de “Activar Para Flujo de Dispositivo” y automaticamente colocara una dirección por nosotros. En el ambito de Oauth seleccionamos “Acceso completo (Full)” el cual es el maximo nivel de permisos y finalmente el importante es activar el checkbox “Activar Flujo de Credenciales de Cliente” el cual es el flujo Client Secret.

Para el flujo de Client Secret no se necesita un usuario, pero para salesforce se necesita un usuario para todo,por lo cual en ejecutar como vamos a colocar nuestro propio usario.

Le damos en guardar y nos dice que puede tardar hasta 10 minutos en configurarse nuetra aplicación, en la pantalla que nos deja, la cual deberia ser la vista principal de nuestra applicación, le damos click en el boton modificar politicas y asginamos nuestro usuario en “ejecutar como” en la sección “flujo de credenciales de cliente”

Con estos pasos ya solo nos queda consultar el client id y el client secret, para esto vamos a la pagina de principal de nuestro aplicación conectada y le damos click al boton “Gestionar Detalles de Consumidor”, esto nos enviará un correo de verificación a nuestra correo que registramos en salesforce y una vez ingresado, nos permitira ver el client id y el client secret para nuestra aplicación

Con todos estos pasos ya tenemos correctamente configurado el client id y el client secret para que un cliente pueda acceder al servidor de recurso (en este caso, seria el propio salesforce).

Obteniendo el token de Acceso

Una vez con nuestro client id y client secret basta con realizar una petición tipo POST a salesforce el cual nos retornará el token de acceso. el cual es el primer diagrama que ya vimos en la introducción de este artículo.

El endpoint de salesforce que nos permite solicitar un access token es /services/oauth2/token,

El dominio en mi caso particular es justaservicecomcc-dev-ed.develop.my.salesforce.com, este se puede consultar en configuración > mi dominio

Adicionalmente necesitamos indicar que vamos a ejecutar el flujo client credential e indicar tanto el client id como el secret, la petición se ve de la siguiente forma

POST /services/oauth2/token HTTP/1.1
Host: justaservicecomcc-dev-ed.develop.my.salesforce.com
grant_type=client_credentials&
client_id=*******************&
client_secret=*******************

Ahora utilicemos Postman para simular una petición que realizaria una aplicación cliente y su respuesta

El token de acceso en este ejemplo es

00DHp000001q6QM!AQoAQK9w1w5SWv4u_7EZ2RN0nb_wL8kFaDmrN7X8N7JO.bKQUDQJXrj77XIdhUzKOs__5gYFNUlD6BHIUmMBl14_GcowzOX5

Utilizando el token de Acceso

Ya con el token de acceso queda utilizar el token y consumir el recurso

En nuestro caso el cliente seria Postman y el recurso o servidor de recurso seria la instancia de Salesforce.

Para continuar el ejercicio vamos realizar una consulta a la REST API de Salesforce utilizando el token de acceso. Simplemente vamos a consultar cuales son las veresiones de la API disponibles. El endpoint para esta funcionalidad es

https://MyDomainName.my.salesforce.com/services/data/

En nuestro caso reemplazando el endpoint con nuestro dominio se veria de la siguiente forma

https://justaservicecomcc-dev-ed.develop.my.salesforce.com/services/data/

En los HTTP header vamos a enviar el token de acceso como bearer y nos repondera un JSON con las versiones validas

Conclusión

Este flujo es el mas sencillo de OAUTH2 y debe implementarse teniendo en cuenta el caso de uso para el que esta pensado, en donde el cliente puede garatizar la confidencialidad del client secret, por lo que es común en conexiones de servidor a servidor.

Muchas gracias por leer. Si te pareció interesante, compartelo, ¡es gratis!