In one of my previous posts, Simple Marketing Cloud App hosted on a CloudPage, I have outlined a solution for creating apps for use in Marketing Cloud and hosting them on CloudPages.
While you can choose to hide a CloudPage from being indexed by Google, it can still be accessed by anyone who has the link. That’s why to make your Marketing Cloud apps more secure, I will show you how to restrict access to those apps and CloudPages, so that they can only be accessed and used by your Marketing Cloud users who are logged in. The credit for this solution goes to Pato Spir from Devs United whom I would like to thank for sharing it!
Before we start, I assume that you already have an existing CloudPage with an app that you want to secure. If not, you can still test this solution by creating a very simple CloudPage with a text block saying “Hello world”. After implementing the solution described in this article, the text will only be visible to logged-in users, and users who are not logged in will be taken to the Salesforce Marketing Cloud login screen.
Once you have the CloudPage ready, copy the URL of that CloudPage, as you will need it in the next step.
Web App Integrations with Authorization Code Grant Type
In order to build a mechanism that will prevent external users from accessing the CloudPage/App, we will create a new integration in Marketing Cloud and use the authorization code flow to authorize your users.
Let’s start by creating and configuring a new integration package in Marketing Cloud:
- In Marketing Cloud, go to Setup > Apps > Installed Packages.
- Click New.
- Give the package a name and description.
- Save the package.
- Under Components, click Add Component, and select an API Integration component.
- Under Integration Type, choose Web App and click next.
- Under Redirect URIs, paste the link to the CloudPage that hosts your app.
- The scope is not required, so leave all checkboxes blank. Save the package.
Make a note of the Client Id and Secret and your 28 characters tenant-specific subdomain, as you will need those later.
Note: If your users’ default business unit is different than the BU where you install the package, make sure to assign access to the package to your users in both BUs, in their default BU and in the BU which hosts your app. You can do that by going to the Access tab from the detailed view for your package. For more details, see Manage Licensing for Installed Packages.
Authorization Code Flow
In the authorization code flow, end users are redirected to Marketing Cloud to authorize your application to act on their behalf. After the redirect, the user gives authorization to your application by logging in to Marketing Cloud. After login, Marketing Cloud redirects the user to your application’s redirect URL, which you specify when you create the API integration in Installed Packages. As part of this redirect, Marketing Cloud appends an authorization code to the redirect URL for your application to use. Your application then uses the authorization code to request an access token from Marketing Cloud.

Authorization Script
The script will check if the user is logged in, and if not, the user will be asked to log in to Marketing Cloud using their credentials. Once the user logs in, a cookie will be set with the value of the access token. In the below script, you will need to add:
- Client Id from the Installed Package you created earlier,
- Client Secret from the Installed Package you created earlier,
- The 28 character subdomain used in your tenant-specific endpoints (eg. mcx3g7dtegr6hh7y5h7grhrgr97n),
- The URL of the CloudPage that hosts your app.
You can add the below script to the CloudPage’s HTML in the Code View or simply create a new HTML block at the beginning of your CloudPage and paste it there:
For more advanced use cases, you could enhance this solution by adding a state query string when requesting a code to see if it matches a value that you previously set. See more details here and an outline of the solution here.
Questions? Comments?
Leave a comment below or email me at zuzanna@sfmarketing.cloud.
It works like charm,….but just a little modification,…Just in case anybody wants to use the retrieved token for future purposes, the value is stored in the property ‘access_token’, not ‘accessToken’.
This script logic still works, since is storing a value for the cookie, and checking after if it has a value, but it never uses the value itself
LikeLike
Will this work if a Marketing Cloud user has Single Sign-On enabled, or doesn’t that matter? I’m getting an access denied error on the redirect.
LikeLike
Does it matter if a Marketing Cloud user has Single Sign-On enabled, or doesn’t that matter. I’m getting an access denied error on the redirect.
LikeLike
Never mind, it worked! I received an error because I was logged into the wrong MC business unit at the time I tried to access the CloudPage. You can remove these comments. Thanks for the great article!
LikeLike
Thanks for this; however this is not working for me. I’m getting the 500 error. Do I need to add the https on the subdomain?
LikeLike
For those wondering, when you copy paste the code some of the quotes in the URL are not properly copied ((“https://"). If you fix the quotes it should work without any other changes besides entering the ID.
To answer an earlier question you don’t need to add https:// in the subdomain, just the 28 characters. If you look at the code you can see it merges “https” (where the quotes are bad) with the subdomain variable.
LikeLike
Pingback: Data Views App: Display Data Views data in real-time on a CloudPage – sfmarketing.cloud