Javascript

How to Set Up OAuth with a Stripe App

May 24, 2022

8 min read

Stripe Apps are a great way to extend Stripe dashboard functionality using third-party integrations. But when using these integrations, developers must prioritize security. The best way to do this is by using OAuth with the third-party product with which you would like to integrate.

However, there are some constraints, and we cannot use cookies to set up a cookie based authentication front-end only. In this article, we would like to show you how to do it with a NestJS back-end.

Stripe signatures

The best way to secure your API is by making sure that every request comes from a verified Stripe App instance. The @stripe/ui-extension-sdk package provides a way to generate a signature on the front-end side. This signature is valid for 5 minutes, and you can send it as a header for every request you make. For this to work, you need to have @stripe/ui-extension-sdk installed in your repository.

import fetchStripeSignature from "@stripe/ui-extension-sdk/signature";
// fetchStripeSignature returns with a Promise<string>

In order to properly validate this signature on your API, you will need some additional information to be sent in the request headers as well. That information is the Stripe user's ID, and the Stripe account's ID. We found that the best way is to implement a global context with this information.

import { createContext } from "react";
import { ExtensionContextValue } from "@stripe/ui-extension-sdk/context";
export const GlobalContext = createContext<{
  userContext: ExtensionContextValue["userContext"] | null;
  environment: ExtensionContextValue["environment"] | null;
}>({ userContext: null, environment: null });

The above context stores the ExtensionContextValue that gets passed from the Stripe dashboard to the app when it opens in the view. For example, if you are on a payment detail page, the userContext will contain information about your Stripe user, while the environment will provide you access to the object that you are viewing. In the above example, that would be the payment's ID as the objectContext.id property.

Let's set up the view with this global context.

import type { ExtensionContextValue } from "@stripe/ui-extension-sdk/context";
import { ContextView } from "@stripe/ui-extension-sdk/ui";
import { GlobalContext } from "./common/global-context";
const PaymentDetailView = ({
  userContext,
  environment,
}: ExtensionContextValue) => (
  <ContextView title={title || " "} description={description}>
    <GlobalContext.Provider value={{ userContext, environment }}>
      TODO: navigation and login will come here.
    </GlobalContext.Provider>
  </ContextView>
);
export default PaymentDetailView;

Now, we can set up a hook to provide a proper fetch method that always appends a Stripe signature, and the other required fields to the headers.

useFetchWithCredentials hook

In order to make our future job easier, we need to set up a hook that creates a proper wrapper around fetch. That wrapper will handle setting the headers for us. It needs to have access to our GlobalContext, so we can get the Stripe user's, and their account's, IDs.

import { ExtensionContextValue } from "@stripe/ui-extension-sdk/context";
import fetchStripeSignature from "@stripe/ui-extension-sdk/signature";
import { useCallback, useContext } from "react";
import { GlobalContext } from "../common/global-context";
export function useFetchWithCredentials() {
  const globalContext = useContext(GlobalContext);
  return useCallback(
    async (uri: string, { headers, ...options }: RequestInit = {}) => {
      const stripeSignature = await fetchStripeSignature();
      const headersObject = new Headers(headers);
      headersObject.append("stripe-signature", stripeSignature);
      headersObject.append("Content-Type", "application/json");
      headersObject.append(
        "stripe-user-id",
        globalContext.userContext?.id ?? ""
      );
      headersObject.append(
        "stripe-account-id",
        globalContext.userContext?.account.id ?? ""
      );
      return fetch(uri, {
        ...options,
        headers: headersObject,
      });
    },
    [globalContext]
  );
}

Let's set up a very basic component for demonstrating the use of the useFetchWithCredentials hook. This component will be the default route for our app's navigation wrapper. It is going to handle more later. But for now, let's just implement a basic use for our hook. The AUTH_INIT_URL constant will point at our back-end's /api/oauth/userinfo endpoint.

Please note that, for this to work, you are going to need to install react-router-dom.

import { Box, Spinner } from "@stripe/ui-extension-sdk/ui";
import { useEffect } from "react";
import { useNavigate } from "react-router-dom";
import { AUTH_INIT_URL } from "../constants/auth.urls";
import { setUser } from "../auth/state";
import { useFetchWithCredentials } from "../hooks/useFetchWithCredentials";
export const AuthInit: React.FC<{ redirectPath: string }> = ({
  redirectPath,
}) => {
  // Please note, that we are going to set the whole routing up in a later article.
  const navigate = useNavigate();
  const fetchWithCredentials = useFetchWithCredentials();
  useEffect(() => {
    fetchWithCredentials(AUTH_INIT_URL)
      .then((user) => {
        // Make sure you set the user in your chosen global state management tool.
        setUser(user);
        // For now if the response is a success response (status 200), we are going to navigate to the first authenticated route.
        navigate(redirectPath);
      })
      .catch((e) => {
        console.error(e.message);
        // If the request returns with an error (status 401), it means that the user is unauthenticated, so we send them to the login page
        navigate("/login");
      });
  }, [redirectPath]);
  // Let's display a spinner while we wait for our initial request to return.
  return (
    <Box
      css={{
        layout: "column",
        alignX: "center",
        alignY: "center",
      }}
    >
      <Spinner size="large" />
      Loading...
    </Box>
  );
};

As we can see from the above implementation, this component will be the initial component that gets rendered inside of the application. It will send out a request to determine if the user is logged in. If they are logged in, we are going to send them to a route that is the first page of our application. If they are not signed in, we are going to redirect them to our login page. This initial call, just as every other API call, must be verified and always have a Stripe signature.

Let's visualise how routing looks like right now:

import type { ExtensionContextValue } from "@stripe/ui-extension-sdk/context";
import { ContextView } from "@stripe/ui-extension-sdk/ui";
import { GlobalContext } from "./common/global-context";
import { Route, Routes } from 'react-router-dom';
import { PaymentInfo } from './components/PaymentInfo;
const PaymentDetailView = ({
  userContext,
  environment,
}: ExtensionContextValue) => (
  <ContextView title={title || " "} description={description}>
    <GlobalContext.Provider value={{ userContext, environment }}>
      <Router basename="/" initialEntries={['/init']}>
        <Routes>
          <Route
            path="/init"
            element={<AuthInit redirectPath={'/payment-details'} />}
          />
          <Route path="/login" element={<Login />} />
          <Route path="/payment-details" element={<PaymentInfo />}>
        </Routes>
      </Router>
    </GlobalContext.Provider>
  </ContextView>
);
export default PaymentDetailView;

