General

How to Discover API Signatures and Verify Callers Using the Stripe API

Published Dec 2, 2022

Updated Feb 13, 2023

3 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

When you are working with sensitive data like customer payment information or login credentials, you will want to ensure that the data you are receiving from the backend is properly authenticated. API signature verification will check for proper authentication and help ensure that it has not been tampered with.

In this article, we will learn how API signatures work, and look at an example using the Stripe API within Stripe Apps.

Prerequisites: This article will assume that you have a basic working knowledge of the fetch API, JavaScript, Node, and Express. We are also going to be looking at an example using Stripe Apps. I encourage you to create a Stripe account if you are interested in trying out some of the examples on your own.

API signatures and hashing algorithms

When an API request is made, an unique digital signature is created. These signatures use a hashing algorithm which takes the inputted data and converts it to a fixed length string of enciphered data. Popular forms of hashing algorithms include the Secure Hash Algorithm (SHA), and the (Rivest-Shamir-Adleman)(RSA) algorithm.

Here is a basic example of using the HMAC-SHA1 hash algorithm with Node.js.

const crypto = require("crypto");

const text = "This is just demo text";
const key = "x1fjd918dkcn88283sdnc";

// the following code bellow would return this result: ef4dbb240f1f2724a0f909f762b3e539e16f8c3d
crypto.createHmac("sha1", key).update(text).digest("hex");

Third party APIs like PayPal or Stripe have their own verification methods and libraries that use these popular hashing algorithms underneath the hood.

Let's take a look at an example where we will create a fetch call with an API signature using Stripe's fetchStripeSignature and verify the request on the backend using the verifyHeader method.

How to use Stripe's `fetchStripeSignature` in the frontend

Before we make a fetch call, we will need to first get a Stripe signature. Within Stripe's Extensions SDK, we will need to import the fetchStripeSignature function. This function will create a signature that we will use to send to the backend for verification.

import fetchStripeSignature from "@stripe/ui-extension-sdk/utils";

We are now going to start setting up our fetch request with the POST method.

fetch("url-goes-here", {
  method: "POST",
});

Within the headers object, we are going to invoke the fetchStripeSignature function and add it as a value to the 'Stripe-Signature' key. We are also going to set the content type to JSON.

fetch("url-goes-here", {
  method: "POST",
  headers: {
    "Stripe-Signature": fetchStripeSignature(),
    "Content-Type": "application/json",
  },
});

For the body, we are going to add the user and account IDs because Stripe signatures, by default, are signed with those IDs. We are also going to use the JSON.stringify method to ensure that we are working with a JSON string.

fetch("url-goes-here", {
  method: "POST",
  headers: {
    "Stripe-Signature": fetchStripeSignature(),
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    user_id: "user-id-goes-here",
    account_id: "account-id-goes-here",
  }),
});

In order to get the user and account IDs, Stripe Apps has a userContext object which comes from the ExtensionContextValue. To learn more, please visit the Stripe Extensions API reference page.

How to verify the request on the backend using the `verifyHeader` method

Now that we have made our fetch call on the frontend, we now need to verify that data on the backend. We first need to import the Stripe API, and add our Stripe API key and secret. These API keys are used to help authenticate the request and can be found on your Stripe Developer Dashboard. It is a best practice to place your API keys in an .env file like this:

STRIPE_API_KEY=sk_test_...
STRIPE_APP_SECRET=absec_...

Then you can access those keys use process.env.

const stripeAPI = require('stripe')(process.env.STRIPE_API_KEY);
const secretAPIKey = process.env.STRIPE_APP_SECRET;

Then we are going to setup a small Express sever.

const express = require("express");
const app = express();
const port = process.env.PORT || 3000;
const stripe = require("stripe")(process.env.STRIPE_API_KEY);
const secretAPIKey = process.env.STRIPE_APP_SECRET;

app.use(express.json());

app.post("/endpoint-goes-here", (req, res) => {
  // this is where we are going to verify the signature
});

app.listen(port, () => console.log(`This server is running on port: ${port}`));

Within our post, we need to setup the request to get the Stripe signature header.

app.post("/endpoint-goes-here", (req, res) => {
  const stripeSignature = req.headers["stripe-signature"];
});

Next, we need to request the user and account ids.

app.post("/endpoint-goes-here", (req, res) => {
  const stripeSignature = req.headers["stripe-signature"];
  const accountIds = JSON.stringify({
    user_id: req.body["user_id"],
    account_id: req.body["account_id"],
  });
});

