Can I have the same audience claim value when using Sign In with Apple via an app and website?

user_403425 0
Viewed 218

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?

sign-in-with-apple apple-sign-in jwt
2 Answers

ID TOKENS

The audience for an ID token represents the client application, so you will have 2 different audience values. ID tokens are typically validated by the client app, eg in the mobile code, but using an API to do the work is also possible.

ACCESS TOKENS

Here is the OAuth standard behaviour:

  • Don't send ID tokens as credentials in API requests - send access tokens instead. Access tokens have an audience that specifies an API or a set of related APIs, eg api.mycompany.com.

  • Issue your own access tokens, where you can control the scopes and claims that your APIs will need for authorization - Apple tokens are not designed to be used in your own APIs

AUTHORIZATION SERVER (AS)

The optimal way to issue your own tokens is to let an AS manage the connection to Apple for you - as in this tutorial.

SUMMARY

Hopefully this gets across key points in case useful. Aim to base solutions on the standard design patterns that have been vetted by experts for many years. Sometimes vendor specific guides don't explain these principles well.

user_90198850

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.

user_48003440
Related