Stripe secrets and the Stripe API

In order to be able to use the Stripe NodeJS Api, you will need two secrets from Stripe. One is your Stripe account's API key, and the other one is your Stripe-app's secret. You need to set up your .env file as the following.

STRIPE_API_KEY='your api key goes here'
STRIPE_APP_SECRET='your app secret goes here'

Stripe API key

You can find your Stripe API key at https://dashboard.stripe.com/apikeys, under the Standard keys section. The key you are looking for is called Secret key, and you need to reveal it by clicking the button that hides it.

Stripe App Secret

For this key, you are going to need to upload your stripe-app using the stripe apps upload command. Make sure that you set a development app ID in your app manifest (stripe-app.json). After you uploaded your app, visit https://dashboard.stripe.com/apps. Under My Apps, you should see your uploaded application. Open it and search for the Signing secret. Reveal it and copy it into your .env file.

Stripe NodeJS API

Please make sure you have installed the stripe nmp package for your server code. In this example series, we use NestJS as our framework for our API. We need the above two secret keys to be able to start up our Stripe API.

// verify-signature.ts
import { BadRequestException, Logger } from "@nestjs/common";
import { Stripe } from "stripe";
const STRIPE_API = new Stripe(process.env.STRIPE_API_KEY, {
  apiVersion: "2020-08-27",
});
const APP_SECRET = process.env.STRIPE_APP_SECRET;
export function verifySignature(
  userId: string,
  accountId: string,
  signature: string,
  logger: Logger
): void {
  // Signature verification will come here
}

NestJS VerifySignatureInterceptor implementation

In NestJS, we can use interceptors to abstract away repetitive logic that needs to be done on multiple requests. In our case, we need to verify almost every API for a valid Stripe signature. We have access to the proper secret keys, and we have a Stripe NodeJS API set up. Let's create our VerifySignatureInterceptor.

import {
  BadRequestException,
  CallHandler,
  ExecutionContext,
  Injectable,
  Logger,
  NestInterceptor,
} from "@nestjs/common";
import { Request } from "express";
import { Observable } from "rxjs";
import { Stripe } from "stripe";
const STRIPE_API = new Stripe(process.env.STRIPE_API_KEY, {
  apiVersion: "2020-08-27",
});
const APP_SECRET = process.env.STRIPE_APP_SECRET;
@Injectable()
export class VerifySignatureInterceptor implements NestInterceptor {
  // We set up a logger instance, so we can properly log errors
  private readonly logger = new Logger(VerifySignatureInterceptor.name);
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const req: Request = context.switchToHttp().getRequest();
    const signature = req.headers["stripe-signature"] as string;
    const userId = req.headers["stripe-user-id"] as string;
    const accountId = req.headers["stripe-account-id"] as string;
    verifySignature(userId, accountId, signature, this.logger);
    return next.handle();
  }
}

Every interceptor must implement the intercept() method. We extract the Request object from the execution context, and we get the headers that we previously set in our useFetchWithCredentials hook. We call our verifySignature function which will throw errors if the signature is invalid. We also pass the Logger instance, so we can determine when an error comes from this interceptor in our logs.

Please be aware that there are several reasons signature verification can go wrong, like if we provide the wrong Stripe account keys or app secrets. In order for you to be able to easily debug these issues, proper logging is a must. That is why we set up a Logger instance in our interceptor.

// ...
export function verifySignature(
  userId: string,
  accountId: string,
  signature: string,
  logger: Logger
): void {
  if (!(user_id && account_id && signature)) {
    throw new BadRequestException("Missing user identifiers");
  }
  try {
    stripe.webhooks.signature.verifyHeader(
      JSON.stringify({ user_id, account_id }),
      signature,
      APP_SECRET
    );
  } catch (e: any) {
    logger.error(`Could not verify signature due to: ${e.message}`);
    throw new BadRequestException("Could not verify signature");
  }
}

If the user_id, account_id, or the signature are missing, that could mean that the request came from outside a stripe application, or the useFetchWithCredentials hook was not used. We throw a BadRequestException that will result in the request sending back a status: 400 HTTP response.

If the signature verification fails, that could mean that a not valid signature was used in the request, or that the API environment variables might have the wrong keys.

Set up the userinfo endpoint

Let's quickly set up our /api/oauth/userinfo endpoint. For that, we are going to create the OauthModule and the OauthController.

// oauth.module.ts
import { Module } from "@nestjs/common";
import { OauthController } from "./oauth.controller";
@Module({
  controllers: [OauthController],
})
export class OauthModule {}

In our controller, we decorate our getUserInfo() method, with the @Get() decorator, so we set up the route. We also decorate the method with the @UseInterceptors() decorator, where we pass our VerifySignatureInterceptor.

// oauth.controller.ts
import {
  Controller,
  Get,
  Headers,
  Logger,
  UnauthorizedException,
  UseInterceptors,
} from "@nestjs/common";
import { VerifySignatureInterceptor } from "./interceptors/verify-signature.interceptor";
import { UserInfo } from "../interfaces/user";
@Controller("oauth")
export class OauthController {
  // We set up our Logger instance here as well
  private readonly logger = new Logger(OauthController.name);
  @Get("userinfo")
  @UseInterceptors(VerifySignatureInterceptor)
  async getUserInfo(
    @Headers("stripe-account-id") accountId: string,
    @Headers("stripe-user-id") userId: string
  ): Promise<UserInfo> {
    // For now, we always throw an unauthorised exception, so our front-end will load the login page
    throw new UnauthorizedException();
  }
}

