Post not yet marked as solved
Please request a Technical Support Incident, including your bundle/client ID, or failing request (if a web service), and I'll be happy to troubleshoot.
Post not yet marked as solved
An invalid client error can be the result of multiple failure points on the client-side implementation. For a quick reference of the potential errors returned from the validation response, please see ErrorResponse.
Additionally, the most common occurrence is a mismatched client identifier between the following scenarios:
the client id provided in the authorization request (or the audience claim contained within the identity token of the authorization response); and
the subject contained within the client secret generated for the validation request.
Please see the Generate and Validate Tokens for additional information about the validation servers.
Post not yet marked as solved
Please direct all App Store Review Guideline questions to the App Review team directly, by using the Contact Us form.
https://developer.apple.com/app-store/review/
You must create a Services ID to associate your web service with a primary App ID from your developer account. Please follow the steps outlined in Developer Account Help: Sign in with Apple – Configure Sign in with Apple for the web—
https://help.apple.com/developer-account/#/dev1c0e25352
Hi tony308,
I've checked the bundleId several times. I've created new Identifiers and keys, used those new values instead and I get the same issue. [...]
The client_id must be identical to the client_id used to receive the initial authorization response. If you are authorizing on iOS, the authorization grant code validation must use the iOS bundle ID as well; otherwise, if you received the grant code via your client_id should be your Services ID created for the web application. Whenever these client_id values mismatch, the grant code validation will fail as the code was issued for another client.
If this is not the case, please submit a Technical Support Incident - https://developer.apple.com/support/technical/ and I can take a deeper look into your scenario.
Post not yet marked as solved
Hi jrim,
I don't have much information about your app, web service, or configuration, to assist you here. Please submit a Technical Support Incident - https://developer.apple.com/support/technical/ so we can investigate the issue, when doing so, please provide the App ID, Team ID, and if your app uses Sign in with Apple via the AuthenticationServices framework, the Sign in with Apple JS SDK, or the Sign in with Apple REST API.
Post not yet marked as solved
Hi James G,
Is this something expected from Apple's OIDC server? or am I doing something wrong? I've tested it with both native iOS SWIA and on the web client as well, and both produce the same result.
Sign in with Apple does not provide incremental changes to the user scope. If the application initially omitted, and later included, the email scope, only newly authorized users would include the email claim in their identity token (and in the initial user body of the authorization response).
If a user were to revoke access to your app via the steps outlined here - https://support.apple.com/en-us/HT210426, they would be treated as a newly authorized user and would also respect the requested email scope.
If you have any further questions about Sign in with Apple, please [submit a Technical Support Incident] (https://developer.apple.com/support/technical/) and I'll be happy to help.
Post not yet marked as solved
Hi vikaaa,
Please see App privacy details on the App Store - https://developer.apple.com/app-store/app-privacy-details/ for more information about providing details about data collection in your app.
Post not yet marked as solved
The Server-to-Server Notification responses are documented here—
Processing Changes for Sign in with Apple Accounts - https://developer.apple.com/documentation/sign_in_with_apple/processing_changes_for_sign_in_with_apple_accounts
Hi TylerKenneth43,
The behavior you've reported is the result of a system bug, and should be fixed in a future release. As a workaround, you can prevent the race condition by wrapping your deletion logic in NSManagedObjectContext.perform:
private func deleteItems(offsets: IndexSet) {
withAnimation {
viewContext.perform {
offsets.map { molts[$0] }.forEach(viewContext.delete)
do {
try viewContext.save()
} catch {
viewContext.rollback()
userMessage = "\(error): \(error.localizedDescription)"
displayMessage.toggle()
}
}
}
}
Please let me know if the information above does not resolve your issue(s).
Cheers,
Paris
Hi TylerKenneth43,
Please submit a focused sample project via Feedback Assistant - https://feedbackassistant.apple.com along with your description above and the complete error output. Once submitted, please reply here with your Feedback ID so we can take a closer look into the issue and provide some insight into the underlying cause.
Post not yet marked as solved
Hi David,
Sorry to hear about this experience! Please see the following Apple Support article for tips on how to avoid scams and what to do if you think your account has been compromised. Specifically—
If you receive a suspicious email that looks like it's supposed to be from Apple, please forward it to reportphishing@apple.com. Recognize and avoid phishing messages, phony support calls, and other scams - https://support.apple.com/en-us/HT204759 – Apple Support
Post not yet marked as solved
Please submit a Technical Support Incident - https://developer.apple.com/support/technical/, or a bug report via Feedback Assistant - https://feedbackassistant.apple.com, so we can look into this issue. If you submit a bug report, please respond with the Feedback ID, so we can begin our investigation.
Post not yet marked as solved
The email is included in the identity token on subsequent requests. The related claims are as follows—
email: A String value representing the user’s email address. The email address will be either the user’s real email address or the proxy address, depending on their status private email relay service.
email_verified: A String or Boolean value that indicates whether the service has verified the email. The value of this claim is always true, because the servers only return verified email addresses. The value can either be a String ("true") or a Boolean (true).
is_private_email: A String or Boolean value that indicates whether the email shared by the user is the proxy address. The value can either be a String ("true" or "false") or a Boolean (true or false).
For additional information about the identity token, please see Authenticating Users with Sign in with Apple - https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/authenticating_users_with_sign_in_with_apple.
Post marked as Apple Recommended
In order to send email messages through the relay service to the users’ personal inboxes, you will need to register your outbound email domains. All registered domains must create Sender Policy Framework (SPF) DNS TXT records in order to transit Apple’s private mail relay. Please ensure the source emails and domains are properly registered for your developer account, and that you have Private Email Relay notification enabled to detect misconfigurations and receive periodic emails of failed deliveries.
All outbound emails sent through the Private Email Relay service must be authenticated with the Sender Policy Framework (SPF) and/or DomainKeys Identified Mail (DKIM) protocol. This is to prevent spam and ensure that messages sent to your users only come from your registered source email addresses and email domains. We recommend authenticating outbound emails using both SPF and DKIM, if possible.
For additional information, please see Developer Account Help: Sign in with Apple - Configure Private Email Relay Service > Authenticating Your Domains - https://help.apple.com/developer-account/#/devf822fb8fc—
Using SPF Authentication
The domain in the envelope sender (also known as the MAIL FROM, bounce, or Return-Path address) must be registered in the Domains section of Certificates, Identifiers & Profiles. This domain must pass SPF validation, and the registered domain and envelope sender domain must match exactly to pass the private relay service SPF check.
Using DKIM Authentication
If you use an email service provider that uses their domain in the envelope sender of your outbound emails, you must sign your emails with DKIM to meet the private relay’s email authentication requirements.
The DKIM domain (the d= value in your DKIM signature) will be matched against the domain used in your email’s From: address (aka the header From: address) that is registered in the Domains section Certificates, Identifiers & Profiles. To pass the private relay’s DKIM check, the DKIM signature must pass verification, the DKIM signature must include the From: address, and the DKIM domain and the domain in the From: address must match exactly.
Registering Valid Source Domains and/or Emails
After the private relay authenticates inbound emails with either SPF or DKIM, it will also match the source email or domain against your registered email domains or email addresses.
You must register and validate every source email domain or subdomain you intend to use. If you do not own a domain configured for email, you can register individual source email addresses. For example, if you want to send emails from “john@example.com” and “john@sales.example.com” you must choose to register source email domains as “example.com” and “sales.example.com” or you may choose to register individual source email addresses as “john@example.com” and ”john@sales.example.com”.
If you want to send email addresses from any other source (for example, “john@help.example.com”) you must also register “help.example.com” or “john@help.example.com” as a separate source.
If you do not register all the source domains or emails that you use, email sent to the private relay service will result in a bounce message.
Configuring Your Email Service Provider (ESP) Account
If you send outbound emails with email service providers such as Amazon SES, Mailchimp, or SendGrid, the SPF record you publish for your email sending domain should look similar to examples below. The “include” mechanism in the SPF record authorizes your email service provider’s mail servers to send on behalf of your domain.
SPF TXT Record for example.com to support using SendGrid example.com. IN TXT "v=spf1 include:sendgrid.net ~all"
SPF TXT Record for example.com to support using Amazon SES example.com. IN TXT "v=spf1 include:amazonses.com ~all"
SPF TXT Record for example.com to support using Mailchimpexample.com. IN TXT "v=spf1 include:servers.mcsv.net ~all"
