Authenticating Requests from the Shopfront Embedded Bridge
Shopfront's Embedded Bridge allows your application's backend to verify that a request came from an Embedded bridge application through the use of a secure token (similar to a cookie).
You'll still need to authenticate your application through the OAuth 2.0 flow so the user can approve it. This is in addition and allows you to prevent unauthorized use of your backend server. It does not assist with making requests to Shopfront.
Sending Requests
After setting up your application with the Embedded Bridge, obtaining a token is easy. For each request
you make, simply call the getToken method on the application instance and send the token somehow in
your request (such as through a header).
Tokens should be requested for each request as they only have a short period before they expire.
import { Bridge } from "@shopfront/bridge";
const application = Bridge.createApplication({ /* ... your parameters ... */ });
const sendGetRequest = async (url) => {
return fetch(url, {
method: "GET",
headers: {
// Integrations built by Shopfront use the X-Shopfront-Token header,
// but you can use whatever name you'd like
"any-header": await application.getToken(),
},
});
};
Receiving & Decoding Requests
When you receive a request to your server from an embedded application, you should validate it by decoding the token provided.
Shopfront's tokens use the JSON Web Token format for which there are a number of libraries available for common server frameworks.
In order to decode and validate your token, you'll need to pass the token to the decode / verify method of your selected JWT library along with your application's Embedded Signing Key and the HS256 algorithm.
decode(tokenFromRequest, process.env.SHOPFRONT_SIGNING_KEY, "HS256");
This will use your Embedded Signing Key to verify that the contents of the message are valid and will also allow you to read details provided in the token (see below for the anatomy of a token).
Your Embedded Signing Key is shown on your application's page in the developer portal.
Rotating your signing key
Because we sign tokens and you verify them, a rotation can't take effect immediately without breaking every request until you've deployed the new key. So rotating happens in two steps, and you control both.
In the developer portal, go to Applications, then press Edit on your application. The rotation buttons are at the bottom of that page, next to Reset Secret.
- Press Rotate Signing Key. We generate your new signing key and show it in the Next Embedded Signing Key field, but keep signing with your current key - nothing changes for your integration yet, so there's no rush.
- Deploy the new key, then come back to the same page and press Complete Rotation. We start signing with it straight away.
There's no deadline on the second step. If you need to back out, press Cancel Rotation and the new key is discarded, leaving your current one in place.
The simplest way to handle it is to accept either key while you roll out, then drop the old one once you've completed the rotation:
const verifyWithEither = (tokenFromRequest, options) => {
try {
return verify(tokenFromRequest, process.env.SHOPFRONT_SIGNING_KEY, options);
} catch(e) {
return verify(tokenFromRequest, process.env.SHOPFRONT_NEXT_SIGNING_KEY, options);
}
};
Once you've completed the rotation you can drop the old key.
If you don't wish to use a library, you can also manually decode the JWT, we'd suggest reading up on the way JWTs work and are formatted on the JWT.io site.
Validating Tokens
Once you decode the token (or by using the verify method of your JWT library) ensure the following are true:
- The token hasn't expired (the
expclaim) - this should be in the future, - The issuer is who you'd expect (the
issclaim) - for most applications this should behttps://onshopfront.com, - You're the intended recipient (the
audclaim) - this should match your client ID, - The token is for the Vendor you're expecting (using either the
subor thevendor_urlclaim)
The below examples is a Node.js (JavaScript) example using the
jsonwebtoken library. It takes a non-decoded token and which
vendor it should expect and returns a promise which will resolve with a boolean whether it is valid or not.
const verifyToken = (tokenFromRequest, expectedVendor) => {
const shopfrontUrl = "onshopfront.com";
const clientId = "123456";
const signingKey = "abcdef";
return new Promise(res => {
verify(tokenFromRequest, signingKey, {
algorithms: ["HS256"],
issuer : `https://${shopfrontUrl}`,
audience : clientId,
}, (error, decoded) => {
if(error) {
return res(false);
}
if(typeof decoded !== "object") {
return res(false);
}
if(decoded.vendor_url !== `https://${expectedVendor}.${shopfrontUrl}`) {
return res(false);
}
res(true);
});
});
}
Anatomy of a Token
Authentication tokens from Shopfront contain a small amount of useful fields which are helpful for verifying if a request is legitimately from an application embedded within Shopfront's UI.
Header
The values in the header are always the same:
alg: The algorithm used to encode the JWT (alwaysHS256),typ: The type of token this is (alwaysJWT)
Payload
The values in the payload are dynamic and can be different for every request:
iss: The place the token was created from (typicallyhttps://onshopfront.com),aud: The audience the token is for (this is your application's Client ID),sub: The subject of the token (this is the ID of the vendor),exp: When the token expires (in seconds since the Unix epoch),jti: A unique identifier for the token (note, this does not guarantee a unique request),vendor_url: The base URL for the store that the request was made through (typicallyhttps://[vendor].onshopfront.com)token_intention: The intention for this token (alwaysembedded)