This setup will enable us to call the /api/oauth/userinfo endpoint which will, in-turn, check if we have a valid signature present in the headers. If the request is invalid, it will throw a 400 Bad Request exception. If the signature is valid, for now, we will throw a 401 Unauthorized exception just to make our front-end navigate to the login page.

Just to keep this example simple, our login page will only have a button in the center that will start our login flow with our API.

import fetchStripeSignature from '@stripe/ui-extension-sdk/signature';
import { LOGIN_URI } from '../../constants/url.constants';
import { Box, Button } from '@stripe/ui-extension-sdk/ui';
import { GlobalContext } from '../../common/global-context';
export const Login: React.FC = () => {
  const globalContext = useContext(GlobalContext);
  const [stateKey, setStateKey] = useState<string | null>(null);
  // setting the stateKey will be implemented here
  const queryParams = new URLSearchParams({
    state: stateKey as string,
  })
  // LOGIN_URI points to our API at the '/api/oauth/login' endpoint
  const loginUrl = `${LOGIN_URI}?${queryParams}`
  return (
      <Box css={{
            height: 'fill',
            width: 'fill,
            layout: 'row',
            alignX: 'center',
            alignY: 'center'
      }}>
        <Button
            type="primary"
            css={{
                width: 'fill',
                alignX: 'center',
            }}
            disabled={!stateKey}
            href={loginUrl}
        >
          Sign in
        </Button>
      </Box>
  )
}

We need to create a state key, that can be validated before we fetch the token. This state key will first be sent to our third-party oauth client, and it will be returned to us when the authentication is finished. This key is passed securely and over https. Therefore, it can be a stringified object. While the key is not set, we disable the button.

import fetchStripeSignature from "@stripe/ui-extension-sdk/signature";
import { LOGIN_URI } from "../../constants/url.constants";
import { Box, Button } from "@stripe/ui-extension-sdk/ui";
import { GlobalContext } from "../../common/global-context";
export const Login: React.FC = () => {
  const globalContext = useContext(GlobalContext);
  const [stateKey, setStateKey] = useState<string | null>(null);
  useEffect(() => {
    // we create an async function which will get all the necessary data and then call JSON.stringify() on it
    const getStateKey = async () => {
      const signature = await fetchStripeSignature();
      const userId = globalContext.userContext?.id;
      const accountId = globalContext.userContext?.account.id;
      return JSON.stringify({ userId, accountId, signature });
    };
    getStateKey().then(setStateKey);
  }, [globalContext.userContext]);
  const queryParams = new URLSearchParams({
    state: stateKey as string,
  });
  // LOGIN_URI points to our API at the '/api/oauth/login' endpoint
  const loginUrl = `${LOGIN_URI}?${queryParams}`;
  return {
    /* ... */
  };
};

Pressing the Sign in button will call our API that will redirect us to our third-party login screen. When the login happens, it will redirect us to our API, where we can fetch a valid token and redirect again to the Stripe dashboard. Let's extend our environment variables.

STRIPE_API_KEY='your api key goes here'
STRIPE_APP_SECRET='your app secret goes here'
STRIPE_REDIRECT_URL='https://dashboard.stripe.com/test/apps-oauth/your.app.id'
## The above url is set to the development preview redirect url. In production, this url will look like the following:
## STRIPE_REDIRECT_URL='https://dashboard.stripe.com/apps-oauth/your.app.id'
## Don't forget that your app-id in development and in production should be different
THIRD_PARTY_CLIENT_ID='your client id goes here'
THIRD_PARTY_CLIENT_SECRET='your client secret goes here'
THIRD_PARTY_URL_BASE='https://third-party.com'
API_HOST_URL='http://localhost:3333'
## In production, the above url should point to your deployed back-end

Now that we have every environment variable set up, let's implement our api/oauth/login and api/oauth/authorise endpoints in our OauthController.

// ...
const THIRD_PARTY_OAUTH_URL = `${process.env.THIRD_PARTY_URL_BASE}/oauth`;
const API_AUTH_CALLBACK_URL = `${process.env.API_HOST_URL}/api/oauth/authorise`;
@Controller("oauth")
export class OauthController {
  // ...
  @Get("login")
  @Redirect(THIRD_PARTY_OAUTH_URL, 303)
  // the HasValuePipe checks if the state is not an empty string or undefined.
  login(@Query("state", HasValuePipe) state: string): { url: string } {
    const queryParams = new URLSearchParams({
      response_type: "code",
      client_id: process.env.THIRD_PARTY_CLIENT_ID,
      redirect_uri: API_AUTH_CALLBACK_URL,
      state,
    });
    // with the query parameters set, we redirect to our third-party oauth page
    return {
      url: `${THIRD_PARTY_OAUTH_URL}?${queryParams.toString()}`,
    };
  }
}

The login endpoint, if everything is correct, redirects us to the login page where the user should be able to log in. Make sure that if you oauth client needs to have configured redirect urls, you configure them. For example, for development, the http://localhost:3333/api/oauth/authorise endpoint should be in the allowed redirect url list.

@Controller("oauth")
export class OauthController {
  // ...
  @Get("authorize")
  @Redirect(process.env.STRIPE_REDIRECT_URL, 303)
  async loggedIn(
    @Query("state", HasValuePipe) state: string,
    @Query("code", HasValuePipe) code: string
  ) {
    // If either the state or the code is missing, we return with a 400 Bad Request response
    if (!state || !code) {
      throw new BadRequestException();
    }
    let userId: string;
    let accountId: string;
    let signature: string;
    try {
      const _ = ({ userId, accountId, signature } = JSON.parse(state));
    } catch (error: any) {
      // If the state is not a valid JSON we can be sure that we won't be able to
      this.logger.error(`Invalid state returned to the authorise endpoint`);
      throw new BadRequestException();
    }
    // We verify the signature to make sure it comes from our Stripe app.
    verifySignature(userId, accountId, signature, this.logger);
    // see implementation below
    await this.fetchToken(accountId, userId, code).catch(
      (error: AxiosError) => {
        if (error.response) {
          throw new UnauthorizedException();
        }
        throw new InternalServerErrorException(
          "Cannot contact authentication server"
        );
      }
    );
  }
}

