Skip to Content
TutorialsIntegration PlaybooksMy Apps

My Apps

Add single sign-on to your app, backed by My Apps.

What is My Apps?

My Apps is an OIDC identity provider — a separate app in your workspace, not a Microsoft product. It issues standard OAuth2/OIDC tokens (authorization code + PKCE), so your generated app can add “Sign in with My Apps” without you writing any IDP-specific code — the same add-external-oauth skill your coding assistant already uses for Azure AD, Google, Okta, and Auth0 handles My Apps too.

Perfect for:

  • Adding SSO login without registering an OAuth client by hand
  • Keeping every generated app’s login on one shared identity provider
  • Skipping the manual “copy client_id, paste client_secret” round trip most OIDC providers require
  • Multi-provider login pages that offer My Apps alongside Azure/Google/Okta

Do not confuse this with Microsoft’s “My Apps” portal (myapplications.microsoft.com), part of Entra ID/Azure AD app assignment. They share a name but are unrelated products — if you want this My Apps, say so explicitly, or just connect it here first and let your assistant find it automatically (see Step 2).

What You’ll Need

My Apps, connected

Auto-provisioned automatically, or bring your own Client ID/Secret — see Step 1.

Nothing else

Auto-provision registers everything My Apps needs in one call.

Step 1: Connect My Apps

Connect the project

  1. Open your project → Connectors in the sidebar (or check the My Apps card during project creation).
  2. Click Connect.
  3. Choose a mode:
    • Auto-provision (default) — Buildpad registers an OIDC client with My Apps on your behalf, named {your org name} - {your project name}, with both your deployed app’s callback URL and http://localhost:3000/api/auth/callback (for local dev) already registered as redirect URIs. The card shows Auto-configuring while this is in flight, then Connected.
    • Bring your own credentials — paste an existing My Apps Client ID and Client Secret. Use this if you already registered a client yourself through the My Apps admin UI.
  4. Click Connect.

Auto-provisioning stores seven values for your project: OAUTH_CLIENT_ID, OAUTH_CLIENT_SECRET, and five fixed OIDC endpoint URLs (OAUTH_AUTHORIZATION_URL, OAUTH_TOKEN_URL, OAUTH_USERINFO_URL, OAUTH_JWKS_URI, OAUTH_ISSUER) — all pointed at the My Apps instance for this environment. These are exactly the env var names the add-external-oauth skill’s “Generic / Custom OIDC Provider” config expects, so no mapping step is needed.

If you’re bringing your own credentials

  1. Open the My Apps admin UI (the Platform link on the connector card).
  2. Register a new IDP client, giving it your app’s redirect URI(s) — the deployed callback URL, plus http://localhost:3000/api/auth/callback if you’ll test locally.
  3. Copy the Client ID and Client Secret it gives you, and paste them into the connect form.

Unlike auto-provision, Buildpad can’t register redirect URIs on your behalf here — if you add a custom domain or a non-default local port later, you’ll need to add that redirect URI in the My Apps admin UI yourself.

Step 2: Tell the Agent What You Want

Once My Apps is connected, your coding assistant already knows how to reach it — you don’t need to paste a client ID, secret, or any URLs into a prompt.

Example 1: Basic SSO login

Create an SSO feature that uses the IDP from My Apps.

Example 2: Multi-provider login page

Add a login page with two options: "Sign in with My Apps" and 
"Sign in with Google". Let me pick which providers show based on 
a `providers` prop, like the existing OAuthLoginButtons component 
supports.

Example 3: Redirect after login

After signing in with My Apps, redirect the user to /dashboard 
instead of the homepage. If they were trying to reach a specific 
page before being sent to log in, return them there instead.

Under the hood: the add-external-oauth skill’s Step 0 looks for a connected connector whose env vars include OAUTH_CLIENT_ID before doing anything else. If it finds one, it uses those values directly; only if none exists does it fall back to asking you to register a client and paste credentials by hand.

Step 3: Test the Connection

Start the app

Run pnpm dev and open the login page.

Confirm the button appears

A “Sign in with My Apps” (or similarly labeled) button should render.

Click through the flow

You should be redirected to My Apps, prompted to authenticate, then redirected back and logged in.

Check for a session

After redirecting back, you should be an authenticated Supabase user — no login loop back to the sign-in page.

Check the user can actually use the app

Test with a brand-new My Apps account, not one that already has a role. First-time SSO users are created on the fly (JIT provisioning), and they must also be assigned your app’s default role during that first login — a user with no role is denied everything by the permissions system, so login effectively fails even though My Apps authenticated them. See Logged In, but Everything Is Denied if this happens.

Repeat after deploying

Env vars connected here don’t automatically reach your deployed app — ask your assistant to push them (see Something Not Working?) and re-test on the live URL.

Common Questions

Do I need to register a redirect URI myself?

