visionOS Sign In With Apple support for Cognito User Pools about amplify-swift

[harsh62]

@LarissaKim Thanks for creating the issue. Our team will look into your questions and provide and update as soon as we can. Appreciate your patience.

[LarissaKim]

@harsh62 I'm following up with details regarding my specific use case to provide further context:

Cognito User Pool is used for authentication and an Identity Pool manages S3 resource access (primarily to enable "guest" user access). Ideally, Sign In with Apple would be the exclusive authentication method. StoreKit is integrated to manage subscriptions, and certain app features require users to be both authenticated and have an active subscription. Having users federate via Sign In with Apple would streamline the account and subscription management by associating them directly with the user's Apple ID. Our app's business logic also requires a user to be associated with a "username", so we would prompt users for one upon sign-up and assign it to their preferred_username attribute.

Based on the documentation and insights from existing discussions, it seems that signInWithWebUI would be the only option for integrating Sign In with Apple for a Cognito User Pool.

Given this context:

1. Is signInWithWebUI indeed the recommended method for integrating Sign In with Apple in our scenario?
2. Are we able to add or update attributes (such as preferred_username and custom user attributes) for users who sign in through federated identity providers?
3. Assuming we initially implement authentication via USER_SRP_AUTH, what would the transition process look like for users to federate with Sign In with Apple as their primary authentication method later?
4. Would using AWSMobileClient.default().showSignIn be an option for visionOS, or is this only available on iOS?

I would greatly appreciate your guidance on implementing this with Amplify, including any alternative strategies that might be better suited for our goals.

[harsh62]

@LarissaKim Answers to your original questions first

The Amplify.Categories.Auth.AuthCategory+ClientBehavior interface seems to indicate that signInWithWebUI is supported on visionOS. However, the docs state that "Social sign-in (OAuth) functionality is only available in iOS and macOS."

Since VisionOS is dev-preview, the official documentation has not been updated to include VisionOS.

Is signInWithWebUI the only way to implement social sign-in with Cognito User Pools?

Yes. ATM signInWithWebUI is the only way.

Is Sign in with Apple via signInWithWebUI for a Cognito User Pool supported for visionOS?

Yes. The API is available on VisionOS.

---

Answers to your 2nd post:

Is signInWithWebUI indeed the recommended method for integrating Sign In with Apple in our scenario?

Yes. ATM this is the only way to use Sign In with Apple.

Are we able to add or update attributes (such as preferred_username and custom user attributes) for users who sign in through federated identity providers?

Yes. Check documentation. See AuthUserAttributeKey for the type of user attributes available to update.

Assuming we initially implement authentication via USER_SRP_AUTH, what would the transition process look like for users to federate with Sign In with Apple as their primary authentication method later?

See this AWS Blog to understand how Sign In with Apple works with Cognito User Pools.

Would using AWSMobileClient.default().showSignIn be an option for visionOS, or is this only available on iOS?

AWSMobileClient (which is part of the AWS SDK) would not support VisionOS.

[LarissaKim]

@harsh62 My original goal was to integrate a native Sign In with Apple experience for the users. I had assumed signInWithWebUI was not yet supported on visionOS and didn't have a pressing need for DynamoDB (since User Pool attributes seemed adequate for user profile management), so I decided to authenticate users directly into a User Pool.

While you have confirmed thatsignInWithWebUI is indeed supported on visionOS, I'd still like to provide a native sign-in experience. It seems this would only be possible by federating users into an Identity Pool and managing user profiles independently.

A shift in our project's requirements has now made it necessary to implement a REST API (API Gateway with Lambda integration/DynamoDB). This validates the case for managing user profiles directly.

Considering the objectives to 1) securely and consistently identify and associate users by their Apple ID, and 2) offer as close to a native sign-in experience as possible, are there any potential challenges or limitations with relying solely on an Identity Pool for social sign-in with Amplify, without integrating a User Pool, I should be aware of before committing fully to this path?