Keychain access group used for the sign-in state

[byohay]

Hi,

This framework stores the user's sign-in information persistently in the keychain storage. From looking at the code, it doesn't set the access group of the query to the keychain, which means according to Apple's docs that it will use the first access group.

If the first access group is shared in several apps of the same vendor, this means that the state will be read and written to the same place, which means that one app will get the user state of another app, which is not necessarily the desired result.

Did I understand everything correctly? If so, what's the way to work around it? Also if that's the case, I suggest to document it explicitly.

Thanks

[byohay]

@petea what are your thoughts about this?

[petea]

GSI stores sign-in state in the default keychain group. If you have the Keychain Sharing capability enabled and one or more keychain access groups defined, the default keychain group will be the first item in this list of keychain access groups. Groups defined after this first group could be used for state sharing between apps without GSI state being present, if that's desired.

[byohay]

@petea In our apps the first keychain access group is the shared one, meaning GSI will store the state in a shared place that will be read and written by all our apps. That's undesired of course. I can think of several ways to avoid such mistakes in the future:

• Keep the current behavior and explicitly mention this in the README.
• Use a different service for each app based on their bundle ID (Like being done in FB SDK). This will require migration which is not desired I assume.
• Allow to select the keychain storage name (Like being done in MSAL). Might also require migration

What do you think?