We are now going to setup a try catch block and first try to verify the signature for its authenticity. If it is not a valid signature, then we will setup an error message and add a 400 status code in the catch block.

For the verification, we are going to use Stripe's verifyHeader method and pass in the account IDs, Stripe signature, and the Stripe API secret key.

app.post("/endpoint-goes-here", (req, res) => {
  const stripeSignature = req.headers["stripe-signature"];
  const accountIds = JSON.stringify({
    user_id: req.body["user_id"],
    account_id: req.body["account_id"],
  });
  try {
    stripeAPI.webhooks.signature.verifyHeader(
      accountIds,
      stripeSignature,
      secretAPIKey
    );
  } catch (err) {
    res
      .status(400)
      .send(`There was an error validating this signature: ${err.message}`);
  }
});

At the bottom of our post function, we are going to return the JSON response.

app.post("/endpoint-goes-here", (req, res) => {
  const stripeSignature = req.headers["stripe-signature"];
  const accountIds = JSON.stringify({
    user_id: req.body["user_id"],
    account_id: req.body["account_id"],
  });
  try {
    stripeAPI.webhooks.signature.verifyHeader(
      accountIds,
      stripeSignature,
      secretAPIKey
    );
  } catch (err) {
    res
      .status(400)
      .send(`There was an error validating this signature: ${err.message}`);
  }
    // This request is now verified as trusted. Put the rest of your endpoint logic here.
  res.json("response-object-goes-here");
});

Conclusion

In this article, we learned about API signatures and how it uses popular hashing algorithms underneath the hood. We then looked at an example using the Stripe API within the Stripe Apps platform. We first setup a frontend fetch call using the POST method and created a Stripe signature using the fetchStripeSignature function. Then, we verified that signature on the backend using the verifyHeader method.

I hope you enjoyed this article and best of luck on your programming journey.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Jessica Wilkins
Jessica Wilkins is a classical musician turned Software Engineer. Prior to joining the tech industry, she spent her time running her own sheet music company (JDW Sheet Music) as well as performing and teaching in Los Angeles, CA. She enjoys working with React and TypeScript. She is also a prolific technical writer for freeCodeCamp.
@codergirl1991 @jdwilkin4

Learning Paths for Next.JS Developers with Ankita Kulkarni

In this video, Rob Ocel and co-hosts Tracy Lee, Adam Rackis, and Danny Thompson talk with tech educator Ankita Kulkarni about her journey from engineering leader to full-time educator. Ankita shares insights on teaching Next.js, bridging practical knowledge gaps, and helping developers tackle real-world challenges. They discuss Next.js as a React-based framework, its benefits, and the challenges it presents for beginners. Chapters - Introduction to the Podcast and Guests 00:01 - Meet Ankita Kulkarni, Tech Educator 00:26 - Ankita's Transition to Full-Time Education 01:41 - Teaching Practical Knowledge in Next.js 03:19 - Effective Methods for Teaching Next.js 05:27 - Challenges of Being a Full-Time Educator 07:48 - Balancing Broad and Specific Examples 09:54 - Embracing Mistakes as a Teaching Tool 12:13 - Pair Programming and Mentorship 14:00 - Discussion on Next.js and Framework Adoption 16:48 - Advantages and Challenges of Next.js 18:12 - Choosing the Right Framework for Your Needs 20:35 - Impact of Next.js in React Documentation 22:26 - Learning Paths for New Developers 23:24 - The Rise of Full-Stack Web Development 25:09 - Benefits of Frameworks Abstracting Complexity 26:27 - OpenNext and Deployment Flexibility 28:06 - Ankita's Excitement for New Next.js Features 30:35 - The Future of Next.js Without Vercel 32:16 - Final Thoughts and Where to Find Everyone Online 34:21 Follow Ankita Kulkarni on Social Media Twitter: https://x.com/kulkarniankita9 YouTube: https://www.youtube.com/@kulkarniankita Sponsored by This Dot: thisdot.co...

Nov 12, 2024

2 mins

NextJSJavaScript

Exploring Angular Forms: A New Alternative with Signals

