API de inicio de sesión del comprador: técnicas y trucos para aprovechar al máximo las vacaciones de gran volumen ☁️

Promociones sensibles al tiempo, ventas relámpago, picos de tráfico y la experiencia de escaparate: hay tantos detalles a tener en cuenta al prepararse para festividades de gran volumen, como el Día de Acción de Gracias en los EE. UU. En Salesforce, la confianza es nuestro valor número uno, y es Nuestra principal prioridad en esta temporada navideña es ayudar a nuestros clientes de comercio a ofrecer experiencias de compra seguras, siempre disponibles y de gran escala a millones de sus compradores.

Con el fin de proporcionar una experiencia de inicio de sesión altamente segura, los clientes que están implementando escaparates basados en PWA Kit o SFRA o híbridos (en parte basados en PWA, en parte SFRA) implementan el servicio Shopper Login and API (SLAS) que permite una experiencia de inicio de sesión OAuth 2.1 estándar. Con SLAS, obtiene un inicio de sesión federado o social, acceso seguro a las API del comprador, una experiencia de compra personalizada mediante un identificador de comprador único ( USID ) e inicio de sesión perpetuo o persistencia del carrito.

Después de un inicio de sesión exitoso, las aplicaciones pueden usar el token SLAS para llamar de forma segura a los puntos finales SCAPI y OCAPI como parte de sus aplicaciones comerciales. En Salesforce, la confianza es nuestro valor número 1. Como parte de la entrega de este valor, hemos seleccionado las siguientes mejores prácticas para los desarrolladores que utilizan SLAS para aumentar la seguridad y la confianza en todo tipo de compilaciones de comercio sin cabeza.

Minimice las llamadas SLAS

Para hacer que su aplicación tenga un mejor rendimiento y reducir las llamadas a SLAS, considere crear su propio USID (identificador único de comprador) y pasarlo a SLAS. Un USID de SLAS es simplemente un UUID tipo 4 (por ejemplo, consulte el Generador de UUID en línea ). Evite llamar al flujo de invitado de SLAS solo para obtener un nuevo USID y luego descartar el JWT de invitado de SLAS. Consulte nuestros límites de tasa prescritos para asegurarse de que sus solicitudes a los puntos finales de SLAS estén dentro de los límites permitidos. Orientación en resumen:

Use un cliente privado si puede asegurar el secreto del ID del cliente
Conservar el USID y actualizar los tokens para su uso posterior
Reutilice el token de acceso SLAS JWT hasta que esté a punto de caducar

Aproveche SLAS JWT para obtener información del comprador

El SLAS JWT (token web JSON) tiene información sobre el comprador, como su nombre e ID de inicio de sesión. Asegúrese de que se utilice la duración completa del SLAS Shopper JWT antes de actualizar el token. Esperar un error 401 en el vencimiento del JWT del comprador SLAS y luego actualizar el token agrega una llamada adicional. Cuantas menos llamadas a la API utilice, mejor será la experiencia del comprador. En el contexto de SLAS Shopper JWT, esto se logra mejor haciendo un uso completo de la duración del token. Agregue un código en su cliente para leer la hora en que se emitió el JWT (IAT) o la hora después de la cual caduca el JWT (EXP). Justo antes del tiempo de vencimiento, llame al token de actualización de SLAS. Tenga en cuenta que el tiempo de vida (TTL) del token SLAS es de 30 minutos. Los tokens de acceso se invalidan si se actualiza la contraseña del cliente.

Si se necesita información sobre el comprador, puede usar el token de ID que se encuentra en la respuesta de una llamada /token .

Token de ID de SLAS:

Un enfoque alternativo para obtener información del comprador es llamar al punto /userinfo (ver documentos ). Como esto crea una llamada API adicional, solo se recomienda cuando ya no tiene acceso a los datos del token de ID.

Fichas de actualización

Los tokens de acceso SLAS JWT son válidos durante 30 minutos, pero el token de actualización se puede usar hasta 90 días en producción (nueve días en inquilinos de nivel inferior) para solicitar un nuevo token de acceso. Con un cliente público, el token de actualización solo se puede usar una vez , por lo que es importante reemplazar y almacenar el nuevo token de actualización que se devuelve cuando solicita un token de acceso. Con un cliente privado, puede reutilizar el mismo token de actualización repetidamente hasta que caduque, o usar el nuevo token de actualización que se devuelve.

