Hi all, I am in the process of preparing for an app transfer, and have sign-in with apple enabled. I have read the documentation thoroughly and multiple times, yet there are a few things I'd like to have a confirmation about, before taking the leap and risking that some users might experience any issues. If I understand correctly, after the migration if a user performs a sign-in with Apple, they will send an access_token that differs from the one they were sending when the app was assigned to the old team. In case I didn't take any action that means that my system would think this was a new user given the access_token has never been seen before, and therefore it will create a new user. Is that correct? Ok, so if that assumption is correct, I'd like to have a confirmation also of the way I intend to fix this, since we're doing an internal transfer and the database is going to be the same. I would get a TransferID for all users in my database that have used sign-in with Apple (I have already done that for one of my test users, successfully). After that, I will start the transfer, and accept it from the other team. Once that is done, I will call the migrationinfo endpoint from the other team, getting all the new access_tokens related to the transfer ids. With that information, I will update my databse, adding a relation from the new access token from team B that points to the same user as the access token that was given by team A, and I know which one it is because of the TransferID. Does that make sense? Would it work? I'm not a fan of messing with the login logic (having a look at transfer_ids, looking for matches, and so on), especially because there doesn't seem to be a way to test this. I believe the only risk is that a user might login after the app has been transferred but before I can upload the new access token to the database, but we can handle these (few, hopefully even zero cases) via ticketing. These are the resources I have read so far: https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer#Preparing-to-migrate-users-for-an-app-transfer https://developer.apple.com/documentation/sign_in_with_apple/transferring_your_apps_and_users_to_another_team#3546291 https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team My last question is: how can I test this before going live? Do I really have to just implement changes/update the DB and then go live, hoping that it will all work? Can't I do some sandbox transfer or anything like that? Even just creating like a "clone" of my app and transferring this one would be a huge boost for the confidence of this big leap. Thanks in advance.

For Sign in With Apple I recieve an expected flow including an ask to share or hide my email along with a message like this 'Create an account for Apple {some_company} using your Apple ID “{email}”.' However when i sign into an existing account i get the same flow, where on other apps i see a message like this ~ "Do you want to continue using {some_company} with your Apple ID “{email}”? How can i configure this for my own app? Note: it always logs me into the correct existing account, i'm just trying to make sure users go through the correct flow in the apple popup when their account already exists.

