Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .
El enlace a la publicación original, lo encontrarás al final de este artículo.
…
Puede llegar un momento en el que necesite integrar una aplicación con su organización de Salesforce para realizar una tarea específica, como recuperar datos de cuentas o clientes potenciales de Salesforce. Para hacerlo, Salesforce proporciona un conjunto completo de API que abordan una amplia gama de casos de uso. Una vez que haya averiguado qué API desea usar, su pregunta de seguimiento probablemente será: "¿Cómo me autentico?"
Aquí es donde entra en juego OAuth. OAuth (abreviatura de "autorización abierta") es un estándar IETF para la delegación de acceso que se utiliza para que los usuarios de Internet otorguen a las aplicaciones acceso a su información en otros sitios, generalmente sin compartir sus contraseñas.
Salesforce ha admitido OAuth 2.0 y varios de sus flujos durante mucho tiempo. El flujo más popular es el otorgamiento de código de autorización , que es el que normalmente usa cuando conecta un sitio web (por ejemplo, Airbnb a su cuenta de Google) para iniciar sesión. Salesforce le permite usarlo en varias áreas, como su Páginas de inicio de sesión de Mi dominio o Experience Cloud, a través de un proveedor de autenticación .
Esto es excelente cuando desea una autenticación basada en el usuario mediante la cual desea que un sistema (su aplicación) se conecte a Salesforce en el contexto de un usuario específico .
Por qué implementar el flujo de credenciales del cliente
Sin embargo, en ocasiones, desea conectar su aplicación a las API de Salesforce fuera del contexto de un usuario en particular. Por ejemplo, su aplicación puede ser una aplicación de respaldo o una aplicación de análisis; no conoce ningún nombre de usuario y no tiene las credenciales de ningún usuario específico. Por lo tanto, cualquier otro medio de autenticación está fuera de la mesa. Aquí es donde entra en juego la "concesión de credenciales de cliente" de OAuth. RFC6749 señala lo siguiente:
El cliente puede solicitar un token de acceso utilizando solo sus credenciales de cliente (u otros medios de autenticación admitidos) cuando el cliente solicita acceso a los recursos protegidos bajo su control, o los de otro propietario de recursos que se han acordado previamente con el servidor de autorización ( cuyo método está más allá del alcance de esta especificación).
En el lenguaje de OAuth, las credenciales del cliente son el identificador del cliente y el secreto del cliente. En el lenguaje de Salesforce, los llamamos clave y secreto del consumidor. Puede encontrarlos en su aplicación conectada en la sección etiquetada API (Habilitar configuración de OAuth) como se ve en la captura de pantalla a continuación.
Haga clic en Administrar detalles del consumidor , lo que lo llevará a la siguiente captura de pantalla.
Configurando el flujo
En Configuración > Administrador de aplicaciones, cree una nueva aplicación conectada. En las pantallas de detalles, proporcione un nombre y un contacto en la sección de información básica. Lo que elijas realmente no importa allí. Centrémonos en cambio en la siguiente sección, API (Habilitar configuración de OAuth).
Seleccione la casilla de verificación junto a "Habilitar flujo de credenciales de cliente". Esto habilitará el flujo de OAuth para la aplicación conectada seleccionada y los ámbitos de OAuth. Luego, elija sus alcances; debido a que esto está destinado al acceso a la API, debe elegir el alcance solo de API.
Una vez que haya hecho eso y haya guardado su aplicación, debe ir a administrar su aplicación para editar las políticas que rigen la aplicación.
En particular, querrá elegir un usuario para que el flujo "se ejecute como". ¿Un usuario? Bueno, sí, todo en Salesforce se ejecuta en el contexto de un usuario, por lo que aunque este flujo está destinado a ejecutarse fuera del contexto de un usuario, aún debemos asignarlo a un usuario. Piense en esto como el patrón de "usuario de integración". Ese usuario puede ser un administrador o un usuario con permisos que le permitan tocar todos los datos que le interesan. En Spring '23, el usuario debe ser "Solo API", pero ese requisito se eliminará de Summer '23 en adelante. . Tenga en cuenta que las organizaciones de Developer Edition no tienen el permiso Solo API, por lo que si está en Spring '23, necesitará una edición diferente.
Probarlo todo
Usemos Postman para probar. Estamos de suerte ya que la colección API de Salesforce (presentada por el increíble Philippe Ozil) ya contiene una muestra para las credenciales de los clientes. Todo lo que necesita hacer es abrir esa muestra y asegurarse de que las bibliotecas de su colección contengan valores actualizados para:
-
client_id:
puede encontrar este valor dentro de la aplicación conectada. En el menú desplegable junto a la aplicación conectada, haga clic en Ver . Luego ubique la sección API (Habilitar configuración de OAuth) y haga clic en Administrar detalles del consumidor . Esto le permitirá copiar su clave de consumidor y secreto de consumidor (también conocido como ID de cliente y secreto de cliente). -
client_secret
: Ver arriba. - URL: por ejemplo, su URL puede ser algo como: https://login.salesforce.com .
Invocar esta llamada devolverá un token de acceso opaco que puede usar en llamadas posteriores. Recuerde: este token de acceso se emite para el usuario "Ejecutar como". Por lo tanto, si elige un usuario con un amplio conjunto de permisos (quizás un perfil de administrador del sistema), entonces el token de acceso obtiene la misma cantidad. Esto es excelente para las integraciones, pero puede ser peligroso de lo contrario, así que trate su token con cuidado. Cree un usuario de integración dedicado y limite su acceso mediante conjuntos de permisos al subconjunto más pequeño posible de funciones necesarias.
Así es como se ve la respuesta:
Conclusión
Ahora que Salesforce agregó soporte para la concesión de credenciales de cliente de OAuth 2.0, es más fácil que nunca establecer integraciones de servidor a servidor que no necesariamente necesitan el contexto del usuario. Para obtener más información, consulte el RFC para obtener detalles esenciales o nuestra página de ayuda .
Sobre el Autor
David Brossard es el director sénior de gestión de productos para identidad en Salesforce. Se enfoca en todo lo relacionado con el SSO y la identidad del cliente. Es miembro fundador de IDPro y colaborador de estándares, como XACML y SCIM. David habla regularmente en conferencias de identidad como Identiverse.
Obtenga las últimas publicaciones de blog de desarrolladores de Salesforce y episodios de podcast a través de Slack o RSS.
Agregar a Slack Suscríbete a RSS
…
Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2023/03/using-the-client-credentials-flow-for-easier-api-authentication.html