Absolutely feasible! Apple Sign In is built to integrate smoothly with existing account systems—whether you’re running email/password auth or token-based authentication. Let’s break down how to handle both response types and link Apple ID credentials to your users’ existing accounts:

It’s key to get these straight before diving into integration:

• usercredentials: This is returned when the user is signing in with Apple ID for the first time on your service, or when their Apple ID hasn’t been linked to any of your existing accounts. It includes a unique userIdentifier (Apple’s permanent, unchanging ID for the user), their email (could be their real email or an Apple-generated private relay address like xxx@privaterelay.appleid.com), and basic profile info.
• passwordcredential: This pops up when the user has previously saved your service’s credentials to their Apple Keychain, or when they’ve already linked their Apple ID to your account. It contains your service’s existing username (usually an email) and password—essentially auto-filling your standard login flow.

Depending on whether the user is already logged into your service or not, here’s how to handle the association:

Scenario 1: User is logged in, wants to add Apple Sign In as an option #

This is the simplest case:

• Let users trigger an Apple Sign In prompt from your account settings page (label it something like "Link Apple ID").
• When you receive the usercredentials response, extract the userIdentifier and email.
• Validate that the logged-in user’s email matches the one from Apple (if it’s a real email; if it’s a private relay, you can ask the user to verify their real email via a code sent to their registered address).
• Store the userIdentifier in your database, linked to the user’s existing account ID.
• From now on, when this user uses Apple Sign In on any device, you’ll recognize the userIdentifier and log them into their linked account directly.

Scenario 2: User is not logged in, uses Apple Sign In to access their existing account #

Here’s how to handle the two possible response types:

Case A: You get usercredentials #

• First, check if the email from Apple matches any existing account in your system.
  • If there’s a match: Prompt the user with, "We found an existing account linked to this email—would you like to link your Apple ID and log in?" Once they confirm, link the userIdentifier to their existing account and start their session (generate your service’s token if using token auth).
  • If no match: Offer two options—create a new account linked to the Apple ID, or prompt them to log into their existing account first then link the Apple ID.

Case B: You get passwordcredential #

• Treat this like a standard email/password login: Pass the provided email and password to your existing auth endpoint.
• If login succeeds, you can optionally prompt the user to link their Apple ID now (to enable faster logins in the future) by triggering the Apple Sign In flow again and storing the userIdentifier.

• Always use userIdentifier as the link key: Apple’s userIdentifier is permanent and won’t change if the user updates their Apple ID email. Never rely on the email alone—private relay addresses are specific to your service, and users can change their real Apple ID email at any time.
• Handle private relay emails: If a user opts for a private email, you can still link it to their account, but consider adding a verification step to confirm they own the real email associated with your existing account.
• Token-based auth integration: When verifying an Apple Sign In login, validate Apple’s ID Token using their public keys (you don’t need to call their API for this—just cache the keys locally). Once validated, generate your service’s standard token (JWT, etc.) for the user, just like you would after a normal login.
• Password credential handling: For passwordcredential responses, reuse your existing email/password login logic—no extra work needed beyond passing the credentials through your auth pipeline.

• Keep it optional: Apple requires that Apple Sign In is only offered as an alternative login method, not a mandatory one. Don’t force users to link their Apple ID to use your service.
• Prioritize security: When linking an Apple ID to an existing account, ensure the user is authenticated first (either via their current session or email verification) to prevent account hijacking.
• Respect user privacy: If a user chooses a private relay email, don’t attempt to resolve it to their real email—this violates Apple’s terms and user trust.

内容的提问来源于stack exchange，提问作者Chris Baxter