The Salesforce Spring ’22 release is almost here and with it, Marketing Cloud has now realigned their release cycle with other Salesforce products. While we probably shouldn’t expect animated loading spinners replaced with a cute ‘release theme’ mascot like Sales Cloud, there’s one new feature that I’m particularly looking forward to, which is the ability to generate JavaScript Web Tokens with AMPscript.
In this post I explain what this new support actually means for Marketing Cloud Developers and what its future potential holds.
Overview
JWT Explained
JSON and AMPscript
Authentication
Secure Data Exchange
Journey Builder and JWT
Summary
The release notes don’t really give too much information away and summarises this new feature as:
“AMPscript functions now allow users to generate JavaScript Web Tokens (JWTs) in content resolved by Outbound Mail Manager (OMM) rendering engines. Users can use JWTs to authenticate and securely exchange your information. These functions are available for messages and landing pages.”
While the supporting explanation is a little vague, these three sentences alone provide some important clues into what we should expect. But before I launch into a full expository, it’s important to explain what a JavaScript Web Token actually is and when you might need one.
JWT Explained
I don’t mean to sound pedantic, but there’s actually no such thing as a “JavaScript Web Token”. I assume that Salesforce is actually referring to a JSON Web Token, or JWT (pronounced “jot”), which is an open standard that enables data to be securely transferred between different parties using a self-contained payload. Once received, the information can be verified (as it’s digitally signed). There are a couple of main use cases for JSON Web Tokens, which include:
Authorization which is the most common application for JWT. Requests can be made on the behalf of authenticated users, which includes data on who the user is and what resources they have permission to access.
Data Exchange refers to securely transferring information between different parties. As JWTs can include a signature, they can be validated to ensure senders say who they really are. Additionally, the signature can be used to verify the message wasn’t tampered with, along with who the actual sender of the JWT is.
JSON and AMPscript
Perhaps one of the most surprising implications of this new announcement is that it implies AMPscript will support JavaScript Object Notation (or JSON), at least to some level. AMPscript is a mature scripting language which has barely been touched for over a decade, which is ultimately a testament to how the language “inventors” got it right from the start. However, AMPscript was really built for a different era, specifically due to the notable absence of support for JSON which is an extremely popular data-interchange format today, particularly in REST APIs and this era of “APIfication”. This new support can only mean that the respective function(s) will be able to accept JSON data as arguments.
Before we all get too excited, it’s important to pay close attention to the release notes which explain the scope of this new support is for encoding or “generating” JWTs, not decoding them. This essentially limits the use cases of this feature to two use cases: authentication and data encryption.
Authentication
A popular architectural pattern is to use Script Activities in Automation Studio or CloudPage code resources to make external API requests to external platforms. Authentication methods vary by API, but common ones include:
- Basic
- Bearer
- Digest
- OAuth
Bearer authentication (also called ‘token authentication’) is an HTTP authentication scheme that involves security tokens called bearer tokens. And it’s very popular, particularly for scenarios where you don’t need an authentication server to keep track of tokens (like OAuth does).
The bearer token is a cryptographic string, usually generated by the server in response to a login request. While token generation formats vary, JWT is an increasingly popular format as JWTs encode and verify (via signing) their own “claims” while also being self-contained, so they don’t have an additional overhead of an authentication server and can include an expiration date embedded within the token. In short, there’s no need to store any session state on the server, which of course is perfect for restful APIs.
The problem is that there hasn’t been a JWT Library in Marketing Cloud until now, so you haven’t been able to integrate with APIs that require JWT formatted tokens. However, given that a primary source of initializing HTTP requests would be from a Script Activity, it’s a little surprising that Salesforce didn’t also release a corresponding SSJS function to generate tokens. In the meantime, you will need to wrap AMPscript functions in SSJS and invoke them using the TreatAsContent platform function.
Secure Data Exchange
The second use case is for securely exchanging data from Marketing Cloud to external platforms. While AMPscript already includes functions (EncryptSymmetric and DecryptSymmetric) for encrypting and decrypting strings using different algorithm options, encryption or decryption outside of the platform is not supported, so it can really only be used for encrypting data within the platform.
However, this new support opens up some interesting use cases, specifically for storing data in an encoded token. CloudPages are an increasingly convenient choice for creating ‘custom API routes’ and through encoding a payload that can’t be decoded without a secret key, it’s now possible to create publicly accessible HTTP pages which perform tasks like returning Subscriber data to a remote server as an encoded token, based on a query string value (like a Subscriber Key).
In short, JWTs are a good method for securely transmitting data between parties, because they can be signed (so the sender can be validated) and as the signature is based on the header and payload, the content can be verified for integrity.
Journey Builder and JWT
While Salesforce has gone to the trouble of using a JWT Library to generate tokens using AMPscript, I was hoping that we can expect to see accompanying functions for decoding functions. This would open up additional use cases, primarily the ability to create Journey Builder custom activities in CloudPages, which is an architectural pattern is already quite popular within the Marketing Cloud community, as it:
- Doesn’t require a separate Platform as a Service (PaaS) for hosting activity endpoints
- Enables activities to be written in AMPscript or SSJS, which facilitates rapid application development through a library of pre-built functions for fulfilling common use cases (for example, retrieving records from a Data Extension)
- Doesn’t require expertise in other server-side languages (like Node, PHP or Java)
And while Journey Builder custom activities assets require predefined file names (index.html, config.json and customActivity.js), these static files can actually be hosted on any publicly accessible web server, for example your website or Amazon S3.
But the main consideration when adopting this architectural pattern is that requests to activities’ endpoints can’t be validated. So if your custom activity returns personally identifiable data, then data from these public endpoints could be used maliciously.
However, JWT is also supported for custom activities that retrieve sensitive data or perform sensitive actions. Requests can be encrypted, either by creating a new Salt key (in Key Management) or by using the JWT Signing Secret from the installed package. In this scenario, when a “useJwt” key-value pair is included in the config.json file for a respective endpoint, the request will be encrypted by the Platform.
Adding JWT decoding support to AMPscript would unlock the potential for building contained custom activities on a single platform (Marketing Cloud), to mention just one of many use cases.
Summary
It’s refreshing to see an update to AMPscript. The last language enhancement we saw was back in October 2019 with the addition of the GetSendTime function. This new addition appears to signal a renewed commitment in extending AMPscript to support additional programmable use cases. My only hope is that Salesforce doesn’t stop here and finishes what they started, by adding other functions for decoding tokens, along with a complimentary set of SSJS platform functions.
Have questions about Marketing Cloud? Or want to speak with an expert about how you can get the most out of your Marketing Cloud investment? Get in touch! We’d love to hear from you.