Exploring Angular Forms: A New Alternative with Signals In the world of Angular, forms are essential for user interaction, whether you're crafting a simple login page or a more complex user profile interface. Angular traditionally offers two primary approaches: template-driven forms and reactive forms. In my previous series on Angular Reactive Forms, I explored how to harness reactive forms' power to manage complex logic, create dynamic forms, and build custom form controls. A new tool for managing reactivity - signals - has been introduced in version 16 of Angular and has been the focus of Angular maintainers ever since, becoming stable with version 17. Signals allow you to handle state changes declaratively, offering an exciting alternative that combines the simplicity of template-driven forms with the robust reactivity of reactive forms. This article will examine how signals can add reactivity to both simple and complex forms in Angular. Recap: Angular Forms Approaches Before diving into the topic of enhancing template-driven forms with signals, let’s quickly recap Angular's traditional forms approaches: 1. Template-Driven Forms: Defined directly in the HTML template using directives like ngModel, these forms are easy to set up and are ideal for simple forms. However, they may not provide the fine-grained control required for more complex scenarios. Here's a minimal example of a template-driven form: ` ` 2. Reactive Forms: Managed programmatically in the component class using Angular's FormGroup, FormControl, and FormArray classes; reactive forms offer granular control over form state and validation. This approach is well-suited for complex forms, as my previous articles on Angular Reactive Forms discussed. And here's a minimal example of a reactive form: ` ` Introducing Signals as a New Way to Handle Form Reactivity With the release of Angular 16, signals have emerged as a new way to manage reactivity. Signals provide a declarative approach to state management, making your code more predictable and easier to understand. When applied to forms, signals can enhance the simplicity of template-driven forms while offering the reactivity and control typically associated with reactive forms. Let’s explore how signals can be used in both simple and complex form scenarios. Example 1: A Simple Template-Driven Form with Signals Consider a basic login form. Typically, this would be implemented using template-driven forms like this: ` ` This approach works well for simple forms, but by introducing signals, we can keep the simplicity while adding reactive capabilities: ` ` In this example, the form fields are defined as signals, allowing for reactive updates whenever the form state changes. The formValue signal provides a computed value that reflects the current state of the form. This approach offers a more declarative way to manage form state and reactivity, combining the simplicity of template-driven forms with the power of signals. You may be tempted to define the form directly as an object inside a signal. While such an approach may seem more concise, typing into the individual fields does not dispatch reactivity updates, which is usually a deal breaker. Here’s an example StackBlitz with a component suffering from such an issue: Therefore, if you'd like to react to changes in the form fields, it's better to define each field as a separate signal. By defining each form field as a separate signal, you ensure that changes to individual fields trigger reactivity updates correctly. Example 2: A Complex Form with Signals You may see little benefit in using signals for simple forms like the login form above, but they truly shine when handling more complex forms. Let's explore a more intricate scenario - a user profile form that includes fields like firstName, lastName, email, phoneNumbers, and address. The phoneNumbers field is dynamic, allowing users to add or remove phone numbers as needed. Here's how this form might be defined using signals: ` > Notice that the phoneNumbers field is defined as a signal of an array of signals. This structure allows us to track changes to individual phone numbers and update the form state reactively. The addPhoneNumber and removePhoneNumber methods update the phoneNumbers signal array, triggering reactivity updates in the form. ` > In the template, we use the phoneNumbers signal array to dynamically render the phone number input fields. The addPhoneNumber and removePhoneNumber methods allow users to reactively add or remove phone numbers, updating the form state. Notice the usage of the track function, which is necessary to ensure that the ngFor directive tracks changes to the phoneNumbers array correctly. Here's a StackBlitz demo of the complex form example for you to play around with: Validating Forms with Signals Validation is critical to any form, ensuring that user input meets the required criteria before submission. With signals, validation can be handled in a reactive and declarative manner. In the complex form example above, we've implemented a computed signal called formValid, which checks whether all fields meet specific validation criteria. The validation logic can easily be customized to accommodate different rules, such as checking for valid email formats or ensuring that all required fields are filled out. Using signals for validation allows you to create more maintainable and testable code, as the validation rules are clearly defined and react automatically to changes in form fields. It can even be abstracted into a separate utility to make it reusable across different forms. In the complex form example, the formValid signal ensures that all required fields are filled and validates the email and phone numbers format. This approach to validation is a bit simple and needs to be better connected to the actual form fields. While it will work for many use cases, in some cases, you might want to wait until explicit "signal forms" support is added to Angular. Tim Deschryver started implementing some abstractions around signal forms, including validation and wrote an article about it. Let's see if something like this will be added to Angular in the future. Why Use Signals in Angular Forms? The adoption of signals in Angular provides a powerful new way to manage form state and reactivity. Signals offer a flexible, declarative approach that can simplify complex form handling by combining the strengths of template-driven forms and reactive forms. Here are some key benefits of using signals in Angular forms: 1. Declarative State Management: Signals allow you to define form fields and computed values declaratively, making your code more predictable and easier to understand. 2. Reactivity: Signals provide reactive updates to form fields, ensuring that changes to the form state trigger reactivity updates automatically. 3. Granular Control: Signals allow you to define form fields at a granular level, enabling fine-grained control over form state and validation. 4. Dynamic Forms: Signals can be used to create dynamic forms with fields that can be added or removed dynamically, providing a flexible way to handle complex form scenarios. 5. Simplicity: Signals can offer a simpler, more concise way to manage form states than traditional reactive forms, making building and maintaining complex forms easier. Conclusion In my previous articles, we explored the powerful features of Angular reactive forms, from dynamic form construction to custom form controls. With the introduction of signals, Angular developers have a new tool that merges the simplicity of template-driven forms with the reactivity of reactive forms. While many use cases warrant Reactive Forms, signals provide a fresh, powerful alternative for managing form state in Angular applications requiring a more straightforward, declarative approach. As Angular continues to evolve, experimenting with these new features will help you build more maintainable, performant applications. Happy coding!...

