Amplify-js: Storing user attributes in AWS against anonymous unauthenticated user

[fredrivett]

Which Category is your question related to?

Authentication, User data

What AWS Services are you utilizing?

Amplify, AppSync, Cognito, DynamoDB

Provide additional details e.g. code snippets

I'm new to AWS (started last week) so forgive me if I come across as naive here. I've spent the past few days trying to understand how I can migrate my current Firebase setup over to AWS. I'm using AWS Amplify with React Native (Expo), and authenticating with AppSync & Cognito. The point I'm stuck on is the following:

We don't want to force users to sign up when they download the app, but still need to store user attributes (like the notification token) in the cloud so we can access this via a node script and send notifications to our users.

I know we can setup unauthenticated identities in Cognito Identity Pools, and I know we can store attributes against users in the Cognito User Pools, but as far as I know, the unauthenticated identity setup doesn't include a user from the User Pools, so my question is:

Is it possible to store user attributes against an anonymous, unauthenticated user/identity?

Or are there other solutions to this issue?

With our current setup on Firebase, it's all very simple, we simply add an item to the user in the DB, but I'm at a loss at how to do this with AWS Amplify.

It seems the done thing is to store user attributes against a user, but I don't have a user in the User Pool to store it against, just an identity in the Identity Pool.

Any help much appreciated.

[powerful23]

@fredrivett Hi as I know there is no way to store attributes on unauthenticated identities unless you use something like DynamoDB to store those attributes.

[fredrivett]

Hey thanks for the reply @powerful23. I guess my situation here is an edge case. Though it would be nice if Amplify played nicer with unauthenticated users. As I say Firebase makes this super easy (link in original post) by just allowing you to treat an unauthenticated user the same as an authenticated user, and later just letting Firebase know the user has now signed up.

Understand the AWS setup is far more powerful, but doesn't seem to play nicely with unauthenticated users (not in a way someone new to AWS like me could understand, at least).

For now we've decided to force users to sign up, which isn't a great UX but seems the simplest way forwards.

[manueliglesias]

@fredrivett

An alternative solution which some people do, is to have a generic "unauth user" account in user pools that just serves as the unauthenticated user and you put that password in the client code.

[sakhmedbayev]

Posted question on the StackOverflow here

[fredrivett]

Thanks for the reply @manueliglesias. So you're saying that there'd be one "unauthenticated user" that all logged out folks would use. Then I'd need to store the data somewhere like DynamoDB, and then if someone converts and signs up, I would need to write custom logic to transfer any user data I've stored there over to the new user? That wouldn't work easily for storing user attributes (like onboarded, or notificationsToken)

Just checking I'm understanding what this solution might look like.

For me this is the biggest blocker with using AWS, as I much prefer a system that allows users to use an app without requiring sign up. I feel like this is quite a common use case too.

It can be handled with AWS, in the sense of storing everything offline on device for these users and manually bringing this online once the user signs up, but doubles the complexity of the app as it now has to manually handle both pulling data from offline storage and from AWS, depending on if the user is signed up. Maybe I've been spoilt with how nice this is handled with Firebase.

[undefobj]

@fredrivett We are working on automating this & making it easier. You are correct that if you want to have Auth & UnAuth access to an AppSync API you will need to use AWS_IAM via Cognito Identity Pools right now. If you could take a moment and read our RFC please do so to ensure that we are capturing your requirements: aws-amplify/amplify-cli#766

In the meantime, we have provided a sample to help unblock you here: https://github.com/dabit3/appsync-auth-and-unauth

cc: @dabit3 @manueliglesias @kaustavghosh06

[vparpoil]

I guess my situation here is an edge case

Many of us are in an edge case then ;) The user experience you describe as being unauthenticated at first with optional sign up seems pretty natural to me and the good way to design apps. I second you wanting amplify/appsync to be more straightforward to set up this way

[GraemeAllanBryce]

I agree this is not an edge case but more "best practice". Forcing a new user to create an account with username and password before they can see the value of an app is an impediment to on-boarding.

Ideally it would be possible to allow a new "user" to "proceed as a guest" and at that stage create a identity in the IDP but not yet create a user in the pool. At some later stage when the user decides the app is good for them and they want to have a login to recover data etc then we would want to create a user in the pool but have this remain linked to the IDP identity that has already been created for them.

This also means that all analytics passed to Pinpoint from before and after they create the account are all linked and so funnels can be created that include everything the user did.

[davegariepy]

trying to find a solution to this.

My use case is a little different in that I'm not using Appsync but API gateway instead.

[martinjuhasz]

This is an absolute must.
My usecase: Users provide additional information about themselves on signup. I cannot do a graphql query when a user doesn't have an account yet.

I will use user pool attributes for the moment but they are not an exact match for some user informations.

It would be nice if i could do requests with a user directly after signup that is not yet confirmed and reflect that in my @auth directives in my graphql schema.