We validate everything to be sure that this endpoint was called from our third-party OAuth page. With the information available to us, we can fetch the access token and store it in the Stripe Secret Storage. In this example, we use axios in our bakc-end to send requests to our third-party API.

// ...
const THIRD_PARTY_TOKEN_URI = `${process.env.THIRD_PARTY_URL_BASE}/token`;
@Controller("oauth")
export class OauthController {
  // ...
  constructor(private secretService: SecretService) {}
  // ...
  private async fetchToken(
    accountId: string,
    userId: string,
    code: string
  ): Promise<void> {
    const data = {
      grant_type: "authorization_code",
      client_id: process.env.THIRD_PARTY_CLIENT_ID,
      client_secret: process.env.THIRD_PARTY_CLIENT_SECRET,
      code,
    };
    const response = await axios.post(THIRD_PARTY_TOKEN_URI, data, {
      responseType: "json",
    });
    // Please note that the third-party API you integrate with might have a different response structure.
    const { access_token } = response.data;
    // We set the token in the secret store. See the implementation below. The Secret Store only accepts strings as values.
    // The accountId is needed so we can scope the request to the requestor user's Stripe account.
    // The userId is needed so we can use the requestor user's secrets
    // We set the secret name to 'access_token', and we pass the token as its value.
    await this.secretService.addSecret(
      accountId,
      userId,
      "access_token",
      access_token
    );
  }
}

We exchange our code returned from our OAuth client to a valid access token, and then store it in the Stripe Secret Store. That logic got extracted into a SecretService class, because the logic implemented in it can be reused later for other API calls. Please make sure you set up a NestJS module that exports this service.

Stripe Secret Store

Stripe's Secret Store API enables your app to securely store and retrieve strings that can be authentication credentials, tokens, etc. This API enables users to stay logged in to third party services even when they log out of their Stripe dashboard. Let's set up a service that handles access to the Secret Store on our back-end.

import { Stripe } from "stripe";
interface Secret {
  id: string;
  name: string;
  payload: string;
}

// With the below setup, we can communicate with the Stripe Secret Store.
const SecretResource = Stripe.StripeResource.extend({
  find: Stripe.StripeResource.method({
    method: "GET",
    path: "apps/secrets/find",
  }) as (...args: any[]) => Promise<Secret>,
  set: Stripe.StripeResource.method({
    method: "POST",
    path: "apps/secrets",
  }) as (...args: any[]) => Promise<Secret>,
  delete: Stripe.StripeResource.method({
    method: "POST",
    path: "apps/secrets/delete",
  }) as (...args: any[]) => Promise<Secret>,
});
@Injectable()
export class SecretService {
  // To make calls for connected accounts, we should create a new Stripe API instance every time.
  private getSecretResource(stripeAccount: string): Stripe {
    const client = new Stripe(process.env.STRIPE_API_KEY, {
      apiVersion: "2020-08-27",
      stripeAccount,
    });
    return new SecretResource(client);
  }
}

Adding secrets

As we can see above, the Secret Storage needs some preliminary setup, which we do in our SecretService. The StripeResource sets up the find, set, and delete methods on the Stripe Api, and interacts with the Secret Store. Let's implement the addSecret method, so we can actually store our returned token.

import { Stripe } from "stripe";
interface Secret {
  id: string;
  name: string;
  payload: string;
}
@Injectable()
export class SecretService {
  // ...
  async addSecret(
    accountId: string,
    userId: string,
    secretName: string,
    value: string
  ): Promise<Secret | null> {
    return this.getSecretResource(accountId)
      .set({
        "scope[type]": "user",
        "scope[user]": userId,
        name: secretName,
        payload: value,
      })
      .catch((error: any) => {
        this.logger.error(
          `Could not set secret to Stripe Secret Store: ${error.statusCode} - ${error.message}`
        );
        return null;
      });
  }
}

With the above, we can finally store our token with which we can make authenticated requests.

Getting secrets

Let's implement the getSecret so we can retrieve secrets. The principles are the same. We will need the accountId, the userId, and the secret's name for it.

import { Stripe } from "stripe";
interface Secret {
  id: string;
  name: string;
  payload: string;
}
@Injectable()
export class SecretService {
  // ...
  async getSecret(
    accountId: string,
    userId: string,
    secretName: string
  ): Promise<Secret | null> {
    const secret = await this.getSecretResource(accountId)
      .find({
        "scope[type]": "user",
        "scope[user]": userId,
        name: secretName,
        "expand[]": "payload",
      })
      .catch((error: any) => {
        if (error.statusCode === 404) {
          throw new UnauthorizedException();
        } else {
          this.logger.error(
            `Could not get secret from Stripe Secret Store: ${error.statusCode} - ${error.message}`
          );
          return null;
        }
      });
    if (!secret) {
      throw new UnauthorizedException();
    }
    return secret.payload;
  }
}

Let's close the login flow, and implement the final version of the api/oauth/userinfo endpoint.

// ...
const THIRD_PARTY_WHO_AM_I_URL = `${process.env.THIRD_PARTY_URL_BASE}/oauth/whoami`;
@Controller("oauth")
export class OauthController {
  // ...
  constructor(private secretService: SecretService) {}
  @Get("userinfo")
  @UseInterceptors(VerifySignatureInterceptor)
  async getUserInfo(
    @Headers("stripe-account-id") accountId: string,
    @Headers("stripe-user-id") userId: string
  ): Promise<UserInfo> {
    const token = await this.secretService.getSecret(
      accountId,
      userId,
      "access_token"
    );

  const user = await axios
      .get<UserInfo>(THIRD_PARTY_WHO_AM_I_URL, {
        responseType: "json",
        headers: {
          authorization: `Bearer ${token}`,
        },
      })
      .catach(() => {
        throw new UnauthorizedException();
      });
    // We add an extra layer of security by requiring the user to verify their e-mail.
    if (!user.email_verified) {
      throw new UnauthorizedException();
    }
    return user;
  }
}

Deleting secrets

We want our users to have ability to log out from our third-party API as well. That can be achieved by deleting their access_token from the Secret store.

