Summary: Need help with Certificates, Identifiers and Profiles settings to allow two apps to use Sign in with Apple. Background: We have a web application (React, static JavaScript) that allows users to sign in with Apple, Google or Microsoft via OAuth/OIDC. We are developing a mobile application using React Native and Expo. Both the web application and the mobile application use the same backend (Django). For the mobile application, we added Google and Microsoft sign in via the same web-based OAuth/OIDC flow. For Sign in with Apple, we are using the expo-apple-authentication package to get the required native sign in experience. We have two active app identifiers: org.terraso.terraso; web app; primary Apple ID org.terraso.test.Terraso-LandPKS; mobile apple; Group with an existing primary App ID (selected (1), the web app) We have one services identifier: org.terraso.app; primary ID is web app (app identifier 1) above; URLs have been configured We have one app group: group.org.terraso (seems unused) On our backend app, we have code: https://github.com/techmatters/terraso-backend/blob/abc655e83eaca849e2bc24389946cc4f0bcd9d48/terraso_backend/apps/auth/providers.py#L84 and APPLE_CLIENT_ID is set to org.terraso.app (which matches the services identifier above In my local development environment, I have tried a few different combinations of IDs attempting to get this to work using the iOS simulator: (i) backend client id: org.terraso.app mobile app bundle Id: org.terraso.test.Terraso-LandPKS result: error: jwt.exceptions.InvalidAudienceError: Audience doesn't match (ii) backend: org.terraso.app mobile app: org.terraso.app result: clicking "Sign In" in Apple ID dialog is a no-op (no errors from client or server) (iii) backend: org.terraso.test.Terraso-LandPKS mobile app: org.terraso.test.Terraso-LandPKS result: works (but I can't use that in production, because the client ID is wrong) How can I configure Sign in with Apple to allow both the web app, the mobile app (and possible additional mobile apps) to work with the same backend? Do I need to us app groups? When do you use app groups vs "group with an existing primary apple id"?

Good day folks, We have a workflow setup where a new Sign in with Apple user registers (first SIWA login where user can pick name and show/hide email), and the server-side code obtains a refresh token from SIWA REST API. That refresh token is stored internally against the user's profile in the DB for future use. Whenever user account is deleted from server-side, we use that refresh token to revoke Sign in with Apple (so that the user would need to go through registration flow rather than sign in- where they have an option to specify name and show/hide email). That has been working beautifully until we have added an AppClip to the app. The code which obtains the refresh token "respects" the correct bundle ID for the main app / app clip, and everything seems to work. Both of Apple's APIs return OK codes. In fact, we even get the email from Apple when token is revoked which reads "APP_NAME has revoked your Sign in with Apple account. Next time you use Sign in with Apple to sign in to your onUgo Access account, you will have to share your name and email again". Problem is- it doesn't. SIWA still offers to "sign in" as if account is still linked, and the app still shows up as "App using Sign in with Apple" in iPhone settings. What's even more mysterious is that you can't delete/revoke/"Stop using Apple ID" on that SIWA link with the app from iPhone settings too! It seems to work, but the app never goes away from the list, as if it fails silently. Could anyone please help shed some light on this?

