Using GetSessionCustomerID for Custom API Integration in Catalyst

[Pedro-Silva-MM]

Hi Catalyst Team,

We are developing a Catalyst application that will serve not only as an e-commerce storefront but also include additional functionalities. To support these additional features, we need the Catalyst application to communicate with our own APIs, identifying the customer making the request.

We noticed that the Catalyst application has a functionality called GetSessionCustomerID, which is used to identify the customer when communicating with the BigCommerce APIs. We’re considering using this same functionality to identify customers when making requests to our own APIs.

Our goal is to understand if we can leverage the existing GetSessionCustomerID functionality to:

1.	Identify customers in our custom API requests.
2.	Maintain a seamless and secure user experience without extensive modifications to the Catalyst codebase.
3.	Ensure that the identification process is secure and efficient.

We have a few questions and would appreciate your guidance:

•	Is there a risk of users attempting to impersonate other users by using this approach?
•	Is this approach recommended for identifying customers in custom API requests?
•	Are there best practices or common patterns that other developers use to handle similar needs?

This is our first time working with BigCommerce and Catalyst, and we believe that this use case is not unique to us. Other agencies and developers likely have similar needs for their headless commerce applications to communicate with additional APIs. We would appreciate any insights or recommendations you can provide on the best way to achieve this.

We appreciate any guidance and opinions you guys can provide us with.
Thank you in advance.

[chanceaclark]

Hey @Pedro-Silva-MM,

Sort of a long reply, but hopeful this helps answers your questions.

Is there a risk of users attempting to impersonate other users by using this approach?

There are issues which we've identified with using a customer id as a way to impersonate a shopper. We have a solution that will added to the repo soon to resolve these risks, but before I get into that I want to provide some context:

The customer id field is a auto-increment field so any attacker that knows this can easily iterate through a list of customers to steal their data. Right now we are storing the customer id in an encrypted cookie that can only be encoded/decoded in the Next.js application. The only reason why we are using this customer id approach is historical and that most of the data on the GraphQL API is not sensitive information.

As an example of why there are risks, if we introduced a way to retrieve saved payment methods on our GraphQL API, an attacker (either a merchant or developer in this case) could iterated through customers 1-100 and retrieve their stored payment methods. If your API was to use the customer id to identify these requests, the same thing could be done with your endpoints. Not good at all.

For the solution I mentioned, very soon here we will be going back to using the Storefront API Token and will be able to generate a Customer Access Token whenever a shopper logs in. We will then authenticate logged in shoppers using a different header which will give you back customer specific information. This will also help us out with a bunch of other things too, but that's a topic for another time.

Is this approach recommended for identifying customers in custom API requests?

For 3rd party requests, as in to your API, I would say no. Even if it is a customer id or customer access token, you should still have a way of authenticating your own requests. When a sign in/out happens, I would hit your own API to generate your own session token and store it within the JWT. Since we use AuthJS, you should be able to do that with this jwt callback. You can use the customer id or customer access token as an identifier for generating your own session token but I would not use those values explicitly as a session.

Are there best practices or common patterns that other developers use to handle similar needs?

Essentially what I just mentioned is sort of the best practice here. I would explore how to make sure your API has a way of generating a session token and authenticating requests with that token.

[Pedro-Silva-MM]

Hey @chanceaclark , thanks for the response

There are issues which we've identified with using a customer id as a way to impersonate a shopper.

The customer id field is a auto-increment field so any attacker that knows this can easily iterate through a list of customers to steal their data.

From what I understand though to be able to make those requests the attacker would need to have access to the BigCommerce access token, and as far as I can tell thats not accessible from the browser. If all the requests are being made from server actions and the access token is not available in the browser then how would an attacker be able to exploit this? Unless they are able to change the customer id in the browser without authenticating as that user, I'm not seeing the issue.

I would agree though that for customer specific data it would be better to have short lived customer access tokens instead of using the BigCommerce access token.

For 3rd party requests, as in to your API, I would say no. Even if it is a customer id or customer access token, you should still have a way of authenticating your own requests.

Regarding this, the way we set it up was that our API is not exposed to the web and it only accepts requests from the Catalyst application, assuming an attacker is not able to do something on the browser to impersonate another user then the requests to our api would be made with the information of the user that has already been authenticated with BigCommerce.

I would hit your own API to generate your own session token and store it within the JWT. Since we use AuthJS, you should be able to do that with this jwt callback. You can use the customer id or customer access token as an identifier for generating your own session token but I would not use those values explicitly as a session.

I would also agree here that adding this layer would be better, I'm struggling to understand if its necessary. Our approach here has been to consider that if a user has authenticated with BigCommerce then they should be able to make authenticated requests to our API. We noticed that the requests to the BigCommerce API were using only the GetSessionCustomerID and the BigCommerce access token as means to identify the customer, so we did something similar.

P.S.:

an attacker (either a merchant or developer in this case)
I just noticed this, if the attacker already has access to the BigCommerce access token or can generate one then its an issue.

Regardless, we appreciate all the info and context, let me know if I misunderstood or am missing something. I'm not opposed to generating a token on our own side it seems though that it would make comms with our own systems more secure while the issues with comms with BigCommerce would remain, for now the user data stored on BigCommerce would be more sensitive than what we will be storing.

[chanceaclark]

From what I understand though to be able to make those requests the attacker would need to have access to the BigCommerce access token, and as far as I can tell thats not accessible from the browser. If all the requests are being made from server actions and the access token is not available in the browser then how would an attacker be able to exploit this? Unless they are able to change the customer id in the browser without authenticating as that user, I'm not seeing the issue.

From a security standpoint we are not just thinking about external actors, but also internal too. If I was a malicious developer with access to the production store, I could do this which would not be good. For example, I am able to render the first 100 customer names and email addresses currently (blurred due to PII):

Regarding this, the way we set it up was that our API is not exposed to the web and it only accepts requests from the Catalyst application, assuming an attacker is not able to do something on the browser to impersonate another user then the requests to our api would be made with the information of the user that has already been authenticated with BigCommerce.

From a security standpoint, I think that's a single layer of security. If that works for y'all I would try it out and see.

I think the question I would ask myself when building something like this out is that, should I trust that a third party has authenticated a user or not? I think about how oauth is set up, for example when you sign into Google, it gives you information about the signed in customer, but it's up to the other application to create a session for that customer. Creating a session allows you to be able to do things like block requests from a certain user, rate limit requests, etc... it's another layer on the security onion.