The user migration API (https://appleid.apple.com/auth/usermigrationinfo) is inconsistent when we call it with the correct parameters and tokens to retrieve new user subs/emails for users made under a previous Entity before completing an Entity Transfer: 65% of our requests return with no new sub or email and we receive an {'error': 'invalid_request', 'email_verified': False} response back from the API when sending it our transfer subs. 34% of our requests succeed in getting a sub but no new private relay email from the same API with the same parameters- isn't it always supposed to return an email? 1% of our requests successfully responded with a new sub and private relay email. We know it is not from anything in the request expiring because we regenerate the secrets, access_tokens, and transfer subs before making each request. All the other parameters are exactly the same as the successful API calls. I can respond over email with more app/team-specific details or our request code. Thanks!

We've encountered an issue with implementing "Sign in with Apple." We've set up an authorization mechanism that returns a JWT, which includes the following fields in the IdTokenPayload: iss, aud, exp, iat, sub, at_hash, email, email_verified, auth_time, and nonce_supported. We tested this using an Apple ID that had not previously been used with our app. At this stage, we expected to receive the user's name, but instead, the relevant fields are returning null values, and all we receive is the email address. Here’s an example of the JWT payload we're receiving: { "iss": "https://appleid.apple.com", "aud": "com.octocrm.webapp", "exp": 1724833875, "iat": 1724747475, "sub": "000335.ad7cef1b0a3c474b842531f95444f2ad.1205", "at_hash": "perz_dvgtpe4cglpuzzj-a", "email": "firma.pl", "email_verified": true, "auth_time": 1724747463, "nonce_supported": true } We were expecting the user's name fields (e.g., name, given_name, family_name) to be populated in the JWT, but instead, they are returning as null. Is there something we're missing in our implementation, or is there a specific condition that needs to be met for these fields to be included? Any guidance on how to resolve this issue would be greatly appreciated.

Hi, Please see TN3159: Migrating Sign in with Apple users for an app transfer for more information on the expected end-to-end app transfer and user migration flow. Additionally, if you'd like for the iCloud and App Store engineering teams to confirm if the errors are related to a revoked authorization to previous users accounts, please submit a report via Feedback Assistant and include the following information: Gathering required information for troubleshooting Sign in with Apple user migration To prevent sending sensitive JSON Web Tokens (JWTs) in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. For issues occurring with your user migration, ensure your feedback contains the following information: the primary App ID and Services ID the client secret for the transferring team (Team A) and the recipient team (Team B) the failing request(s), including all parameter values, and error responses (if applicable) the timestamp of when the issue was reproduced (optional) screenshots or videos of errors and unexpected behaviors (optional) Important: If providing a web service request, please ensure the client secret (JWT) has an extended expiration time (exp) of at least ten (10) business days, so I have enough time to diagnose the issue. Additionally, if your request requires access token or refresh tokens, please provide refresh tokens as they do not have a time-based expiration time; most access tokens have a maximum lifetime of one (1) hour, and will expire before I have a chance to look at the issue. Submitting your feedback Before you submit via Feedback Assistant, please confirm the requested information above (for your native app or web service) is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

now there is a way for apple id to get into the code without a password

Recently our Sign In with Apple integration has been affected by an inconsistency in Apple token response, where the email_verified attributed has a false value in the response but inside the id_token payload the email_verifiedattribute is set to true (the correct value), our integration has been working as expected until recently and haven't found an official announcement on this change. When making a call to https://appleid.apple.com/auth/token to exchange a code for a token using curl -v POST "https://appleid.apple.com/auth/token" \ -H 'content-type: application/x-www-form-urlencoded' \ -d 'client_id=CLIENT_ID' \ -d 'client_secret=CLIENT_SECRET' \ -d 'code=CODE' \ -d 'grant_type=authorization_code' \ -d 'redirect_uri=REDIRECT_URI' We're getting the following response where email_verified is set to false { "access_token": "XXXXXXX", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "XXXXXXX", "id_token": "XXXXXX", "email_verified": false } But by inspecting the id_token payload the email_verified attribute has the correct value: true { "iss": "https://appleid.apple.com", "aud": "xxxxx", "exp": 1724433090, "iat": 1724346690, "sub": "xxxxxxxxx", "at_hash": "xxxxxxxxxxx", "email": "my-apple-id@gmail.com", "email_verified": true, "auth_time": 1724346672, "nonce_supported": true } I'd like to know the reason for this inconsistency, or if it is an issue and is under the Apple team's radar.

When developing an app that requires to sign up or login, I heard somewhere that I won't get an approval for the app if I don't implement the ability to login with apple account. Is that correct?

Hi, In our application, apple users have option to hide their email and continue with proxy email that apple provides to use our application feature. But we noticed that apple account created with gmail is having an issue where the email that we send from our apps is going to spam folder in gmail. All the other email domains used is working fine. Is anyone facing/faced this issue, please suggest a possible solution Thanks JM

After an app transfer, I'm reached this point in this article, and I need to check if the Sign In with Apple ID users I've migrated have the "transferred" status. This articles provides you with Swift code to check this status; does anyone know if there's a way to access this info using the Apple ID REST API, preferably with a curl command? Or do I specifically need to check this info on my app? Here's the swift code I'm talking about: let request = ASAuthorizationAppleIDProvider().createRequest() // Specify the current user identifier here. request.user = "User Identifier" let controller = ASAuthorizationController(authorizationRequests: [request]) controller.delegate = self controller.presentationContextProvider = self controller.performRequests()

Hello, I have a JS website that uses "Sign in with Apple" with AppleID.auth.signIn : It redirects to appleid.apple.com It redirects to my backend with a form POST Then I redirect the user to my frontend I bundled my website as a webview in an app for iOS. When using the functionality on iOS : A faceId popup appears over my app The user is redirected to appleid.apple.com A second faceId popup appears It redirects to my backend with a form POST it gets redirected to my frontend in an embeded Safari. When closing the embeded browser, the user is not connected on my app I would like my user to be redirected to my app instead of staying in the embeded browser. I would like to eliminate the double faceId popups The functionality works in the web (Safari desktop and mobile), as a PWA, and on Android. So I think I have properly configured the Domains and Redirect URLs in my Sign in with Apple service. When I click on a link that points to my website from Safari, it opens my iOS app. So I think I have properly configured the associated domains. When testing the functionality from an iPhone emulator in XCode, it works (but uses a simple appleId/password form instead of faceId) I could not find an answer on the forums that solved my problem. I can provide code and screen captures. Thank you

We're preparing to migrate our Apple Sign-In users for an upcoming app transfer. Following this guide, we're currently stuck on the first curl command: curl -v POST "https://appleid.apple.com/auth/token" \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'grant_type=client_credentials' \ -d 'scope=user.migration' \ -d 'client_id=CLIENT_ID' \ -d 'client_secret=CLIENT_SECRET_ISSUED_BY_TEAM_A' Specifically, we're having issues generating the client secret, specified here. We're using a Node.js script to generate the script; initially I realized that the private key I was signing the JWT with was wrong (I was using the App Store Connect API team key instead of a private key for use with Account & Organization Data Sharing). Every time we try entering this curl command: curl -v POST "https://appleid.apple.com/auth/token" \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'grant_type=client_credentials' \ -d 'scope=user.migration' \ -d 'client_id=com.jumbofungames.platMaker' \ -d 'client_secret=$(node clientsecret_jwt2.js)' Where $(node clientsecret_jwt2.js) is the command to generate the client secret; we get this error: < HTTP/1.1 400 Bad Request < Server: Apple < Date: Mon, 19 Aug 2024 15:41:31 GMT < Content-Type: application/json;charset=UTF-8 < Content-Length: 49 < Connection: keep-alive < Pragma: no-cache < Cache-Control: no-store < * Connection #1 to host appleid.apple.com left intact {"error":"invalid_client","email_verified":false}% Here is the script we are using to generate the Client Secret (JWT), with some variables using placeholders for privacy: const fs = require('fs'); const jwt = require('jsonwebtoken'); // npm i jsonwebtoken // You get privateKey, keyId, and teamId from your Apple Developer account const privateKey = fs.readFileSync("./AuthKey_ABCDEFG123.p8") // ENTER THE PATH TO THE TEAM KEY HERE (private key file) const keyId = "API_KEY"; // ENTER YOUR API KEY ID HERE const teamId = "TEAM_ID"; // ENTER YOUR TEAM ID HERE const clientId = "com.companyname.appname"; // ENTER YOUR APP ID OR SERVICES ID HERE (This is the client_id) // Time settings (in seconds) let now = Math.round((new Date()).getTime() / 1000); // Current time (seconds since epoch) let nowPlus6Months = now + 15776999; // 6 months from now (maximum expiration time) let payload = { "iss": teamId, // The Team ID associated with your developer account "iat": now, // Issued at time "exp": nowPlus6Months, // Expiration time (up to 6 months) "aud": "https://appleid.apple.com", // Audience "sub": clientId // The App ID or Services ID } let signOptions = { "algorithm": "ES256", // Algorithm for signing (ECDSA with P-256 curve and SHA-256 hash algorithm) header : { "alg": "ES256", // Algorithm in the header "kid": keyId, // Key ID in the header "typ": "JWT" // JWT type } }; // Generate the JWT (client_secret) let clientSecret = jwt.sign(payload, privateKey, signOptions); console.log(clientSecret); module.exports = clientSecret; If anyone has run into similar issues using this API or could shed some light on what could be going wrong, please let us know — we're at a bit of a loss here.

Hello, I’m transferring an app from my individual account to my corporate developer account. I’m the primary owner of both accounts. I’m trying to transfer the users that used Sign In with Apple and this is what I did: I generated the transfer identifier for all the users that used Sign In with Apple from the database (50.000 users → 100% success rate) I’m using the transfer identifier previously generated to create the new Apple ID and private email address of the user. (40% success rate) I successfully generated new Apple ID and private email address for 20.000 users but for the other 30.000 users I cannot generate it because I get { error: 'invalid_request’ } on the migration endpoint (/auth/usermigrationinfo), even though I'm using the same request parameters as the ones that are working. I couldn’t find any difference between users that could be migrated and the users that couldn’t. It doesn’t matter if they are old users or new users. What I found is that I can generate the new Apple ID and private email address if the user signs in with Apple for the first time after the app transfer. Then I can use the “transfer_sub” that I have stored for the user to generate the new user details. The same process worked fine for another app that I transferred. Something seems to be broken only for this app on 60% of the users that used Sign In with Apple. Please let me know if you need further information Best, Cosmin

Dear Apple: Due to the change of company information, we need to migrate the online App from the developer account to the developer account of the new company. We have two apps to transfer，bundle id：com.dhgate.DHgateBuyer，com.dhgate.DHgateSeller，old teamId: 6PG7H3L6MA，new teamId: Y2GSG84XX2 According to the Apple login transfer process, we have obtained the user's exchange identifier according to the provided API (https://developer.apple.com/documentation/sign_in_with_apple/transferring_your_apps_and_users_to_another_team/)，and the new team accepted the App transfer（com.dhgate.DHgateSeller）. However, in the process of using the exchange identifier to exchange for the new team identifier according to the API（https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team）, it is found that 40% of users (about 2 million) can succeed, and 60% of users (about 2 million) will report an error（{"error":"invalid_request"}）. Please help to explain the cause or influencing factors of this problem and how to solve it. Thank you.

My company wants to build two apps for two separate product lines, but we want our users to be able to sign in to both apps with the same credentials, and we want Sign In with Apple to be an option. Is it possible to associate the apps with one another in a way that Sign In with Apple will produce the same token for the same Apple ID in both apps?

We have transferred our app from one Apple Developer account to our parent Apple Developer account. We're having trouble exchanging identifiers for the majority of users, and are looking for alternate ways to match the SIWA user with the user in our database once they log in again I know that the SIWA user's 'sub' will change, but what about the privaterelay.appleid.com email? Does that stay the same after app migration?

Hi all, We've been given the opportunity to beta test an app at my school and we have been asked to download the Test Flight app to enable it to run. Unfortunately it's not possible to use Test Flight with a managed Apple ID. All our staff and pupils' iPads are signed in with a managed Apple ID. It's a shame to pass up this opportunity, but I can't see any way around it... does anyone have any alternatives (apart from creating and using a non-managed Apple ID, which isn't feasible). Thanks in advance, Jacob

We recently did an app transfer of our app from one account to a parent company's account. Because we have Sign In With Apple, we need to transfer the users. We're following this doc: https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team We have about 118,000 users, and were successful in generating the transfer identifier for the majority. We assume some users have revoked access. When we try to call to exchange identifiers, we are successful for about 50k users, but for the remaining 68k users we are receiving 'invalid_request' with no other information I don't understand why we would have a transfer identifier, and then receive 'invalid_request.' If it was a configuration problem I would expect that error for all users, or invalid_client. I've already gone through this doc: https://developer.apple.com/documentation/technotes/tn3107-resolving-sign-in-with-apple-response-errors We've tried using a Node.js script, bash, Postman, with the same result. If an API call to exchange identifiers has an error, that user has an error every time. If a call is successful, it's successful every time. Other forum posts are dead ends with no resolution. Has anybody seen this behavior and found a fix for it?

Hi everyone, I've been working on integrating Apple Sign-In with my web app and have hit a roadblock that I can't seem to resolve. I've successfully set up an Nginx reverse-proxy for development purposes enabling SSL/TLS to provide HTTPS. I have configured everything using the values from the Apple Developer Console, including identifiers, keys, and IDs. The sign-in flow works perfectly when I use my Apple ID (which is linked to my developer account). The Apple Sign-In REST API returns a JWT with my email, as expected. However, when other users sign in with their Apple IDs, the returned JWT doesn't include their email addresses. I am aware that Apple only provides the email on the first sign-in, but this doesn't seem to be the issue here. Below is the relevant code I'm using (Bun.js, Elysia, Arctic): import Bun from 'bun'; import { Apple, type AppleCredentials, type AppleTokens } from 'arctic'; import type { BaseAuthAccountInfo } from './type'; import { createPrivateKey } from 'crypto'; import { sign, decode } from 'jsonwebtoken'; const { APPLE_CLIENT_ID, APPLE_TEAM_ID, APPLE_KEY_ID, APPLE_CLIENT_SECRET, APPLE_CLIENT_SECRET_JWT, } = Bun.env; type AppleReponseJWTPayload = { iss: string; aud: string; exp: number; iat: number; sub: string; at_hash: string; email: string; email_verified: boolean; auth_time: number; nonce_supported: boolean; }; const credentials: AppleCredentials = { clientId: APPLE_CLIENT_ID!, teamId: APPLE_TEAM_ID!, keyId: APPLE_KEY_ID!, certificate: `-----BEGIN PRIVATE KEY-----\n${APPLE_CLIENT_SECRET}\n-----END PRIVATE KEY-----`, }; const apple = new Apple(credentials, 'https://intellioptima.com/api/v1/aus/auth/apple/callback'); const appleAuthUrl = async (state: string) => { const appleUrl = await apple.createAuthorizationURL(state); appleUrl.searchParams.set('response_mode', 'form_post'); appleUrl.searchParams.set('scope', 'email'); return appleUrl; }; const getAppleTokens = async (code: string) => { console.log('Authorization code:', code); const appleResponse = await apple.validateAuthorizationCode(code); console.log('Apple Response:', appleResponse); return appleResponse; }; const getAppleAccount = async (tokens: AppleTokens): Promise<BaseAuthAccountInfo> => { const token = generateJWTApple(); const response = await fetch('https://appleid.apple.com/auth/token', { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', }, body: new URLSearchParams({ client_id: credentials.clientId, client_secret: token, grant_type: 'refresh_token', refresh_token: tokens.refreshToken!, }).toString(), }); if (!response.ok) { throw new Error('Failed to fetch user info'); } const appleResponse = await response.json(); console.log('APPLE_RESPONSE', appleResponse); const decodedUser = decode(appleResponse.id_token) as AppleReponseJWTPayload; if (!decodedUser || !decodedUser.email) { throw new Error('The user does not have an email address.'); } return { id: decodedUser.sub as string, username: decodedUser.email.split('@')[0], email: decodedUser.email!, name: decodedUser.email.split('@')[0], emailVerified: decodedUser.email_verified ?? false, iconUrl: `https://robohash.org/${decodedUser.email.split('@')[0]}.png`, }; }; function generateJWTApple() { const MINUTE = 60; const HOUR = 60 * MINUTE; const DAY = 24 * HOUR; const MONTH = 30 * DAY; const tokenKey = `-----BEGIN PRIVATE KEY-----\n${APPLE_CLIENT_SECRET_JWT!.replace(/\\n/g, '\n')}\n-----END PRIVATE KEY-----`; const privateKey = createPrivateKey(tokenKey); const now = Math.ceil(Date.now() / 1000); const expires = now + MONTH * 3; const claims = { iss: APPLE_TEAM_ID, iat: now, exp: expires, aud: 'https://appleid.apple.com', sub: 'com.intellioptima.aichat', }; return sign(claims, privateKey, { header: { kid: APPLE_KEY_ID, alg: 'ES256', }, }); } export { apple, appleAuthUrl, getAppleAccount, getAppleTokens }; I would greatly appreciate any insights or suggestions on what might be going wrong. I'm at a loss, and any help would be invaluable! Thanks in advance! <3333

Please someone help me.... I have been struggling for quite a while now configuring everything for the flow of using Apple SSI for my web app. I have finally managed to configure a nginx reverse-proxy for development experience. Creating and working correctly with all the values from Apple Developer Console which involves the identifiers, keys and Id's. My issue is now, that everything works for my signin flow. SO when I sign in using my AppleID which is also connected to the developer account I get signed in and Apple signin RESTAPI returns a JWT with my email. But when everyone else signs in with their AppleID's the returned JWT doesn't have the emails. And I know that Apple only gives the email first time user signs in - but that's is not the issue. Here is my code (using bun.js, Elysia, Arctic): import Bun from 'bun'; import { Apple, type AppleCredentials, type AppleTokens } from 'arctic'; import type { BaseAuthAccountInfo } from './type'; import { createPrivateKey } from 'crypto'; import { sign, decode } from 'jsonwebtoken'; const { APPLE_CLIENT_ID, APPLE_TEAM_ID, APPLE_KEY_ID, APPLE_CLIENT_SECRET, APPLE_CLIENT_SECRET_JWT, } = Bun.env; type AppleReponseJWTPayload = { iss: string; aud: string; exp: number; iat: number; sub: string; at_hash: string; email: string; email_verified: boolean; auth_time: number; nonce_supported: boolean; }; const credentials: AppleCredentials = { clientId: APPLE_CLIENT_ID!, teamId: APPLE_TEAM_ID!, keyId: APPLE_KEY_ID!, certificate: -----BEGIN PRIVATE KEY-----\n${APPLE_CLIENT_SECRET}\n-----END PRIVATE KEY-----, }; const apple = new Apple(credentials, 'https://intellioptima.com/api/v1/aus/auth/apple/callback'); const appleAuthUrl = async (state: string) => { const appleUrl = await apple.createAuthorizationURL(state); appleUrl.searchParams.set('response_mode', 'form_post'); appleUrl.searchParams.set('scope', 'email'); return appleUrl; }; const getAppleTokens = async (code: string) => { console.log('Authorization code:', code); const appleResponse = await apple.validateAuthorizationCode(code); console.log('Apple Response:', appleResponse); return appleResponse; }; const getAppleAccount = async (tokens: AppleTokens): Promise => { const token = generateJWTApple(); const response = await fetch('https://appleid.apple.com/auth/token', { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', }, body: new URLSearchParams({ client_id: credentials.clientId, client_secret: token, grant_type: 'refresh_token', refresh_token: tokens.refreshToken!, }).toString(), }); if (!response.ok) { throw new Error('Failed to fetch user info'); } const appleResponse = await response.json(); console.log('APPLE_RESPONSE', appleResponse); const decodedUser = decode(appleResponse.id_token) as AppleReponseJWTPayload; if (!decodedUser || !decodedUser.email) { throw new Error('The user does not have an email address.'); } return { id: decodedUser.sub as string, username: decodedUser.email.split('@')[0], email: decodedUser.email!, name: decodedUser.email.split('@')[0], emailVerified: decodedUser.email_verified ?? false, iconUrl: `https://robohash.org/${decodedUser.email.split('@')[0]}.png`, }; }; function generateJWTApple() { const MINUTE = 60; const HOUR = 60 * MINUTE; const DAY = 24 * HOUR; const MONTH = 30 * DAY; const tokenKey = `-----BEGIN PRIVATE KEY-----\n${APPLE_CLIENT_SECRET_JWT!.replace(/\\n/g, '\n')}\n-----END PRIVATE KEY-----`; const privateKey = createPrivateKey(tokenKey); const now = Math.ceil(Date.now() / 1000); const expires = now + MONTH * 3; const claims = { iss: APPLE_TEAM_ID, iat: now, exp: expires, aud: 'https://appleid.apple.com', sub: 'com.intellioptima.aichat', }; return sign(claims, privateKey, { header: { kid: APPLE_KEY_ID, alg: 'ES256', }, }); } export { apple, appleAuthUrl, getAppleAccount, getAppleTokens }; What could be the issue??? I really hope someone out there can provide me with some details on what is going on <33333

Recently, we received a transfer of ownership for an application. While the transfer has been completed, we are encountering issues when we tried exchange the transfer identifiers for team-scoped identifiers and private email addresses. Specifically, we are only able to successfully exchange a portion of the user identifier. Following the official documentation, we performed the following steps: Obtained the interface token: Request parameters: client_id client_secret grant_type=client_credentials scope=user.migration Response: {"access_token":"xxxx","token_type":"Bearer","expires_in":3600} Generate the transfer identifier （https://developer.apple.com/documentation/sign_in_with_apple/transferring_your_apps_and_users_to_another_team） Request parameters: sub=xxxx&target=New Team ID&client_id&client_secret Response: {"transfer_sub":"xxxx"} Re-obtained the interface token: Request parameters: client_id client_secret grant_type=client_credentials scope=user.migration Response: {"access_token":"xxxx","token_type":"Bearer","expires_in":3600} Exchange identifiers： （https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team） Request parameters: transfer_sub=xxxx&client_id&client_secret Response: code:400, content:{"error":"invalid_request"} Could you please help us identify the issue?

I'm unable to request the full name in my SignInWithAppleButton. However, I can correctly gather the apple id and use the email in the requested scope. I have a testing and production project which have the same exact code block for reproducing the sign in button experience within an iOS app. In the testing project, I'm able to gather the full name and email (just as intended) with the same "Sign in with Apple" Capability and signing + signing certificate. Which leads me to think there's some conflict in entitlements or target properties which conflict with ability to gather the full name in the "SignInWithAppleButton" Any help with this would be greatly appreciated before I have to run through each entitlement/property and play with how it affects the SSO capability. Thank you in advance! Code block: import SwiftUI import AuthenticationServices struct ContentView: View { var body: some View { VStack { SignInWithAppleButton(.continue, onRequest: {request in request.requestedScopes = [.fullName, .email] }, onCompletion: {result in switch result { case .success(let auth): guard let cred = auth as? ASAuthorizationAppleIDCredential else {return} print(cred.authorizedScopes) case .failure(let err): print(err) } }) } .padding() } }