How to add Sign in with Apple to your app using WorkOS

If your users are on Apple devices they already have an Apple ID. They use it for iCloud, the App Store, and dozens of apps. Asking them to create yet another account to use your web app is friction you don't need to introduce.

Sign in with Apple is Apple's official OAuth/OIDC identity provider, and it comes with a few unique properties that set it apart from other social logins: Apple lets users hide their real email address behind a private relay, and it requires an App ID and a Service ID in addition to the typical OAuth credentials. That makes setup slightly more involved than, say, GitHub OAuth, but this guide will walk you through every step.

WorkOS handles all the OAuth plumbing on your behalf. Once you've wired up your Apple credentials in the WorkOS Dashboard, AuthKit will automatically surface a "Sign in with Apple" button on your hosted login page, with no custom UI required.

In this guide, we'll cover:

1. Getting the Redirect URI and Outbound Email Domains from WorkOS.
2. Creating an App ID, Service ID, and private key in the Apple Developer Portal.
3. Configuring Apple credentials in the WorkOS Dashboard.
4. Setting up Private Email Relay so emails reach users who hide their address.
5. Setting up AuthKit in a Next.js app.

!!Want to skip the manual setup? The CLI Installer detects your framework, installs the SDK, configures your dashboard, and writes the integration code, all with a single command. Check it out.!!

We're using Next.js here because it's the most common framework for AuthKit integrations, and the @workos-inc/authkit-nextjs SDK makes everything clean and straightforward. If you're on a different framework, the Apple and WorkOS Dashboard steps are identical, only the SDK integration differs. Check the WorkOS docs for samples in your language of choice.

Let's get started.

Prerequisites

Before we begin, you'll need:

• An Apple Developer account (paid membership at developer.apple.com). This is needed for production setup. You can skip this for now if you just want to test using WorkOS's default credentials.
• A WorkOS account (free for up to 1 million users at workos.com).
• A Next.js app (or create one with npx create-next-app@latest).

Step 0: Test with WorkOS default credentials (optional)

Before going through the full Apple Developer setup, you can test the Sign in with Apple flow right away using WorkOS's built-in default credentials.

WorkOS provides a default set of Apple credentials that are automatically used in the Staging environment until you add your own. To enable them:

1. Go to the WorkOS Dashboard > Authentication > OAuth Providers.
2. Locate the Sign in with Apple section and click Enable.

That's it. Sign in with Apple will be active in your Staging environment immediately. You can now jump ahead to Step 8: Set up AuthKit in your Next.js app and get the full flow working before touching a single Apple Developer page.

A couple of things to keep in mind while using default credentials:

• They are only available in the Staging environment. You'll need your own Apple credentials before going to production.
• The Apple consent screen will display WorkOS's name and logo, not yours. Once you register your own application and configure its credentials, you'll be able to customize this.

When you're ready to move to production (or just want to set things up properly from the start), continue with Step 1 below.

Step 1: Get the Redirect URI and Outbound Email Domains from WorkOS

Before touching the Apple Developer Portal, you need two pieces of information from WorkOS: the Redirect URI and the Outbound Email Domains. The Redirect URI is the endpoint Apple will call after a successful login and must be registered in your Apple Developer account. The Outbound Email Domains are used later when setting up Private Email Relay.

1. Go to the WorkOS Dashboard > Authentication > OAuth Providers.
2. Locate the Sign in with Apple section and click Enable.
3. The configuration dialog will open. Copy the Redirect URI and note the Outbound Email Domains; you'll need both later.

Keep this tab open. You'll return to it in Step 6.

Step 2: Retrieve your Apple Team ID

Sign in to the Certificates, Identifiers & Profiles section of your Apple Developer account.

The landing page displays your name, company name, and Team ID in the upper right corner. Note this value; you'll paste it into WorkOS later.

!!The Team ID is a server-side secret. It's used by WorkOS to communicate securely with Apple and should never be exposed to the client.!!

