User Profile

We have a multiplatform app and use both the web and iOS Sign in with Apple flows. Our backend service is shared. We can negotiate the id_token and validate the grant code with the apple /token endpoint as described in the "Verifying a User" article.We have multiple environments for test and production. In order to keep the production client_secret "secret", we need a separate secret for test environments that will not work on production. How can we achieve this?It looks like we have to create a separate Application ID, service (client_id) and associated key. This is fine for web since it can just pass an arbitrary client_id but what about iOS? iOS apps are tightly-coupled to their Applications (and therefore their client_ids). Is there no way to use an arbitrary client_id for SIWA on iOS? Do we really need a separate version of our iOS app for the test environment? This would be really disruptive to our workflow.

We have a set of internal domains that we use for development and testing. In "Web Authentication Configuration" we have a bunch of redirects set up to these domains. Currently things are working for Sign in with Apple, but we are concerned that at some point a strict policy will kick in and prevent redirects to unverified domains. Is this a legitimate concern? Will our redirects to unverified domains cease to function at some point?

I am implementing Sign-in with Apple for a SaaS Android app and hitting design issues. We need to support SiwA on Android for users who use multiple platforms.One complicating factor is the use of a POST-ed form to pass the code and token. Intercepting the redirect endpoint via an app intent-filter does not seem to work for POSTs. Using a webview with javascript injection may work but that level of hackery makes me squeamish. Here's the approach we are currently considering:1. App sign-in-with-apple button launches a hosted "https://foo.com/signInwithApple.html" page in Android Chrome.2. signInWithApple.html configures the request using Apple's .js library and immediately launches the flow3. User signs in with Apple4. Upon completion, post results to a hosted redirect endpoint: https://foo.com/redirect5. The redirect endpoint extracts form data and immediately forwards to foo://bar?apple_token=123&code=4566. Android intercepts the foo:// request via intent filter and receives apple_token (a JWT signed by Apple) and code7. Client exchanges apple_token and code for an app session token via our https://foo.com/token endpoint8. https://foo.com/token will verify apple_token against Apple's public key, validate the code using apple's auth/token endpoint, and return an app session token for the app user that maps to the user ID ("sub") in the JWT.