No, not with auto-provision — both your deployed app’s callback URL and http://localhost:3000/api/auth/callback are registered automatically when the connector is provisioned. You only need to do this yourself with “Bring your own credentials.”

What if my local dev server doesn’t run on port 3000?

The auto-provisioned redirect URI assumes the Next.js default (localhost:3000, no port override). If your generated app runs on a different port, register that redirect URI with My Apps yourself, or switch back to the default port for local testing.

Can I tell my assistant “use My Apps” without it defaulting to Azure AD?

Yes — as long as My Apps is connected on the Connectors page first, your assistant checks there before considering any other provider, regardless of how you phrase the request.

Can I offer My Apps alongside another provider, not instead of it?

Yes — OAuthLoginButtons renders one button per configured provider, so connecting My Apps doesn’t replace an existing Azure AD/Google/Okta/Auth0 setup. See Example 2 above.

Something Not Working?

Can’t Connect

Tell the agent:

Getting an error calling My Apps.

Can you check:
1. OAUTH_CLIENT_ID and OAUTH_CLIENT_SECRET are set in .env.local
2. The connector shows "Connected" on the project's Connectors page
3. Whether I need to restart `pnpm dev` after adding the env vars

Redirects to My Apps, Then Fails

Tell the agent:

I get redirected to My Apps and can log in, but the callback fails
(or I end up back on the login page).

Can you check:
1. Whether the redirect URI My Apps has registered actually matches
   this app's callback route
2. Whether the session is being set with supabase.auth.setSession(),
   not manual cookie setting

Logged In, but Everything Is Denied

New SSO users authenticate fine but see no data, get permission errors, or bounce straight back to the login page.

Tell the agent:

SSO login with My Apps succeeds, but a newly provisioned user can't
access anything afterwards.

Can you check:
1. Whether the JIT-provisioned user has a row in daas_user_roles —
   without a role, the permissions system denies every request
2. That OAUTH_DEFAULT_ROLE_ID is set (locally and in Amplify) to a
   valid non-admin role UUID, and that the OAuth callback assigns it
   on first login
3. That the default role has policies granting the collections the
   app needs

Works Locally, Not After Deploying

Tell the agent:

My Apps login works with `pnpm dev` but not on the deployed app.

Can you check whether OAUTH_CLIENT_ID, OAUTH_CLIENT_SECRET, and the
OAUTH_* endpoint URLs are set in the Amplify environment, and redeploy
if you add or change any of them?

Assistant Suggests Azure AD Instead of My Apps

Tell the agent:

I asked for SSO via My Apps but you configured Azure AD/Entra ID 
instead.

Can you check the Connectors page for a connected connector whose 
env vars include OAUTH_CLIENT_ID, and use that instead of assuming 
which provider I meant?

Real Examples

Example: Internal admin tool, My Apps only

This is an internal tool — restrict login to My Apps only, no 
email/password fallback. Hide any other sign-in options on the 
login page.

Example: Role-based redirect after login

After signing in with My Apps, check the user's role and send 
admins to /admin and everyone else to /dashboard.

Advanced Features

Once the basics work:

Forcing re-authentication

I want a "Switch account" link that forces My Apps to show the 
login prompt again, even if the user has an active My Apps session.

This uses the OAUTH_AUTH_PARAMS env var (a JSON object of extra authorization params, e.g. {"prompt":"login"}) that add-external-oauth already supports for any OIDC provider, including My Apps.

Custom redirect target after login

Store a "returnTo" URL before sending the user to My Apps, so they 
land back on the exact page they started from instead of the 
homepage.

Quick Checklist

Before going live:

  • Connector shows Connected on the Connectors page
  • Login button renders and redirects to My Apps
  • Feature works with pnpm dev locally
  • Env vars pushed to the Amplify deployment and redeployed
  • New SSO users get the app’s default role automatically (OAUTH_DEFAULT_ROLE_ID set locally and in Amplify)
  • Tested the full login flow on the live URL with a brand-new My Apps account — and confirmed that user can actually reach the app’s pages, not just get a session
  • Checked what happens if the user cancels or denies at the My Apps login screen
ConnectorsChocolate Factory Integration

Remember

Auto-provision skips the manual round trip — no registering a client by hand, no copying a client_id/secret back and forth.

“My Apps” refers to this IDP, not Microsoft’s portal — connect it on the Connectors page and your assistant will find it without needing that spelled out every time.

Local dev is handled too — http://localhost:3000/api/auth/callback is registered alongside your deployed URL automatically.

Deploying is a separate step — connecting My Apps doesn’t push env vars to your live app automatically.

SSO alone doesn’t grant permissions — first-time users are provisioned on the fly, and they need your app’s default role assigned during that first login or the permissions system denies them everything.

Stuck? Tell your coding assistant: “I need help with the My Apps integration” and describe the issue.

Last updated on
Get FeedbackFAQ