Step 3: Register an App ID

!!Skip this step if you already have an App ID for your application.!!

An App ID is the parent identifier that links your app's capabilities together. You need one to enable Sign in with Apple.

1. Click Identifiers in the sidebar, then click the + button.
2. Select App IDs and click Continue.
3. Select App and click Continue.
4. Fill in a Description and a Bundle ID. The bundle ID should be unique and in reverse domain notation, e.g., com.example.myapp.
5. In the Capabilities section, check the Sign in with Apple box. There's no need to configure anything inside the Edit modal.
6. Click Continue, review your selections, and click Register.

Step 4: Register a Service ID

The Service ID is what Apple uses to identify your web-based Sign in with Apple flow (as opposed to a native iOS app flow). This is where you'll register the WorkOS Redirect URI.

1. Click Identifiers in the sidebar, then click the + button.
2. Select Services IDs and click Continue.
3. Enter a Description and a Service ID. The Service ID should be unique and in reverse domain notation, e.g., com.example.myapp. Note this value; you'll need it when configuring WorkOS.
4. Click Continue, then click Register.

Now configure your new Service ID for Sign in with Apple:

1. Find the newly created Service ID in the list and click on it.
2. Check the Sign in with Apple box and click Configure.
3. Ensure the App ID you created in Step 2 is selected in the dropdown.
4. In the Domains and Subdomains field, enter api.workos.com.
5. In the Return URLs field, paste the Redirect URI you copied from the WorkOS Dashboard in Step 0b.
6. Click Done, then Continue, then Save.

Step 5: Register a private key

Apple uses a private key (rather than a client secret) to sign authentication requests from your server to theirs. You need to generate one and download it; Apple only lets you download it once.

1. Click Keys in the sidebar, then click the + button.
2. Enter a human-readable Key Name (e.g., "Sign in with Apple Key").
3. Check the Sign in with Apple box and click Configure.
4. In the Configure dialog, select the App ID you created in Step 2 and click Save.
5. Click Continue, review your changes, and click Register.
6. On the confirmation page, note the Key ID and click Download to save the .p8 private key file.

!!Important: Download the private key now. Apple will not let you download it again after leaving this page. If you lose it, you'll need to revoke it and generate a new one.!!

Step 6: Configure Apple credentials in WorkOS

You now have everything WorkOS needs:

• Apple Team ID (from Step 1)
• Apple Service ID (from Step 3)
• Private Key ID and the downloaded .p8 key file (from Step 5)

Return to the WorkOS Dashboard and open the Sign in with Apple configuration dialog (the one you opened in Step 1).

1. Toggle Enable on.
2. Select Your app's credentials.
3. Paste your Team ID, Service ID, and Private Key ID into their respective fields, and upload or paste the contents of your downloaded .p8 private key file.
4. Click Save changes.

At this point, AuthKit's hosted UI will automatically show a "Sign in with Apple" button on your login page; no additional code required.

Step 7: Set up Private Email Relay

Sign in with Apple lets users hide their real email address from your app. When a user chooses this option, Apple generates a private relay address that forwards email to their inbox. If you want those users to receive emails from your app (password resets, notifications, etc.), you need to register your sending domains with Apple's Private Email Relay service.

1. In the Sign in with Apple configuration dialog in the WorkOS Dashboard, copy the Outbound Email Domains; these are the domains WorkOS uses to send email on your behalf.
2. In the Apple Developer Portal, click Services in the sidebar.
3. Under Sign in with Apple for Email Communication, click Configure.
4. Click the + button next to Email Sources.
5. Paste the outbound email domains from WorkOS into the Domains and Subdomains field.
6. Click Next, then Register.

Your domains will appear with green checkmarks when successfully registered.

!!If you skip this step, users who opt to hide their email will still be able to sign in, but any emails you send to their Apple relay address won't be delivered.!!

