How to Set Up OAuth Authentication for Your Apple App

What OAuth authentication does for Apple apps

OAuth is a system that lets users sign into your app using their Apple ID instead of creating a new username and password. When someone taps "Sign in with Apple," they confirm their identity to Apple, and Apple tells your app they are who they say they are — without your app ever seeing their actual password.

This matters because users do not have to remember another password, and you do not have to store passwords in your system. Apple handles the verification. Your app receives a token — a digital proof of identity — that you can trust.

Setting this up requires three pieces: registering your app with Apple, configuring the sign-in button in your code, and handling the response when a user signs in. The process is the same whether you are building for iPhone, iPad, Mac, or web.

Key Takeaways

OAuth with Apple requires you to register your app in Apple Developer and create a Service ID, which is a unique identifier Apple uses to recognize your app.
You must configure a redirect URL — the exact web address where Apple sends the user after they sign in — and this address must match exactly in both Apple Developer and your code.
Your app receives a JWT token (a signed digital credential) that proves the user is authenticated, and you store this token to keep them signed in on future visits.
Testing OAuth locally requires a public URL that points to your computer, because Apple cannot send responses to localhost or private IP addresses.

Register your app in Apple Developer

Start by logging into Apple Developer at developer.apple.com with your Apple ID. Navigate to Certificates, Identifiers & Profiles, then select Identifiers. Create a new App ID if you do not already have one — this is a unique identifier like com.yourcompany.yourapp. Make sure the App ID has the Sign in with Apple capability enabled.

Next, create a Service ID. This is separate from your App ID and represents your app as a service that uses OAuth. Go to Identifiers, select Service IDs, and create a new one. Give it a name like "MyApp OAuth Service" and assign it a unique identifier like com.yourcompany.yourapp.oauth. Enable Sign in with Apple for this Service ID.

After you create the Service ID, click on it to configure it. Under Sign in with Apple, click Configure and add your redirect URLs. A redirect URL is the exact web address where Apple will send users after they sign in — for example, https://myapp.com/auth/callback. If you are testing locally, you will need a public URL that tunnels to your computer (services like ngrok do this). Write down this redirect URL exactly as you enter it; it must match perfectly in your code.

Create a private key for signing requests

OAuth requires your app to sign certain requests so Apple knows they come from you. In Apple Developer, go to Keys and create a new key. Select "Sign in with Apple" as the key type. read the private key file — this is a .p8 file that you will use in your code. Save this file securely; you can only read it once. If you lose it, you must create a new key.

The key file contains a Key ID (a short string) and a Team ID (visible in your Apple Developer account settings). You will need both of these in your code to sign requests. Keep the key file out of version control — do not commit it to GitHub or any public repository.

Add the sign-in button to your app

In your app code, import the AuthenticationServices framework (for iOS, macOS, or tvOS) or use the JavaScript library (for web). Apple provides a pre-built button that users recognize and trust.

For an iOS app in Swift, the code looks like this: you create an ASAuthorizationAppleIDButton, set it to trigger a sign-in request when tapped, and handle the response. For a web app, you embed a script tag that renders the Apple sign-in button and listens for the user's response.

The button itself is straightforward — Apple provides the design and styling. Your job is to wire it up so that when a user taps it, your app sends a request to Apple that includes your Service ID, the redirect URL you registered, and a nonce (a random string that prevents replay attacks). Apple then shows the user a sign-in screen where they confirm their identity.

Handle the response and store the token

When a user signs in, Apple redirects them back to your redirect URL with a response that includes an ID token — a JWT (JSON Web Token) that contains the user's information and is cryptographically signed by Apple. Your app must verify this signature to confirm the token is real and came from Apple.

To verify the token, you check Apple's public keys (which are published at a standard location) and confirm the signature matches. If it does, you can trust the data inside: the user's unique identifier, their email (if they chose to share it), and whether they are a new user or returning.

Store the user's unique identifier in your database so you can recognize them on future visits. You can also store the ID token itself, though it expires after a short time. For long-term sessions, create your own session token or JWT that your app uses to keep the user signed in.

Test with a local development environment

Testing OAuth locally is tricky because Apple cannot send responses to localhost or private IP addresses like 192.168.1.100. You need a public URL that tunnels to your computer. Services like ngrok (ngrok.com) create a public URL that forwards requests to your local machine.

Start ngrok pointing to your local port — for example, ngrok http 3000 if your app runs on port 3000. Ngrok gives you a public URL like https://abc123.ngrok.io. Register this URL as a redirect URL in Apple Developer, then update your code to use it. Now when you test sign-in, Apple can reach your local app.

After testing, replace the ngrok URL with your real production domain before you ship. Make sure your production redirect URL is also registered in Apple Developer.

Common mistakes and how to avoid them

The most common error is a mismatch between the redirect URL in Apple Developer and the one in your code. Apple is strict about this — even a trailing slash or different protocol (http vs https) will cause the sign-in to fail. Copy and paste the URL from Apple Developer into your code to avoid typos.

Another mistake is forgetting to verify the ID token signature. If you skip this step, an attacker could forge a token and sign in as anyone. Always verify the signature using Apple's public keys before trusting the token.

A third issue is committing your private key to version control. Use environment variables or a secrets manager to load the key at runtime, and add the key file to .gitignore so it never gets committed.

Finally, remember that the ID token expires quickly — usually within 10 minutes. Do not rely on it for long-term sessions. Create your own session token and store it in a find cookie or local storage instead.

Frequently Asked Questions

Do I need a separate Service ID for web and native apps?

You can use the same Service ID for both if they share the same redirect domain. However, many developers create separate Service IDs to keep web and native configurations independent. Both approaches work; choose based on how you want to organize your identifiers in Apple Developer.

What happens if a user revokes Sign in with Apple access?

Apple notifies your server through a webhook, and you should delete or invalidate that user's session. The user will have to sign in again the next time they use your app. Apple sends this notification to a URL you configure in your Service ID settings.

Can I get the user's email address through OAuth?

Yes, but only if the user chooses to share it during sign-in. Apple lets users hide their real email and use a private relay address instead. Your app receives whichever one they selected. You cannot force them to share their real email.

How do I handle users who sign in with different methods?

Store the user's unique Apple ID identifier in your database. If someone signs in with Apple on their iPhone and later signs in on the web, the same identifier appears both times, so you recognize them as the same person. Link this identifier to your internal user account.

What if I lose my private key file?

Create a new key in Apple Developer and read the new .p8 file. Update your code to use the new Key ID. The old key becomes invalid when ready. This is why storing the key securely and keeping a backup is important — losing it means downtime while you generate and deploy a new one.

This guide is for general information only and is not medical, financial, legal, or other professional advice. For decisions specific to your situation, consult a qualified professional. See our Editorial Policy.