When transferring an app from one team to another, Sign in with Apple users have to me carefuly migrated since their unique identifiers are team-scoped. To migrate users from Team A to Team B, a transient transfer identifier, aka transfer_sub, has to be generated by Team A before the transfer to prepare the app data, using specific migration endpoints provided by Apple. "Preparing the app data" means, for example, associate database entries to the transfer id instead of the team-specific id. One the app has been transferred, and during 60 days, Team B will find the transfer_sub in ID tokens issued by Apple Sign In, and thanks to this shared identifier they can retrieve the user data and associate it to their new unique identifier. So far so good ! Now, the question : if an app is transferred from Team A to Team B, and then, shortly thereafter (a few days later), from team B to team C, will the transfer_sub related to the B-C transfer be different ? Or will they remain the same as the ones issued for the A-B transfer ? (I'm asking this question in order to avoid the possible catastrophe of an ill-prepared double app transfer) Thank you !

We have been having issues where apple has provided the same sub for two different users. I was under the impression the sub is supposed to be unique? The issue became exacerbated when we transfered an app from one org to another. On transferring the users. Two different transfer subs, resulted in the same sub.

Hi all, I create web app laravel with function login with apple. This is any my information app and packet what i'm use : Laravel: 10.x PHP: 8.1 Packages for login: https://socialiteproviders.com/ I'm done with API appleid.apple.com/auth/authorize for auth user with apple ID. Response below : So next step i call to this API : https://appleid.apple.com/auth/token for verify token but response is below : I'm try with postman but response is same that ( invalid_client ). Everything is correct( client_id, team_id, private_key ). I use https://jwt.io/#debugger for test verify token. Signature Verified is result. Can help me for declare what is issue ? what client is invalid ? Thank you so much. P/s : Sorry for my poor English

I had implemented the Apple login feature and users were fully utilizing it. Then, all of a sudden, it started to fail with an "Invalid client scope " error. And My code is exactly scope="name email". I haven't changed any code for Apple Login, so why is this suddenly happening?

The revoke tokens endpoint (/auth/revoke) is the only way to programmatically invalidate user tokens associated to your developer account without user interaction. This endpoint requires either a valid refresh token or access token for invalidation, as Sign in with Apple expects all apps to securely transmit and store these tokens for validation and user identity verification while managing user sessions. If you don’t have the user’s refresh token, access token, or authorization code, you must still fulfill the user’s account deletion request and meet the account deletion requirement. You'll need to follow this workaround to manually revoke the user credentials: Delete the user’s account data from your systems. Direct the user to manually revoke access for your client. Respond to the credential revoked notification to revert the client to an unauthenticated state Important: If the manual token revocation isn’t completed, the next time the user authenticates with your client using Sign in with Apple, they won’t be presented with the initial authorization flow to enter their full name, email address, or both. This is because the user credential state managed by Sign in with Apple remains unchanged and returns the.authorizedcredential state, which may also result in the system auth UI displaying the “Continue with Apple” button. Respond to the credential revoked notification Once the user’s credentials are revoked by Apple, your client will receive a notification signaling the revocation event:  For apps using the Authentication Services framework to implement Sign in with Apple, register to observe the notification named credentialRevokedNotification. For web services, if an endpoint is registered for server-to-server notifications, Apple broadcasts a notification to the specified endpoint with the consent-revokedevent type. When receiving either notification, ensure you’ve already performed the following operations to meet the requirements of account deletion: Deleted all user-related account data, including: The token used for token revocation; Any user-related data stored in your app servers; and Any user-related data store in the Keychain or securely on disk in the native app or locally on web client. Reverted the client to an unauthenticated state. Securely store user tokens for account creations For all new user account creations, follow the expected authorization flow below: Securely transmit the identity token and authorization code to your app server. Verify the identity token and validate the authorization code using the /auth/token endpoint.  Once the authorization code is validated, securely store the token response — including the identity token, refresh token, and access token. Validate the refresh token up to once per day with Apple servers (to manage the lifetime of your user session and for future token revocation requests), and obtain access tokens (for future token revocation, app transfer, or user migration requests). For information about verifying an identity token and validating tokens, visit Verifying a user and Generate and validate tokens. If you have questions about implementing these flows, including client authorization, token validation, or token revocation, please submit a Technical Support Incident.

Hi! Like a bunch of people on the forums I'm having issues transferring my users from my previous Team to my new Team. When the app was still on the old team, I successfully generated transfer_subs for every one of my apple login users. Now, when trying to migrate them over, it ONLY works on users that have already signed in since the transfer, which is not good, I need to transfer the rest and get the new private relay emails. Here’s a curl of how I get my access token : I’m first generating the secret key using my team key that has apple sign in configured for it. curl --location 'https://appleid.apple.com/auth/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'scope=user.migration' --data-urlencode 'client_id=my.app.id' --data-urlencode 'client_secret=*** This works and I’m getting my access token, then I try to exchange the sub token curl --location 'https://appleid.apple.com/auth/usermigrationinfo' --header 'Content-Type: application/x-www-form-urlencoded' --header 'Authorization: Bearer *** ' --data-urlencode 'transfer_sub=xx.xxxx' --data-urlencode 'client_id=my.app.id' --data-urlencode 'client_secret=***’ This is when I receive : {"error":"invalid_request","email_verified":false} I’ve tried a lot of stuff, even got on the phone with an ex apple engineer and tried a bunch of stuff with him, but to no avail. I've submitted a report on feedback assistant on the 23rd August, but no answer yet. ID: 14898085

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!

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()

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.

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

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.

There are two apps under our account that need to be transferred to other teams, namely A app and B app. Both apps have the function of Apple login. Now we need to transfer the original Apple login user to the new team, and we need to generate a new transfer identifier, i.e. TransferId. We created a new p8 file for each app in the developer background, and then followed the apple document to generate the transfer identifier. A app can be generated normally, but B app cannot be generated, and the error http: 400, { error: 'invalid_grant' }; The process is as follows: Generate clientSecret according to the key and p8 file corresponding to the sent teamID and p8 file and clientId, i.e. bundleid. ✅ Generate accessToken using clientId and clientSecret. ✅ Generate transfer identifier (auth/usermigrationinfo). This interface reports an error http: 400, { error: 'invalid_grant' }. ❌

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

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

I'm trying to access my own financial data (I'm building a dashboard for my own personal finances) but can't seem to find an API for this. I found FinanceKit but it sounds like you have to be a big company to use that and that and it's more of a swift SDK than a generic API endpoint. Does anyone know how I can access my financial data without manual downloads?