import { Stripe } from "stripe";
// ...
@Injectable()
export class SecretService {
  // ...
  async deleteSecret(
    accountId: string,
    userId: string,
    secretName: string
  ): Promise<boolean> {
    return this.getSecretResource(accountId)
      .delete({
        "scope[type]": "user",
        "scope[user]": userId,
        name: secretName,
      })
      .then(() => true)
      .catch((error: any) => {
        this.logger.error(
          `Could not delete secret from Stripe Secret Store: ${error.statusCode} - ${error.message}`
        );
        return false;
      });
  }
}

The /api/oauth/logout endpoint is going to be a GET request, that will delete the token from the Secret Store.

// ...
@Controller("oauth")
export class OauthController {
  // ...
  @Get("logout")
  @HttpCode(204)
  @UseInterceptors(VerifySignatureInterceptor)
  async deleteToken(
    @Headers("stripe-account-id") accountId: string,
    @Headers("stripe-user-id") userId: string
  ): Promise<boolean> {
    return this.secretService.deleteToken(accountId, userId, "access_token");
  }
}

We can create a SignOutLink that will send the request to our back-end and navigates to the /login page. You can put this component into the footerContent property of your ContextView.

import { LOGOUT_URI } from "../../constants/url.constants";
import { useFetchWithCredentials } from "../../hooks/useFetchWithCredentials";
import { Link } from "@stripe/ui-extension-sdk/ui";
import { useNavigate } from "react-router-dom";
export const SignOutLink = () => {
  const navigate = useNavigate();
  const fetchWithCredentials = useFetchWithCredentials();
  return (
    <Link
      onPress={() => {
        fetchWithCredentials(LOGOUT_URI).then(() => {
          navigate("/logout");
        });
      }}
    >
      Sign out
    </Link>
  );
};

And now we are ready with our authentication setup. When the user opens our app, it will call the /api/oauth/userinfo endpoint. Initially, it will return with a 401 error, and our front-end will navigate to the /login route. When the user presses the Sign in button, it will redirect them to the third-party OAuth page. After they log in, our back-end also redirects them back to their Stripe dashboars where the application will open. The app will call the /api/oauth/userinfo endpoint again. But this time, it will return an actual user information and it routes to the protected route.

To help visualize the whole flow, you can also use the following sequence diagram for reference:

Conclusion

As you can see, there are many steps involved in setting up a proper OAuth flow. However, it's necessary to make it right, since this is the most critical part of the app. We hope blog post article will help you to set up some good foundations when implementing your own Stripe app.

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.

Balázs Tápai

He is a Software Engineer with a passion for automated testing. He loves Angular on the Front-End and NestJS on the Back-End. He also uses Cypress to reduce developer anxiety before demo meetings.

@TapaiBalazs @TapaiBalazs

Dario Djuric

Dario is a full-stack engineer who has spent most of his career doing enterprise Java projects. He has always had a hidden passion for frontend, though -- and he is now able to pursue that passion at This Dot. He spends most of his free time with his two sons, but occasionally, he manages to squeeze in some casual sports activities such as jogging, cycling, and soccer.

@dario_djuric @dariodjuric

Deploying apps and services to AWS using AWS Copilot CLI

Copilot has become a household name for developers, all thanks to GitHub’s popular AI tooling. Before GitHub released Copilot, AWS already had a developer tool in the wild, also named Copilot. I stumbled across AWS Copilot a year or two ago and found it to be a really great tool for easily deploying Serverless applications and services to AWS infrastructure. Since deploying to AWS has been such a huge pain point for so many developers, Copilot CLI is one of many tools that is designed to make this process a lot easier. AWS Copilot is a command-line interface (CLI) that simplifies the process of deploying and managing containerized applications on AWS. It abstracts away the complexity of managing infrastructure, allowing us to focus on writing code. This blog post will provide an overview of AWS Copilot CLI and explore its practical use cases. AWS Copilot CLI is designed to simplify the building, releasing, and operating of production-ready containerized applications on Amazon ECS and AWS Fargate. It offers an intuitive interface for developers to launch and manage environments, jobs, pipelines, and services in the cloud. Although ECS and Fargate are considered ‘Serverless’; you are actually deploying to more traditional, stateful, web servers on EC2 _(these are cool again)_. Installation You can install the Copilot CLI using Homebrew. ` Otherwise use one of the scripts from the installation page. Credentials You need to add AWS credentials with proper permissions to your ~/aws/.credentials file to use Copilot. See the credentials docs for more details on this. ` Overview All you need is a Dockerfile that knows how to build and run your application and Copilot will handle the rest. Copilot provides a simple declarative set of commands, including examples and guided experiences built-in. These commands make it easy to start from scratch and get a containerized application running in the cloud in just a few steps. The configuration files that Copilot generates (called manifests) allow us to easily configure and adjust the amount of compute resources available to our web service _(cpu, memory, instances, etc)_. Here’s an architecture diagram for a load-balanced web service running on AWS and deployed with Copilot. The outermost layer is the region your application is deployed to on AWS ie: us-east-1, us-west-1, etc. Copilot handles all the networking for your application which includes a VPC, and public subnets that your server instances can be reached from. The load balancer (ALB) sits at the top, listens for requests, and directs traffic to the ECS Cluster (instances of your application server). Typically, the work involved with setting all of these pieces up and getting them working together is cumbersome to put it lightly. Concepts Before we dive into some of the commands, a quick look at the concepts that Copilot is built on so we have a clear understanding of what we can achieve with it. Applications Applications in Copilot is the top-level parent of all the AWS infrastructure managed by your Copilot setup. In this article I will generally refer to an application as any kind of software that you are deploying (api server, etc). In Copilot your ‘Application’ is the entire collection of all the environments and services that you have configured. Here’s the diagram from the documentation. The Vote application can consist of a number of different services, jobs, pipelines, etc. Services In AWS Copilot, “Services” refer to the type of application (not to be confused with the definition of Application in the previous section) that you’re deploying and the underlying AWS service infrastructure that supports it. Using the Load Balanced Web Service service from the diagram above, the service consists of the ECS (Elastic Container Service) service, the application load balancer, and the network load balancer. These are some of the AWS infrastructure that Copilot orchestrates for you when deploying this type of “Service”. There are a few main types of services that you can deploy with Copilot - Internet-facing web services (Static Site, Load Balanced Web Service, etc) - Backend services (services that can only be accessed internally) - Worker services (pub/sub queues, etc) Environments When setting up your project and your first service you will supply Copilot with the name of the environment you want to deploy to. For example, you can create a production environment initially to deploy your application and services to and then later on add additional environments like a staging environment. Jobs You might also know these as ‘crons’ but these are just tasks or some code that runs on a schedule. Pipelines Pipelines are for automating tests and releases. This is AWS’s CI/CD service somewhat similar to something like GitHub actions. Copilot can initialize and create new pipelines for you. We can configure this as a manifest in our codebase that declares instructions on how we build and deploy our application(s). Configuration Copilot is configured through various configuration files called ‘Manifests’. The documentation contains examples on how to configure your application, services, environments, jobs, and pipelines. You can also refer to it to learn what options are available. Since Copilot is a CLI tool they make a lot of the configuration process pretty painless by providing walkthrough prompts and generating configuration files for you. The CLI Now that we have a pretty good idea of what AWS Copilot is and the types of things we can accomplish with it, let's walk through using the CLI. ` This is where you will most likely want to start to get your application ready for deployment to AWS. The init command will prompt you with questions like what kind of service you want to generate and once you’re done, it will generate all the initial configuration files for you. Example setup: ` You’ll pick your service type, tell Copilot where your Dockerfile lives, name your environment, and let it do its magic from there. Copilot will generate your Manifest/config files which in turn become CloudFormation stacks that set up all your infrastructure on AWS. Other Commands There are commands for each concept that we covered above. There are Create, Delete, and Deploy operation commands for Environments, Services, Jobs, and Pipelines. If you wanted to add a staging environment to your application you could just run copilot env init . There are also commands to manage your Application or things like tasks. To see details about your Application you can run copilot app show -n [name] Conclusion AWS Copilot CLI is a powerful tool that simplifies the deployment and management of containerized applications on AWS. It abstracts away the complexities of the underlying infrastructure, allowing developers to focus on writing code and delivering value to their customers. Whether you're deploying a simple web service or managing multiple environments, AWS Copilot CLI can make your cloud development process more efficient and enjoyable....