Step 8: Set up AuthKit in your Next.js app

With Apple and WorkOS fully configured, all that's left is to wire up the authentication flow in your app.

The easiest way is to run the CLI Installer. It detects your framework, installs the SDK, configures your dashboard, and writes the integration code, all with a single command:

  
npx workos@latest
  

If you prefer to do it manually, keep reading.

1. Install the SDK

Open your terminal in the root of your Lovable project and install the AuthKit Next.js SDK:

  
npm install @workos-inc/authkit-nextjs
  

2. Configure your app's URLs in the WorkOS dashboard

Before writing any code, you need to configure two things in the WorkOS dashboard.

1. Set a redirect URI → this is the callback endpoint WorkOS will redirect to after a user authenticates. Go to the Redirects section of the Dashboard and add: http://localhost:3000/callback
2. Set a sign-in endpoint → this tells AuthKit where to send users if they land on the hosted sign-in page directly (e.g. from a bookmarked link or a password reset email). In the same Redirects section, set your sign-in endpoint to: http://localhost:3000/login

You'll update both of these to your production domain before deploying.

3. Set your environment variables

Grab your API key and client ID from the WorkOS dashboard.

Then create a .env.local file in the root of your project:

  
WORKOS_API_KEY='sk_example_123456789'
WORKOS_CLIENT_ID='client_123456789'
WORKOS_COOKIE_PASSWORD="your-secure-32-character-password-here"
NEXT_PUBLIC_WORKOS_REDIRECT_URI="http://localhost:3000/callback"
  

WORKOS_COOKIE_PASSWORD is used to encrypt cookies and must be at least 32 characters long. You can generate a secure password by using the 1Password generator or the openssl library via the command line:

  
openssl rand -base64 32
  

Note: NEXT_PUBLIC_WORKOS_REDIRECT_URI uses the NEXT_PUBLIC_ prefix so it's accessible in edge functions and proxy configurations (useful for Vercel preview deployments).

4. Wrap your app layout with AuthKitProvider

AuthKitProvider adds protections for auth edge cases and is required to wrap your app. Open your root layout file (app/layout.tsx) and add it:

  
// app/layout.tsx
import { AuthKitProvider } from '@workos-inc/authkit-nextjs/components';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <AuthKitProvider>
          {children}
        </AuthKitProvider>
      </body>
    </html>
  );
}
  

Your existing Lovable-generated components stay exactly as they are; the provider just wraps around them.

5. Add the middleware

Create a middleware.ts file (or proxy.ts for Next.js 16+) at the root of your project:

  
// middleware.ts
import { authkitMiddleware } from '@workos-inc/authkit-nextjs';

export default authkitMiddleware({
  middlewareAuth: {
    enabled: true,
    unauthenticatedPaths: ['/', '/pricing', '/about'],
  },
});

export const config = { matcher: ['/', '/dashboard/:page*'] };
  

Any route not listed in unauthenticatedPaths will require a signed-in user. Unauthenticated visitors are automatically redirected to the WorkOS-hosted AuthKit login page.

6. Create the login and callback routes

You need two route handlers: one to kick off the sign-in flow, and one to handle the redirect back from WorkOS after a successful login.

  
// app/login/route.ts
import { getSignInUrl } from '@workos-inc/authkit-nextjs';
import { redirect } from 'next/navigation';

export const GET = async () => {
  const signInUrl = await getSignInUrl();
  return redirect(signInUrl);
};
  

  
// app/callback/route.ts
import { handleAuth } from '@workos-inc/authkit-nextjs';

// Redirects to `/` after successful sign in by default
// Customize with: handleAuth({ returnPathname: '/dashboard' })
export const GET = handleAuth();
  

7. Display user info and protect routes

Your home page should handle both authenticated and unauthenticated visitors:

  
// app/page.tsx
import Link from 'next/link';
import { getSignUpUrl, withAuth, signOut } from '@workos-inc/authkit-nextjs';