Oct 4, 2024

5 mins

AngularJavaScript

How to Resolve Nested Queries in Apollo Server

When working with relational data, there will be times when you will need to access information within nested queries. But how would this work within the context of Apollo Server? In this article, we will take a look at a few code examples that explore different solutions on how to resolve nested queries in Apollo Server. I have included all code examples in CodeSandbox if you are interested in trying them out on your own. Prerequisites This article assumes that you have a basic knowledge of GraphQL terminology. Table of Contents - How to resolve nested queries: An approach using resolvers and the filter method - A refactored approach using Data Loaders and Data Sources - What are Data Loaders - How to setup a Data Source - Setting up our schemas and resolvers - Resolving nested queries when microservices are involved - Conclusion How to resolve nested queries: An approach using resolvers and the filter method In this first example, we are going to be working with two data structures called musicBrands and musicAccessories. musicBrands is a collection of entities consisting of id and name. musicAccessories is a collection of entities consisting of the product name, price, id and an associated brandId. You can think of the brandId as a foreign key that connects the two database tables. We also need to set up the schemas for the brands and accessories. ` The next step is to set up a resolver for our Query to return all of the music accessories. ` When we run the following query and start the server, we will see this JSON output: ` ` As you can see, we are getting back the value of null for the brands field. This is because we haven't set up that relationship yet in the resolvers. Inside our resolver, we are going to create another query for the MusicAccessories and have the value for the brands key be a filtered array of results for each brand. ` When we run the query, this will be the final result: ` ` This single query makes it easy to access the data we need on the client side as compared to the REST API approach. If this were a REST API, then we would be dealing with multiple API calls and a Promise.all which could get a little messy. You can find the entire code in this CodeSandbox example. A refactored approach using Data Loaders and Data Sources Even though our first approach does solve the issue of resolving nested queries, we still have an issue fetching the same data repeatedly. Let’s look at this example query: ` If we take a look at the results, we are making additional queries for the brand each time we request the information. This leads to the N+1 problem in our current implementation. We can solve this issue by using Data Loaders and Data Sources. What are Data Loaders Data Loaders are used to batch and cache fetch requests. This allows us to fetch the same data and work with cached results, and reduce the number of API calls we have to make. To learn more about Data Loaders in GraphQL, please read this helpful article. How to setup a Data Source In this example, we will be using the following packages: - apollo-datasource - apollo-server-caching - dataloader We first need to create a BrandAccessoryDataSource class which will simulate the fetching of our data. ` We will then set up a constructor with a custom Dataloader. ` Right below our constructor, we will set up the context and cache. ` We then want to set up the error handling and cache keys for both the accessories and brands. To learn more about how caching works with GraphQL, please read through this article. ` Next, we are going to set up an asynchronous function called get which takes in an id. The goal of this function is to first check if there is anything in the cached results and if so return those cached results. Otherwise, we will set that data to the cache and return it. We will set the ttl(Time to Live in cache) value to 15 seconds. ` Below the get function, we will create another asynchronous function called getByBrand which takes in a brand. This function will have a similar setup to the get function but will filter out the data by brand. ` Setting up our schemas and resolvers The last part of this refactored example includes modifying the resolvers. We first need to add an accessory key to our Query schema. ` Inside the resolver, we will add the accessories key with a value for the function that returns the data source we created earlier. ` We also need to refactor our Brand resolver to include the data source we set up earlier. ` Lastly, we need to modify our ApolloServer object to include the BrandAccessoryDataSource. ` Here is the entire CodeSandbox example. When the server starts up, click on the Query your server button and run the following query: ` Resolving nested queries when microservices are involved Microservices is a type of architecture that will split up your software into smaller independent services. All of these smaller services can interact with a single API data layer. In this case, this data layer would be GraphQL. The client will interact directly with this data layer, and will consume API data from a single entry point. You would similarly resolve your nested queries as before because, at the end of the day, there are just functions. But now, this single API layer will reduce the number of requests made by the client because only the data layer will be called. This simplifies the data fetching experience on the client side. Conclusion In this article, we looked at a few code examples that explored different solutions on how to resolve nested queries in Apollo Server. The first approach involved creating custom resolvers and then using the filter method to filter out music accessories by brand. We then refactored that example to use a custom DataLoader and Data Source to fix the "N+1 problem". Lastly, we briefly touched on how to approach this solution if microservices were involved. If you want to get started with Apollo Server and build your own nested queries and resolvers using these patterns, check out our serverless-apollo-contentful starter kit!...

