In this article
January 20, 2026
January 20, 2026

Fetch GitHub repo data for your users without OAuth using WorkOS Pipes

Build a Next.js app that lets users connect GitHub and list their repos with a refreshed access token, without implementing OAuth.

Many applications need data from tools their users already use, like GitHub, CRMs, or internal services. While the APIs are usually straightforward, connecting user accounts and managing OAuth flows, tokens, and refresh logic often adds a lot of complexity.

WorkOS Pipes removes that overhead. Pipes lets users connect third-party services to your app, while WorkOS handles the OAuth flow, credential storage, and token refresh for you. Your application just asks for a valid access token when it needs data and uses it to call the provider API.

In this tutorial, you will use Pipes to connect GitHub and fetch repository data in a Next.js app. You will:

  • Use the Pipes widget to let users connect and manage their GitHub account.
  • Fetch a refreshed GitHub access token from WorkOS on the backend.
  • Call the GitHub API to list repositories for the authenticated user.

The same pattern can be used to connect other data sources and bring external data into your application without building OAuth plumbing yourself.

What are WorkOS Pipes

Pipes allows your users to securely connect their third-party accounts to your application. With Pipes, you can easily integrate with popular services like GitHub, Slack, Google, Salesforce, and many more without managing OAuth flows, token refresh logic, or credential storage.

At a high level:

  1. You configure a provider (like GitHub) in the WorkOS dashboard.
  2. Your app renders the Pipes widget so users can connect and manage accounts.
  3. Your backend calls WorkOS to fetch a provider access token whenever it needs to call the provider API.
  4. Pipes refreshes tokens for you so you always get a usable token.
  5. Use that token in your app to retrieve any data you need from the configured provider (e.g., GitHub repos)

Step 1: Configure GitHub

In the WorkOS Dashboard, go to Pipes.

Screenshot of the Pipes page in the WorkOS dashboard

Click Connect provider and select GitHub.

Screenshot of the GitHub provider option in the WorkOS dashboard

Choose your scopes. For listing repos (public and private), select repo. For more details on what each scope gives access to, see GitHub OAuth Scopes.

Screenshot of setting up scopes for the GitHub integration in the WorkOS dashboard

Add an optional description. This shows up in the widget to explain how your app uses the data.

For the fastest setup, go ahead and use the shared credentials option. This will allow users to connect immediately (using WorkOS-managed shared credentials) without requiring you to create OAuth applications with GitHub. This option is available for sandbox environments only.

For production environments, configure the provider with your own OAuth credentials. Create a GitHub app using the provided Redirect URI, and set the Client ID and Client Secret to the GitHub popup dialog box in the WorkOS dashboard.

Step 2: Add the Pipes Widget

Next we will add the Pipes widget to your app.

The Pipes widget is a pre-built UI that shows available providers and lets users connect and manage accounts. It displays a list of all the 3rd party services you have enabled and the user has the option to connect them or not.

Screenshot of the Pipes Widget

In order to add the widget to our app we need to install some depedencies, configure keys and URLs, and then get a valid token for the user.

2a. Install dependencies

WorkOS Widgets uses Radix Themes for its UI components and style customization APIs, while TanStack Query is used for data fetching and caching. Since both libraries are often used in applications, we require them as peer dependencies to avoid duplication, version conflicts, and bloated bundles.

Install these dependencies:

	
npm install @workos-inc/widgets @radix-ui/themes @tanstack/react-query
	

2b. Configure WorkOS API key and CORS

Next, because WorkOS widgets issue client-side requests to WorkOS, it is necessary to configure your site as an allowed web origin. Adding this in the Authentication section of the WorkOS dashboard will prevent CORS issues when using the widget.

Screenshot of the CORS dialog box in the WorkOS dashboard

You also need to set the WorkOS API key and client ID in order to make calls to the WorkOS API. Copy these values from the WorkOS dashboard.

Screenshot of WorkOS dashboard overview page

Store the values as managed secrets and pass them to the SDK as environment variables:

Environment variables example:

	
WORKOS_API_KEY='sk_example_123456789'
WORKOS_CLIENT_ID='client_123456789'
	

!!For more information on safely handling secrets, see Best practices for secrets management.!!

2c. Get authorization token

The Pipes Widget makes a call to the WorkOS API to retrieve information about all the 3rd party services the user has the option to enable and their corresponding status, so it needs an authorization token. There are two ways you can get one:

	
import { useAuth } from '@workos-inc/authkit-react';
import { Pipes, WorkOsWidgets } from '@workos-inc/widgets';

