I've implemented Sign In with Apple in my iOS app, and now I have also implemented it in my website. What surprises me is that both flows end up with a difference audience value in the id token, is that to be expected? The iOS app uses the app's bundle id, and the web flow uses the service id's identifier.
So for example in the iOS flow the audience is com.domain.app and in the web flow the audience is com.domain.siwa. When I'm sending the id token to my server where I am doing the validation logic, I now have to know where the id token comes from so I can use the correct audience. It would be easier if the audience could just be the same for both flows. Is that possible? Or should I just forgot about this and work with two difference audience values?
The reason why the audience aud claims of your JWT tokens differ is that, as Apple themselves puts clearly, the audience registered claim identifies the recipient for which the identity token is intended.
Simply put, as the audiences are literally different, the aud claim should & will always be different.
This is not unique to Apple and is actually taken from RFC7519: JSON Web Token, so trying to make the aud claim values the same is actually going to be against the JWT spec.
Here is how RFC7519 describes it:
The "aud" (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim when this claim is present, then the JWT MUST be rejected. In the general case, the "aud" value is an array of case- sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case-sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL.
If you need to, I would say to just deal with different audience values but what are you using the aud claim value for anyway?
If you're trying to restrict specific features, for example, based on a certain "audience", feel free to use it however the use of this claim for business logic isn't really that widespread.
Other claims will most likely be better suited depending on what you're exactly trying to achieve here.