May 17, 2023

6 mins

GraphQL

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

In this JS Drop, Danny Thompson is joined by YouTuber Jack Herrington to explore a unique TypeScript and AI project that lets you recognize TV show characters in real time. Just point your camera at a character, and instantly get their details or even chat with them as if they were real! Jack walks through the tech, explaining how client-side face recognition and server-side AI work together to make this possible using the Versal AI library. They discuss prompt engineering, building efficient APIs, and ensuring smooth, interactive AI responses. Jack also shares potential real-world applications, from entertainment to security. Chapters - 0:32 Project Overview – Jack explains the AI-powered character recognition project - 2:17 Setting Up the Project – Overview of how the application is structured and initial setup - 3:04 Client-Side AI – How face detection and character recognition work on the client side - 5:12 Switching to Server Side – Jack demonstrates server-side AI and setting up API endpoints - 8:20 Explaining AI Tooling – How tools and prompts are used to give context to the AI - 10:01 Detailed Prompt Structure – Breaking down the prompt and character context for AI responses - 12:40 Client-Server Interaction – Using the Versal AI library to manage streaming responses - 15:09 Handling Character Data – Training the AI on specific character images and details - 18:15 Practical Use Cases – Discussing potential real-world applications for the face recognition tool - 21:34 Challenges and Lessons Learned – Jack shares obstacles he faced and how he overcame them - 25:45 Building the API – Tips and considerations for creating reliable API endpoints - 28:40 Handling User Inputs – Testing unexpected questions and how the AI responds - 32:00 Using Advanced AI Models – Jack talks about choosing GPT-4 and issues with smaller models - 35:47 Introducing ProNextJS.dev – Jack discusses his new Next.js course, covering advanced topics - 37:20 Closing Thoughts – Danny and Jack wrap up with final thoughts and a link to the GitHub repo Follow Jack Herrington on Social Media Twitter: https://x.com/jherr Linkedin: https://www.linkedin.com/in/jherr/ YouTube: https://www.youtube.com/@jherr Sponsored by This Dot: thisdot.co...

Nov 11, 2024

2 mins

AIArtificial Intelligence

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

How to Discover API Signatures and Verify Callers Using the Stripe API

API signatures and hashing algorithms

How to use Stripe's `fetchStripeSignature` in the frontend

How to verify the request on the backend using the `verifyHeader` method

Conclusion

Jessica Wilkins

You might also like

Learning Paths for Next.JS Developers with Ankita Kulkarni

Exploring Angular Forms: A New Alternative with Signals

How to Resolve Nested Queries in Apollo Server

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

Let's innovate together!

You might also like

Learning Paths for Next.JS Developers with Ankita Kulkarni

Exploring Angular Forms: A New Alternative with Signals

How to Resolve Nested Queries in Apollo Server

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

API signatures and hashing algorithms

How to use Stripe's fetchStripeSignature in the frontend

How to verify the request on the backend using the verifyHeader method

Conclusion

Jessica Wilkins

Learning Paths for Next.JS Developers with Ankita Kulkarni

Exploring Angular Forms: A New Alternative with Signals

How to Resolve Nested Queries in Apollo Server

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

Let's innovate together!

Learning Paths for Next.JS Developers with Ankita Kulkarni

Exploring Angular Forms: A New Alternative with Signals

How to Resolve Nested Queries in Apollo Server

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

How to use Stripe's `fetchStripeSignature` in the frontend

How to verify the request on the backend using the `verifyHeader` method