Valide JWT de manera eficiente

Las reclamaciones de token web JSON (JWT) son piezas de información afirmadas sobre un tema. En el siguiente ejemplo, el token SLAS contiene un reclamo llamado ISB::UIDN que afirma que el nombre del comprador que se autentica es "Blair Smith". Asegúrese de procesar las reclamaciones en función de un patrón de mapa clave en comparación con el orden en que aparecen.

Puede usar un procesador de reclamos JWT para decodificarlo, o puede examinarlo usted mismo con el depurador jwt.io.

Por ejemplo, los JWT a continuación contienen numerosas afirmaciones: sub e isb son las importantes.

Prepárese para los ataques de bots

Las apropiaciones de cuentas , los fraudes con tarjetas de regalo, la obstrucción del ancho de banda y el agotamiento del inventario son solo algunas de las formas en que los bots intentarán arruinar la temporada navideña para sus compradores. Para combatir tales ataques, agregue el encabezado X-Forwarded-For para todas las llamadas a la API de Salesforce Commerce API (SCAPI)/SLAS. El encabezado de solicitud X-Forwarded-For (XFF) es el encabezado estándar de facto para identificar la dirección IP de origen de un cliente que se conecta a un servidor web a través de un servidor proxy. Utilice el encabezado XFF y asegúrese de que su backend para tiendas frontend o CDN lleven información XFF a llamadas API posteriores.

Ejemplos

En caso de ataques de bots, el equipo de CDN de Salesforce también podría limitar la tasa o rechazar llamadas desde esa dirección IP en particular, ahorrando así la cuota de límite de tasa para sus llamadas API legítimas.

Asegúrese de tener las conexiones de seguridad de la capa de transporte (TLS) correctas al conectarse a Salesforce SLAS y SCAPI para evitar ataques de intermediarios. Esto se puede lograr asegurándose de que las llamadas REST tengan las comprobaciones de configuración adecuadas establecidas para confirmar el certificado TLS del lado del servidor.

Realizar pruebas y revisar los registros de errores

Investigue y documente todas sus 400 respuestas que se devuelven de las llamadas SLAS y SCAPI. Estos son errores del lado del cliente que puede cambiar, y cada uno de los 400 errores que corrige podría resultar en un inicio de sesión o una actualización exitosos. Si se encuentra con varios 429 , asegúrese de no exceder las dos llamadas para el inicio de sesión de SLAS. La API de SLAS ofrece dos variantes para invitados y usuarios de inicio de sesión registrados. Dependiendo de su tipo de aplicación, el inicio de sesión de invitado es una llamada para un cliente privado y dos llamadas para un cliente público. Si está utilizando el cartucho plugin_slas , asegúrese de tener la última versión.

Recientemente, SCAPI habilitó la compatibilidad con ID de correlación externa a través del ID de correlación del encabezado de solicitud HTTP correlation-id: $UUIDv4 , que también funciona con SLAS. Con el uso de esta identificación, si las llamadas fallan, el cliente puede proporcionar la identificación de correlación al soporte de SFDC para permitirles identificar qué salió mal. Este ID se devuelve en el encabezado de respuesta x-correlation-id HTTP como parte de la respuesta de SCAPI.

Asegure sus cookies

Se debe tener cuidado para evitar almacenar JWT de compradores de SLAS o tokens de ID de SLAS en el almacenamiento local del navegador. Si el almacenamiento local está en uso, es mejor asegurarse de que exista una Política de seguridad de contenido (CSP) sólida para ayudar a prevenir su exfiltración. Existen vectores de ataque cuando se utiliza el almacenamiento local que podrían conducir a una pérdida de datos de PII (información de identificación personal). Si el JWT o el token de ID deben estar en el navegador, utilice una cookie (con httpOnly y SameSite=strict , consulte más información ). El beneficio de usar el indicador HttpOnly al generar una cookie ayuda a mitigar el riesgo de que un script del lado del cliente acceda a la cookie protegida.

Puede almacenar el token de actualización como una cookie (con httpOnly y SameSite=strict ) y usarlo para recuperar el mismo contexto de usuario que tenía cuando el usuario inició sesión.

