Are there any mechanisms to troubleshoot or test SiwA server-to-server notifications? I am not seeing any traffic from Apple for user account changes (e.g., revoking authorization for an app), but the URL that I have configured in my account matches my endpoint, it is available from the public internet, and other SiwA functions are working correctly. Any guidance will be appreciated.
Hi,
Are there any mechanisms to troubleshoot or test SiwA server-to-server notifications?
Configure Your Server for Notifications
To receive Sign in with Apple server-to-server notifications, your server must support Transport Layer Security (TLS) 1.2 or later. The endpoint URL you provide must be an absolute URI, including the scheme, host, and path (e.g., https://example.com/path/to/endpoint). This URL is configured in App Store Connect or the Apple Developer portal. To learn more, see Processing changes for Sign in with Apple accounts.
Ensure your server is configured to respond with an HTTP 200 status code to indicate successful receipt of a notification. If a non-200 response is returned or a timeout occurs, Apple's servers will retry sending the notification.
Troubleshooting Notification Delivery
If you are not receiving Sign in with Apple server-to-server notifications, consider the following troubleshooting steps:
- Verify Endpoint Configuration: Double-check that the server-to-server notification endpoint URL configured in your Apple Developer account (under Certificates, Identifiers & Profiles, then your App ID) exactly matches your server's endpoint. Only one URL can be provided per Sign in with Apple app grouping and key.
- Check ATS Compliance: Ensure your server's connection adheres to App Transport Security (ATS) requirements. This includes using a certificate issued by a trusted certificate authority, TLS 1.2 or higher, and a certificate signed and hashed using SHA-256 or greater.
- Review Server Logs: Examine your server logs for any incoming requests from Apple's IP addresses (subnet 17.0.0.0/8) and for any errors in processing the notification payload. This can help identify issues with network connectivity, SSL/TLS handshakes, or payload parsing.
- Validate JWS Payload: After receiving a notification, your server must decode the JWS payload and use the algorithm specified in the header's
algparameter to validate the signature. Failure to properly validate the signature might lead to your server discarding valid notifications. - Check for OAuth Errors: If other Sign in with Apple functions are working, but specific notifications are not, review TN3107: Resolving Sign in with Apple response errors for common OAuth error codes and their solutions, which might indirectly affect notification delivery or processing.
Test Server-to-Server Notifications
While there isn't a specific 'test notification' endpoint for Sign in with Apple server-to-server notifications similar to App Store Server Notifications, you can simulate user actions to trigger these notifications in a testing environment.
To test consent-revoked notifications, have a test user revoke authorization for your app. This can be done manually by the user through their device settings. For example, on an iOS device, a user can go to Settings > Apple ID > Password & Security > Apps Using Your Apple ID, select your app, and choose 'Stop Using Apple ID'. You can also programmatically achieve this by invoking the Token revocation endpoint. Your server should then receive a consent-revoked notification.
For comprehensive testing, ensure your server's logic correctly handles the decoding, validation, and processing of all expected notification types, including email-enabled, email-disabled, consent-revoked, and account-deleted events.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