Hello. I would like to provide both self-login/sign-up service and social login service to the app. According to the guidelines, if an app provides a social login service, it must provide Apple Login or another login service with equivalent privacy protection features. So, even if the app provides the company's own login/signup service, if it also provides any other social login service, do the above app review guidelines need to be considered? Or, if we provide our own login, can we ignore the above guidelines even if we provide social login? I don't really understand the guidelines, so I'm asking a question to get a clear answer. Thank you for reading my long question.

Hello, We are currently facing an issue with Apple Sign In that only occurs very rarely, and that for some reason mainly affects the Apple Review team, as everyone in the company can register with their personal Apple Account, and we can see multiple users in production using Apple Login. The problem is that when our BackEnd tries to validate the information on https://appleid.apple.com/auth/token we receive a "{"error":"invalid_request"}". We have no idea what is causing this intermittent issue and we currently have no way to reproduce it. We have been loging both succesull request and failing request and all look very simmilar and we have no ideia what may be causing the 400 here is an example of a curl that generated the problem curl --location 'https://appleid.apple.com/auth/token' --header 'Accept: application/json' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'client_id=----SECRET----'' --data-urlencode 'client_secret=----SECRET----' --data-urlencode 'grant_type=authorization_code' --data-urlencode 'code=----SECRET----'' --data-urlencode 'redirect_uri=----SECRET----'' Any ideia what may be causing this?

We've had Signin with Apple integrated & working since 2020. Recently we've started seeing invalid_request errors in token validation API when we submitted our app for review. However, we are unable to reproduce this issue when testing it on the TestFlight build (occurring only on the App Review team's device). We've also tested on a device with similar specs and failed to reproduce the issue. App Review device details: Device type: iPad Air (5th generation) OS version: iOS 17.4.1 Here's a sample of the validation request. url = "https://appleid.apple.com/auth/token" headers = { "content-type": "application/x-www-form-urlencoded" } body = { "client_secret": "generated_jwt_token", "code": code generated in the app, "client_id": bundle id of the app, "grant_type": "authorization_code" } We are not adding redirect_uri in body since we don't use Apple signin on web. We generate the client_secret with the private key from Keys in Apple developer dashboard and use the following header & payload. header = { "alg": "ES256", "typ": "JWT", "kid": key id } payload = { "iss": team id, "iat": current timestamp in seconds , "exp": current timestamp + 180 days, "aud": "https://appleid.apple.com", "sub": bundle id of the app (same as client_id above) } The only error description we get is invalid_request which does not help find the root cause of the issue. We haven't done any changes wrt to Apple sign-in in this build, the only change we have done is update all third-party SDKs and added the Privacy manifest file which I'm sure should not affect the Signin with Apple.