I have added an order status extension, in which I get the session token and then make a request to my backend. There I’m trying to exchange the session token into an access token and get:
"error": "invalid_subject_token",
"error_description": "Token exchange cannot be performed due to an invalid subject token."
Is that in the frontend or the backend? In neither I seem to have a req. In the backend I have access to the query parameters through the event, but since I’m sending the session token in the header, I’m not sending it in the query.
Session Token suggests sending the session token in the header, like I do.
I think you’re trying to use the session token from your order status extension to call the admin API from your server, right?
This isn’t what this session token is for - it’s meant for you to validate that requests to your server are coming from Shopify and not a malicious third party.
You would need to make sure to:
Verify that the request originated from Shopify via the session token
Set up the appropriate permissioning/access scoping restrictions to ensure that customers can only access data and actions that are relevant to them (i.e. don’t allow a customer to query info about another customer, or edit another customer’s order, etc.)
Hey @endor, to query data about the customer, you should do that directly from your customer account extension, by querying the Customer Account API. The Admin API is a merchant-facing API, the risk of using it in customer-facing contexts is very high - you could end up accidentally leaking data about other customers or data that shouldn’t be visible to customers at all.
As @remy727 mentioned, the goal of the session token is to validate that the call to your server originated from your extension in customer accounts, and not from a bad actor trying to find a vulnerability in your server.
The token exchange docs you linked to are talking about token exchange in the context of having an admin session token, which would only be the case in merchant-facing context, not in customer-facing contexts.
What I haven’t yet understood is this though: How can I take an action in my backend based on some of the customer’s data?
I can verify that a certain customer id sent a request to my backend based on the session token, but how can I get the additional data that I need to take an action?
If I request that data in the frontend and send it to my backend, it’s not guaranteed that this data is from my extension, only that the data in the session token is from my extension, right?
What are you trying to do exactly? Mutate customer data? Order data? Something else?
If I request that data in the frontend and send it to my backend, it’s not guaranteed that this data is from my extension, only that the data in the session token is from my extension, right?
No, this isn’t accurate. When you validate the session token, it tells you that the request originated from your extension, so you can trust the entire request, not just the session token.
Edit: I was wrong, data outside of the session token can’t be trusted
I’m trying to work with the seal subscriptions API. In order to do that I need the customer’s email, but the token only contains the id.
I thought I read somewhere that only the token itself can be trusted, not the other data accompanying the request, but I can’t find the place anymore. Could you shortly explain why the whole request is trustworthy? Couldn’t a man-in-the-middle listen to the request and then use the same token but with other data in the request to gain more access?
@Kenza_Iraki Is the correct way then to set up a custom app that allows me to get an admin API token and use that and the customer id in the token to safely look up information?
I’m trying to work with the seal subscriptions API. In order to do that I need the customer’s email, but the token only contains the id.
I thought I read somewhere that only the token itself can be trusted, not the other data accompanying the request, but I can’t find the place anymore. Could you shortly explain why the whole request is trustworthy? Couldn’t a man-in-the-middle listen to the request and then use the same token but with other data in the request to gain more access?
You’re right, my bad, a man-in-the-middle could listen to the request and use your token in a malicious way. Ideally, APIs would use the customer id, and not the customer email, since the customer’s email can change, while the id remains the same.
@Kenza_Iraki Is the correct way then to set up a custom app that allows me to get an admin API token and use that and the customer id in the token to safely look up information?
Public apps are able to generate admin API access tokens as well. But once you start needing an admin API token, you need to be able to safely store it in your database and refresh it every 24 hours. Some docs about how that works are here.