Hello, I have implemented Sign in with Apple in my iOS app and am currently trying to implement the revocation feature. However, I keep encountering an invalid_client error when calling the Apple authentication/revocation API. Here are the details of my configuration: Team ID: HUGD2H952H Client ID: com.puppylink.puppylinkapp Key ID: KXSYK98424 I am using these details to generate a client secret with the JWT ES256 algorithm. Below is the code I am using on the backend server to generate the client secret: private fun makeClientSecret(): String { val now: ZonedDateTime = ZonedDateTime.now(ZoneOffset.UTC) val expirationTime: ZonedDateTime = now.plusMinutes(5) // Setting expiration time to 5 minutes return Jwts.builder() .setHeaderParam(JwsHeader.KEY_ID, appleProperties.keyId) .setHeaderParam("alg", "ES256") .setIssuer(appleProperties.teamId) .setIssuedAt(Date.from(now.toInstant())) .setExpiration(Date.from(expirationTime.toInstant())) .setAudience("https://appleid.apple.com") .setSubject(appleProperties.clientId) .signWith(getPrivateKey(), SignatureAlgorithm.ES256) .compact() } private fun getPrivateKey(): PrivateKey { val resource = ClassPathResource(appleProperties.privateKeyFile) val privateKey = String(Files.readAllBytes(Paths.get(resource.uri))) val pemReader: Reader = StringReader(privateKey) val pemParser = PEMParser(pemReader) val converter = JcaPEMKeyConverter() val keyInfo = pemParser.readObject() as PrivateKeyInfo return converter.getPrivateKey(keyInfo) } } Additionally, here is the code used to call the Apple authentication API from the backend server: @Service class AppleAuthService( private val appleProperties: AppleProperties, ) { private val logger = LoggerFactory.getLogger(javaClass) private val restTemplate = RestTemplate() fun getTokens(authorizationCode: String): TokenResponse { try { val clientSecret = makeClientSecret() val formData: MultiValueMap<String, String> = LinkedMultiValueMap() formData.add("client_id", appleProperties.clientId) formData.add("client_secret", clientSecret) formData.add("code", authorizationCode) formData.add("grant_type", "authorization_code") val headers = HttpHeaders() headers.contentType = MediaType.APPLICATION_FORM_URLENCODED val requestEntity = HttpEntity(formData, headers) val response = restTemplate.postForObject( "https://appleid.apple.com/auth/token", requestEntity, TokenResponse::class.java, ) return response ?: throw RuntimeException("Failed to retrieve tokens from Apple") } catch (ex: Exception) { logger.error("Error retrieving tokens: ", ex) throw ex } } data class TokenResponse( val access_token: String, val expires_in: Long, val id_token: String, val refresh_token: String, val token_type: String, ) Despite generating the client secret correctly, I am still receiving the invalid_client error when calling the API. Could you please help me identify the cause of this error and provide guidance on how to resolve it? Thank you.

We are currently using "Sign in with Apple for the web": https://developer.apple.com/help/account/configure-app-capabilities/configure-sign-in-with-apple-for-the-web/ but we do not publish apps on the App Store. Because of corporate re-structuring, we need to migrate to a new Apple Developer / App Store Connect account. So we are looking to migrate "Sign in with Apple" users to the new account. Apple does provide guides on how to do it: https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer but unfortunately, it only works if "Sign in with Apple" is used with an app published on the App Store (it requires app transfer). Who should we handle this case? Please help.

We are trying to integrate "Sign in with Apple" and are facing an issue where all users who chose to use Apple's private relay with the hide my email feature are unable to receive any mail sent by us. We have added our domain, mail from domain & email address to https://developer.apple.com/account/resources/services/configure and also verified the SPF. We also have DKIM setup. We use SES as our email provider and have added its SPF as recommended aswell. I have attached a sample delivery log from SES below. {"notificationType":"Delivery","mail":{"timestamp":"2024-01-17T10:20:07.592Z","source":"\"Redacted\" <admin@redacted>","sourceArn":"arn:aws:ses:ap-south-1:redacted:identity/redacted","sourceIp":"34.redacted","callerIdentity":"redacted-ses","sendingAccountId":"redacted","messageId":"redacted","destination":["redacted@privaterelay.appleid.com"]},"delivery":{"timestamp":"2024-01-17T10:20:12.385Z","processingTimeMillis":4793,"recipients":["redacted@privaterelay.appleid.com"],"smtpResponse":"250 2.0.0 Ok: queued as redacted","remoteMtaIp":"redacted","reportingMTA":"redacted.smtp-out.ap-south-1.amazonses.com"}}

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