I'm trying to understand the tenant endpoint and credentials flow for the 'authorization code' grant type used by installed packages that are published on AppExchange.
I have this flow working well independently, that is, I've created an installed package with an API Integration component and a Web App integration type.
With these credentials, I'm then able to follow the documented authorization flow. Specifically:
An end-user initiates the authorization by clicking on a button in my external web application to 'Connect to Marketing Cloud' which makes the authorization code request to the TSSD Authentication Base URI, which includes the Client Id (of the installed package) and Redirect URI defined in the component.
I get the authorization code back from the request which I extract and use to make an access token request to the TSSD Authentication Base URI. Note that this request includes the Client Id and Client Secret.
This flow is suitable for 'manually installed' packages. However, I'm trying to understand how this could work when my installed package is available on AppExchange. Specifically, I don't know the customer's subdomain (TSSD) to make the initial request to.
I note that there's a hint in the documentation for the second authorization part (receiving an access token) which explains:
For AppExchange partners only: The subdomain, or TSSD, that is returned in the /authorize response is different from your own subdomain used as part of the /authorize request. Use the dynamic end-user subdomain returned from /authorize to construct subsequent token requests on your customer’s behalf.
So, here are my assumptions:
- My app will actually use two different TSSD values as Authentication Base URIs; the first includes the TSSD of the app that I used to initially create the Installed Package in Development mode on whatever Marketing Cloud account used (which is then approved and published by Salesforce). The second TSSD is returned from the
/authorizeresponse in the Authorization Code Return.
- I use the same Client Id and Client Secret for every customer (that is, a Marketing Cloud customer who has installed my app from AppExchange on their account).
- The access/refresh token is issued by Marketing Cloud in the context of the user (who initiated the authorization from my app and then logged into Marketing Cloud). That is, the API requests are made on behalf of that user and their account permissions. For example, if I make a GET request to the userInfo REST API route using the access token, this will return the name and email of that user.
In summary, my questions are as follows:
- Are my three assumptions listed above correct?
- If so, why would the initial authorization request be made to the TSSD of the account that I first used to create my installed package? That doesn't sound very sensible to me. That is, if my account is running on a US-based stack, and someone installs my app on S50 (based in Frankfurt, Germany) it doesn't make much sense to me that the initial auth request is routed to a different stack in a different region?! I would expect that I would use a generic auth request like the legacy auth.exacttargetapis.com endpoint for my initial request, but that doesn't appear to be supported.