Proteger las credenciales de acceso

Las API del servicio de acceso al inicio de sesión del comprador (SLAS) utilizan credenciales para la autenticación. Le recomendamos que trate su ID de cliente y secreto/contraseña de SLAS como material confidencial y tome medidas para asegurarlos. No almacene esta información en cookies. Como práctica recomendada, obtenga una prueba de penetración de seguridad independiente para garantizar que esta información se almacene de forma segura.

Evite mezclar llamadas de inicio de sesión

La API de SCAPI /actions/login (que funciona como un IDP) es diferente del IDP de OAuth de inicio de sesión de SLAS. No mezcle un SLAS /autorizar y /flujo de token con ninguna llamada para actualizar en SCAPI /acciones/inicio de sesión. La analogía es que uno no iniciaría sesión en Google y luego enviaría su token de actualización a Facebook para autenticar a un usuario de Google: los inicios de sesión SLAS y SCAPI son dos IDP diferentes.

A partir de la versión Spring '23, los puntos de conexión de la API de Commerce Cloud (SCAPI) relacionados con el inicio de sesión del comprador serán reemplazados por los puntos de conexión del Servicio de Acceso de la API y el Inicio de sesión del comprador (SLAS). No están disponibles para nuevos clientes, y para los clientes existentes, recomendamos encarecidamente que use SLAS porque cumple con un estándar más alto de seguridad y disponibilidad.

Devoluciones de llamadas y redireccionamientos desde SLAS

En los flujos de código de autorización de OAuth para los inicios de sesión de invitados y usuarios designados, SLAS devuelve una redirección HTTP (código de estado de respuesta 303) al URI de redirección proporcionado. Es vital asegurarse de que los puntos de conexión del cliente que reciben la devolución de llamada de SLAS sean lo más eficientes y escalables posible. SLAS es un servicio de gran escala, y cuando se inunda con solicitudes de inicio de sesión de invitados y usuarios designados, enviará una ola de llamadas descendentes. Un servicio de recepción podría verse abrumado y, por lo tanto, potencialmente impedir el inicio de sesión de otros compradores. La lección: codifique sus servicios de devolución de llamada con la lógica más simple y considere posponer el procesamiento fuera de banda.

Otra opción es que si está utilizando plugin_slas (en un patrón donde este flujo ocurre en el backend y no en el navegador directamente), entonces está bien NO seguir la redirección 303, sino simplemente extraer el token authCode de la lista de parámetros de devolución de llamada, luego llame a /token con ella, ¡ahorrándole un paso y aumentando el rendimiento!

Nuestros SDK y la última versión de Plugin SLAS hacen esto de inmediato; consulte los documentos para obtener más información.

Del lado del navegador/cliente, debe seguir la redirección debido a cómo funcionan las especificaciones fetch|xmlhttprequest . Del lado del servidor, puede optar por no seguir la redirección. Muchos marcos siguen las redirecciones de forma predeterminada, por lo que es probable que deba desactivar esto. Para el propio URI de redirección, querrá alojarlo en algo escalable como PWA/ECOM. Si está creando un SPA, la página de redirección puede ser estática.

Conclusión

Para resumir, la preparación para las festividades y la garantía de experiencias de inicio de sesión de clientes (compradores) perfectas que aumentan los ingresos y la reputación de la marca son más importantes. La planificación comienza mucho antes de que comience oficialmente la temporada festiva. Trate de diseñar su estrategia de vacaciones e incorpore las mejores prácticas para el rendimiento del sitio web. De esa manera, no corre el riesgo de perder clientes ansiosos por comenzar sus compras cuando llegue el otoño.

Sobre los autores

Preethika S Kalyanasundaram es Gerente de Producto en Salesforce. Se esfuerza por crear excelentes productos que sean simples, poderosos y orientados a ayudar a las personas a mejorar sus vidas. Conéctate con ella en LinkedIn .

Gregg Ganley es el arquitecto de identidad y seguridad de ingeniería de Commerce Cloud en Salesforce. La identidad y la seguridad son sus pasiones, y trabaja para proporcionar flujos de autenticación confiables y de baja fricción para los clientes. Conéctate con él en LinkedIn .