export function PipesPage() {
 //Get an authorization token
 const { isLoading, user, getAccessToken } = useAuth();
 if (isLoading) {
   return '...';
 }
 if (!user) {
   return 'Logged in user is required';
 }

 //Render the Pipes widget using the token
 return (
   <WorkOsWidgets>
     <Pipes authToken={getAccessToken} />
   </WorkOsWidgets>
 );
}
	
  • If you use one of our backend SDKs, use the “get token” method in the SDK to request a token with the appropriate scope for the widget you want to use. Widget tokens expire after one hour. Node example:
	
import { Pipes, WorkOsWidgets } from '@workos-inc/widgets';
import { WorkOS } from '@workos-inc/node';

const workos = new WorkOS(process.env.WORKOS_API_KEY);

//Get an authorization token
export async function getServerSideProps() {
 const authToken = await workos.widgets.getToken({
   userId: user.id,
   organizationId: organizationId,
 });

 return {
   props: {
     authToken,
   },
 };
}

//Render the Pipes widget using the token
export default function PipesPage({
 authToken,
}: {
 authToken: string;
}) {
 return (
   <WorkOsWidgets>
     <Pipes authToken={authToken} />
   </WorkOsWidgets>
 );
}
	

!!To customize the look and feel of the widget see Styling.!!

Step 3: Get an access token and call GitHub

Once the user connects GitHub, your backend can request a fresh access token from WorkOS. Pipes handles refresh logic so you can treat the token as ready to use.

Create pages/api/repos.js:

	
import { WorkOS } from '@workos-inc/node';
import { Octokit } from '@octokit/rest';

const workos = new WorkOS(process.env.WORKOS_API_KEY);

// For this minimal tutorial we hardcode identity.
// In a real app, read these from the user’s session.
const userId = 'user_demo_123';
const organizationId = 'org_demo_123';

export default async function handler(req, res) {
  try {
    // Call the WorkOS API and get an access token for GitHub
    const { accessToken, error } = await workos.pipes.getAccessToken({
      provider: 'github',
      userId,
      organizationId,
    });

    if (!accessToken) {
      res.status(400).json({
        error:
          error?.message ||
          'GitHub is not connected, or the user needs to reauthorize. Use the Pipes widget to connect GitHub.',
        details: error || null,
      });
      return;
    }

    // Call GitHub and get list of repos for user
    const octokit = new Octokit({ auth: accessToken.token });
    const { data: repos } = await octokit.repos.listForAuthenticatedUser({
      per_page: 50,
      sort: 'updated',
    });

    res.status(200).json({ repos });
  } catch (e) {
    res.status(500).json({ error: e?.message || 'Server error' });
  }
}
	

What this does:

  1. Calls workos.pipes.getAccessToken({ provider: 'github', userId, organizationId })
  2. If the user is not connected or needs reauthorization, it returns an error you can use to direct them back to the widget.
  3. If it succeeds, you get accessToken.token ready for GitHub API calls. This is the “no OAuth in your app” moment:
    • Your app does not implement the OAuth redirect flow.
    • Your app does not store refresh tokens.
    • Your app just asks Pipes for a usable token, then calls GitHub.

Sample workos.pipes.getAccessToken response:

	
{
  "active": true,
  "access_token": {
    "object": "access_token",
    "access_token": "gho_16C7e42F292c6912E7710c838347Ae178B4a",
    "expires_at": "2025-12-31T23:59:59.000Z",
    "scopes": ["repo", "user:email"],
    "missing_scopes": []
  }
}
	

Next steps

You now have a working pattern for bringing external data into your application using Pipes. GitHub is just one example. The same approach can be used to connect other providers and pull in data with minimal changes to your application code.

From here, you might:

  • Add additional providers such as Slack, Google, Salesforce, or other supported services.
  • Reuse the same Pipes widget to let users manage multiple connected accounts in one place.
  • Expand your backend logic to fetch different types of data from connected providers, using the same access token flow.

If you need to integrate with a data source that is not currently listed, reach out to us. Pipes is designed to grow with your product, and we are always open to adding new providers based on customer needs.

As your application evolves, Pipes remains the integration layer, so you can focus on building features instead of maintaining OAuth and credential infrastructure.

Sign up for WorkOS and start working Pipes today.

This site uses cookies to improve your experience. Please accept the use of cookies on this site. You can review our cookie policy here and our privacy policy here. If you choose to refuse, functionality of this site will be limited.