Jan 3, 2024

6 mins

AWSToolingDocker

Understanding Vue's Reactive Data

Introduction Web development has always been about creating dynamic experiences. One of the biggest challenges developers face is managing how data changes over time and reflecting these changes in the UI promptly and accurately. This is where Vue.js, one of the most popular JavaScript frameworks, excels with its powerful reactive data system. In this article, we dig into the heart of Vue's reactivity system. We unravel how it perfectly syncs your application UI with the underlying data state, allowing for a seamless user experience. Whether new to Vue or looking to deepen your understanding, this guide will provide a clear and concise overview of Vue's reactivity, empowering you to build more efficient and responsive Vue 3 applications. So, let’s kick off and embark on this journey to decode Vue's reactive data system. What is Vue's Reactive Data? What does it mean for data to be ”'reactive”? In essence, when data is reactive, it means that every time the data changes, all parts of the UI that rely on this data automatically update to reflect these changes. This ensures that the user is always looking at the most current state of the application. At its core, Vue's Reactive Data is like a superpower for your application data. Think of it like a mirror - whatever changes you make in your data, the user interface (UI) reflects these changes instantly, like a mirror reflecting your image. This automatic update feature is what we refer to as “reactivity”. To visualize this concept, let's use an example of a simple Vue application displaying a message on the screen: ` In this application, 'message' is a piece of data that says 'Hello Vue!'. Let's say you change this message to 'Goodbye Vue!' later in your code, like when a button is clicked. ` With Vue's reactivity, when you change your data, the UI automatically updates to 'Goodbye Vue!' instead of 'Hello Vue!'. You don't have to write extra code to make this update happen - Vue's Reactive Data system takes care of it. How does it work? Let's keep the mirror example going. Vue's Reactive Data is the mirror that reflects your data changes in the UI. But how does this mirror know when and what to reflect? That's where Vue's underlying mechanism comes into play. Vue has a behind-the-scenes mechanism that helps it stay alerted to any changes in your data. When you create a reactive data object, Vue doesn't just leave it as it is. Instead, it sends this data object through a transformation process and wraps it up in a Proxy. Proxy objects are powerful and can detect when a property is changed, updated, or deleted. Let's use our previous example: ` Consider our “message” data as a book in a library. Vue places this book (our data) within a special book cover (the Proxy). This book cover is unique - it's embedded with a tracking device that notifies Vue every time someone reads the book (accesses the data) or annotates a page (changes the data). In our example, the reactive function creates a Proxy object that wraps around our state object. When you change the 'message': ` The Proxy notices this (like a built-in alarm going off) and alerts Vue that something has changed. Vue then updates the UI to reflect this change. Let’s look deeper into what Vue is doing for us and how it transforms our object into a Proxy object. You don't have to worry about creating or managing the Proxy; Vue handles everything. ` In the example above, we encapsulate our object, in this case, “state”, converting it into a Proxy object. Note that within the second argument of the Proxy, we have two methods: a getter and a setter. The getter method is straightforward: it merely returns the value, which in this instance is “state.message” equating to 'Hello Vue!' Meanwhile, the setter method comes into play when a new value is assigned, as in the case of “state.message = ‘Hey young padawan!’”. Here, “value” becomes our new 'Hey young padawan!', prompting the property to update. This action, in turn, triggers the reactivity system, which subsequently updates the DOM. Venturing Further into the Depths If you have been paying attention to our examples above, you might have noticed that inside the Proxy method, we call the functions track and trigger to run our reactivity. Let’s try to understand a bit more about them. You see, Vue 3 reactivity data is more about Proxy objects. Let’s create a new example: ` In this example, when you click on the button, the message's value changes. This change triggers the effect function to run, as it's actively listening for any changes in its dependencies. How does the effect property know when to be called? Vue 3 has three main functions to run our reactivity: effect, track, and trigger. The effect function is like our supervisor. It steps in and takes action when our data changes – similar to our effect method, we will dive in more later. Next, we have the track function. It notes down all the important data we need to keep an eye on. In our case, this data would be state.message. Lastly, we've got the trigger function. This one is like our alarm bell. It alerts the effect function whenever our important data (the stuff track is keeping an eye on) changes. In this way, trigger, track, and effect work together to keep our Vue application reacting smoothly to changes in data. Let’s go back to them: ` Tracking (Dependency Collection) Tracking is the process of registering dependencies between reactive objects and the effects that depend on them. When a reactive property is read, it's "tracked" as a dependency of the current running effect. When we execute track(), we essentially store our effects in a Set object. But what exactly is an "effect"? If we revisit our previous example, we see that the effect method must be run whenever any property changes. This action — running the effect method in response to property changes — is what we refer to as an "Effect"! (computed property, watcher, etc.) > Note: We'll outline a basic, high-level overview of what might happen under the hood. Please note that the actual implementation is more complex and optimized, but this should give you an idea of how it works. Let’s see how it works! In our example, we have the following reactive object: ` We need a way to reference the reactive object with its effects. For that, we use a WeakMap. Which type is going to look something like this: ` We are using a WeakMap to set our object state as the target (or key). In the Vue code, they call this object targetMap. Within this targetMap object, our value is an object named depMap of Map type. Here, the keys represent our properties (in our case, that would be message and showSword), and the values correspond to their effects – remember, they are stored in a Set that in Vue 3 we refer to as dep. Huh… It might seem a bit complex, right? Let's make it more straightforward with a visual example: With the above explained, let’s see what this Track method kind of looks like and how it uses this targetMap. This method essentially is doing something like this: ` At this point, you have to be wondering, how does Vue 3 know what activeEffect should run? Vue 3 keeps track of the currently running effect by using a global variable. When an effect is executed, Vue temporarily stores a reference to it in this global variable, allowing the track function to access the currently running effect and associate it with the accessed reactive property. This global variable is called inside Vue as activeEffect. Vue 3 knows which effect is assigned to this global variable by wrapping the effects functions in a method that invokes the effect whenever a dependency changes. And yes, you guessed, that method is our effect method. ` This method behind the scenes is doing something similar to this: ` The handling of activeEffect within Vue's reactivity system is a dance of careful timing, scoping, and context preservation. Let’s go step by step on how this is working all together. When we run our Effect method for the first time, we call the get trap of the Proxy. ` When running the get trap, we have our activeEffect so we can store it as a dependency. ` This coordination ensures that when a reactive property is accessed within an effect, the track function knows which effect is responsible for that access. Trigger Method Our last method makes this Reactive system to be complete. The trigger method looks up the dependencies for the given target and key and re-runs all dependent effects. ` Conclusion Diving into Vue 3's reactivity system has been like unlocking a hidden superpower in my web development toolkit, and honestly, I've had a blast learning about it. From the rudimentary elements of reactive data and instantaneous UI updates to the intricate details involving Proxies, track and trigger functions, and effects, Vue 3's reactivity is an impressively robust framework for building dynamic and responsive applications. In our journey through Vue 3's reactivity, we've uncovered how this framework ensures real-time and precise updates to the UI. We've delved into the use of Proxies to intercept and monitor variable changes and dissected the roles of track and trigger functions, along with the 'effect' method, in facilitating seamless UI updates. Along the way, we've also discovered how Vue ingeniously manages data dependencies through sophisticated data structures like WeakMaps and Sets, offering us a glimpse into its efficient approach to change detection and UI rendering. Whether you're just starting with Vue 3 or an experienced developer looking to level up, understanding this reactivity system is a game-changer. It doesn't just streamline the development process; it enables you to create more interactive, scalable, and maintainable applications. I love Vue 3, and mastering its reactivity system has been enlightening and fun. Thanks for reading, and as always, happy coding!...