export default async function HomePage() {
  // Returns the user from the session, or null if not signed in
  const { user } = await withAuth();
  const signUpUrl = await getSignUpUrl();

  if (!user) {
    return (
      <main>
        <h1>Welcome to My App</h1>
        <p>Please sign in to continue.</p>
        <Link href="/login">Sign in</Link>
        {' | '}
        <Link href={signUpUrl}>Sign up</Link>
      </main>
    );
  }

  return (
    <main>
      <h1>Welcome back{user.firstName && `, ${user.firstName}`}</h1>
      <p>Email: {user.email}</p>
      <form
        action={async () => {
          'use server';
          await signOut();
        }}
      >
        <button type="submit">Sign out</button>
      </form>
    </main>
  );
}
  

!!Make sure you've configured a Sign-out redirect in the WorkOS dashboard (same Redirects section). Without it, users will see an error after signing out.!!

For routes where authentication is mandatory, use ensureSignedIn: true:

  
// app/dashboard/page.tsx
import { withAuth } from '@workos-inc/authkit-nextjs';

export default async function Dashboard() {
  const { user } = await withAuth({ ensureSignedIn: true });

  return (
    <div>
      <h1>Dashboard</h1>
      <p>Signed in as {user.email}</p>
    </div>
  );
}
  

8. Test it locally

Start your dev server:

  
npm run dev
  

Visit http://localhost:3000. Click Sign in and you'll be redirected to the AuthKit hosted UI. You should see a "Sign in with Apple" button. Click it, authenticate with your Apple ID, and you'll be redirected back to your app as a signed-in user.

To confirm everything is wired up correctly, open the WorkOS Dashboard > Users. The user who just signed in will appear there.

What you've built

In a handful of steps, you've gone from zero to a working Sign in with Apple integration:

• An Apple Developer configuration with an App ID, Service ID, and private key.
• WorkOS configured to handle the Apple OAuth flow and normalize Apple profiles into a consistent user object.
• Private Email Relay set up so users who hide their email can still receive messages from your app.
• AuthKit's hosted UI automatically showing the Apple sign-in option — no custom button required.
• A Next.js app with encrypted session management, route protection, and user profile access, all handled by the @workos-inc/authkit-nextjs SDK.

Because WorkOS abstracts the OAuth plumbing, you can add more providers (Google, GitHub, Microsoft, and more) with no changes to your application code, plus a whole lot more functionality for free:

• Email + password auth: Automatic password strength enforcement and breach detection.
• Social login (Google, GitHub, Microsoft, and more): Enable additional providers with a single toggle in the dashboard.
• Magic auth: Passwordless sign-in via a one-time code sent to the user's email.
• Multi-Factor Auth (MFA): Additional authentication with TOTP and SMS.
• Passkeys: Biometric, passwordless authentication.
• CLI Authentication: Auth support for command-line tools.
• Email verification: Verify user email addresses with magic codes.
• Organization auth policies: Restrict domains, enforce MFA, and require SSO on a per-organization basis.
• Just-in-time (JIT) provisioning: Automatically provision users on first sign-in based on email domain or SSO.
• Role-Based Access Control (RBAC): Flexible, fine-grained permissions for your users.

Next steps

With auth in place, your app is ready for real users. If you're targeting enterprise customers, WorkOS also gives you:

• Enterprise SSO: When an enterprise customer wants to sign in with Okta, Azure AD, or Google Workspace, WorkOS handles the full SAML/OIDC flow automatically.
• Directory Sync: Automatically provision and deprovision users from Okta, Azure AD, and more.
• Audit Logs: A tamper-proof record of every action in your app.
• Radar: Realtime protection against bots, fraud, and abuse.
• Feature Flags: Manage rollout of new features for specific users and organizations.
• And more.

You can add all of these incrementally as your needs grow; no need to rearchitect anything.

‍Get started with WorkOS today.