Nov 22, 2023

7 mins

VueJavaScriptTypeScriptWeb Development

Introducing the express-typeorm-postgres Starter Kit

Here at This Dot, we've been working with ExpressJS APIs for a while, and we've created a starter.dev kit for ExpressJS that you can use to scaffold your next backend project. The starter kit uses many well-known npm packages, such as TypeORM or BullMQ and integrates with databases such as PostgreSQL and Redis. Kit contents The express-typeorm-postgres starter kit provides you with infrastructure for development, and integrations with these infrastructures. It comes with a working Redis instance for caching and a second Redis instance for queues. It also starts up a Postgres instance for you, which you can seed with TypeORM. The infrastructure runs on docker using docker-compose. The generated project comes with prettier and eslint set-up, so you only need to spend time on configuration if you want to tweak or change the existing rules. Unit testing is set up using Jest, and there are some example tests provided with the example controllers. How to initialise API development usually requires more infrastructure than front-end development. Before you start, please make sure you have docker and docker-compose installed on your machine. To initialize a project with the express-typeorm-postgres kit, run the following: 1. Run npx @this-dot/create-starter to run the scaffolding tool 2. Select the Express.js, TypeORM, and PostgreSQL kit from the CLI library options 3. Name your project 4. cd into your project directory, and install dependencies using the tool of your choice (npm, yarn or pnpm) 5. copy the contents of the .env.example file into a .env file With this setup, you have a working starter kit that you can modify to your needs. TypeORM and Database When we started developing the kit, we decided to use PostgreSQL as the database, because it is a powerful, open-source object-relational database system that is widely used for storing and manipulating data. It has a strong reputation for reliability, performance, and feature richness, making it a great choice for a wide range of applications. It can also handle high levels of concurrency and large amounts of data, and supports complex queries and data types. Postgres is also highly extensible because it allows developers to add custom functions and data types to the database. It has a large and active community of developers and users who contribute to its ongoing development and support. The kit uses TypeORM to connect to the database instance. We chose TypeORM because it makes it easy to manage database connections and perform common database operations, such as querying, inserting, updating and deleting data. It supports TypeScript and a wide range of databases, such as PostgreSQL, MySQL, SQLite and MongoDB, therefore if you want to be able to switch between databases, it makes it easier. TypeORM also includes features such as database migrations, which help manage changes to database schema over time, and an entity model that allows you to define your database schema using classes and decorators. Overall, TypeORM is a useful tool for improving the efficiency and reliability of database-related code, and it can be a valuable addition to any TypeScript or JavaScript project that needs to interact with a database. To seed an initial set of data into your database, run the following commands: 1. npm run infrastructure:start - this starts up the database instance 2. npm run db:seed - this leverages TypeORM to seed the database. The seed command runs the src/db/run-seeders.ts file, where you can introduce your seeders for your own needs. The kit uses TypeORM-extension for seeding. Please refer to the src/db/seeding/technology-seeder.ts file for an example. Caching Storing response data in caches allows subsequent requests for the same data to be served more quickly. This can improve the performance and user experience of an API by reducing the amount of time it takes to retrieve data from the server. It can reduce the load on the database or mitigate rate limiting on third-party APIs called from your back-end. It also improves the reliability of an application by providing a fallback mechanism in case the database or the server is unavailable or slow to respond. There is a Redis instance set up in the kit to be used for caching data. Under the hood, we use the cachified library to store cached data in Redis. The kit has a useCache method exported from src/cache/cache.ts, which requires a key and a callback function to be called to fetch the data. ` When you need to invalidate cache entries, you can use the clearCacheEntry method by supplying a key string to it. It will remove the cached data from Redis, and the next request that fetches from the database will cache the new values. ` Under the src/modules/technology folder, you can see a complete example of a basic CRUD REST endpoint with caching enabled. Feel free to use those handlers as examples for your development needs. Queue A message queue allows different parts of an application, or different applications, to communicate with each other asynchronously by sending and receiving messages. This can be useful in a variety of situations, such as when one part of the application needs to perform a task that could take a long time, or when different parts of the application need to be decoupled from each other for flexibility and scalability. We chose BullMQ because it is a fast, reliable, and feature-rich message queue system. It is built on top of the popular Redis in-memory data store, which makes it very performant and scalable. It has support for parallel processing, rate limiting, retries, and a variety of other features that make it well-suited for a wide range of use cases. BullMQ has a straightforward API and good documentation. The kit has a second Redis instance set up to be used with BullMQ, and there is a queue set up out of the box, so resource-intensive tasks can be offloaded to a background process. The src/queue/ folder contains all the configuration and setup steps for the queue. Both the queue and its worker is set up in the queue.ts file. The job-processor.ts file contains the function that will process the data. To run int in a separate thread, we must pass the path to this file into the worker: ` When to use this kit This kit is most optimal when you: - want to build back-end services that can be consumed by other applications and services using ExpressJS - need a flexible and scalable way to build server-side applications - need to deal with CPU-intense operations on the server and you need a messaging queue - need to build an API with relational data - would like to just jump right into API development with ExpressJS using TypeORM and Postgres Conclusion The express-typeorm-postgres starter kit can help you kickstart your development by providing you with a working preset. It has testing configured, and it comes with a complete infrastructure orchestrated by docker-compose....

Jan 13, 2023

5 mins

NodeJSExpress.jsTypeScriptPostgreSQL

Transforming Auth in an AI World with Rod Boothby

In today's digital landscape, the need for secure identity verification has become paramount. With the increasing risks of personal data exposure and the rise of sophisticated cyber threats aided by Artificial Intelligence, it is crucial to adopt robust verification processes to protect individuals and organizations alike. In a recent discussion with Rod Boothby, CEO of ID Partner Systems, the significance of trusted institutions for identity verification was emphasized, particularly the efficiency of bank-based ID verification over traditional methods. One of the key takeaways from the conversation was the importance of continuous authentication. As technology advances, so do the methods employed by cybercriminals. Deepfake technology, for instance, poses a significant threat to identity verification systems. To combat this, tighter security measures and continuous authentication are essential. By constantly verifying and validating user identities, organizations can stay one step ahead of potential fraudsters. Rod Boothby also highlighted the need for a developer-focused approach to identity verification. By providing developers with the tools and resources they need, companies like ID Partner Systems aim to streamline the verification process and enhance security. This approach not only ensures a more efficient experience for users but also allows for the integration of behavioral biometrics, which can further strengthen the verification process. Download this episode here....

Apr 22, 2024

1 min

Engineering Leadership

How to Set Up OAuth with a Stripe App

Stripe signatures

useFetchWithCredentials hook

Stripe secrets and the Stripe API

Stripe API key

Stripe App Secret

Stripe NodeJS API

NestJS VerifySignatureInterceptor implementation

Set up the userinfo endpoint

Stripe Secret Store

Adding secrets

Getting secrets

Deleting secrets

Conclusion

Balázs Tápai

Dario Djuric

You might also like

Deploying apps and services to AWS using AWS Copilot CLI

Understanding Vue's Reactive Data

Introducing the express-typeorm-postgres Starter Kit

Transforming Auth in an AI World with Rod Boothby

You might also like

Deploying apps and services to AWS using AWS Copilot CLI

Understanding Vue's Reactive Data

Introducing the express-typeorm-postgres Starter Kit

Transforming Auth in an AI World with Rod Boothby

Stripe signatures

useFetchWithCredentials hook

Stripe secrets and the Stripe API

Stripe API key

Stripe App Secret

Stripe NodeJS API

NestJS VerifySignatureInterceptor implementation

Set up the userinfo endpoint

The Login flow

Stripe Secret Store

Adding secrets

Getting secrets

Deleting secrets

Conclusion

Balázs Tápai

Dario Djuric

Deploying apps and services to AWS using AWS Copilot CLI

Understanding Vue's Reactive Data

Introducing the express-typeorm-postgres Starter Kit

Transforming Auth in an AI World with Rod Boothby

Deploying apps and services to AWS using AWS Copilot CLI

Understanding Vue's Reactive Data

Introducing the express-typeorm-postgres Starter Kit

Transforming Auth in an AI World with Rod Boothby