Amplify-js: Is it possible to get a access_token for guest users using Cognito User Pool?

[talkhot]

In my use case I use Cognito User Pool with aws-amplify as authorization type for access to the
Appsyc graphql api. This because than I can attach roles to logged-in users (a blogger, admin, reviewer etc). With User Pool I can use these roles seamlessly with the appsyc resolvers for dynamodb. The other auth options for the api don’t bring this advantage (if i understood the docs well). Besides a logged-in user I would also like guest vistors being able to read the website's content.

To authorise my request I send along a Authorization header with the JWT token (accessToken) created by amplify after a user login. It seems a guest user is not provided with a accessToken and so I can’t use graphql API with a guest (not logged-in) user. I’ve been looking trough the code and docs to see if this really is the case, but I can’t find a define answer.

So my question is, it it possible with amplify to get a accessToken for guest users, using the Cognito User Pool?
Or is there a recommended workflow for this use-case?

[rowanu]

I don't think that's possible using just User Pools - unauthenticated identities are a feature of Cognito Identity Pools.

[talkhot]

@rowanu If that's the case, and it seem so it would be great if appsync could add this feature. For mobile mandatory login make sense, but on web not.
The alternative seems to do role based authorisation with lambda, but than you have a lot of extra work.
The combination Cognito User Pool + Appsync would be great to also build a 'web' api.

[buggy]

I've been talking to an Amazon developer advocate about this and it seems that there are two options currently available:

1. Create an anonymous user account in Cognito User Pools. You can hard code a known password into your app or use Lambda triggers on the Cognito User Pool to enable passwordless login for this account.

2. Set up Cognito Federated Identities and Cognito User Pools. For the anonymous user get an access token from Federated Identities. For a logged in user get the access token from User Pools. Configure AppSync to use IAM authentication which will require all requests to be signed. Most of the AppSync documentation seems to assume Cognito User Pools authentication so you may find some of the filtering and fine-grained access control examples don't work.

[talkhot]

@buggy Thanks a lot for asking for the available options.

[joemastersemison]

@buggy -- can you explain more about how you could do #1 with lambda triggers? It seems to me that it would have to be the preauth trigger, and it doesn't seem to let you auto-log a particular user in; it just seems to let you reject users that might otherwise have been authenticated? (Judging by the fact that the trigger doesn't take any response?)

[honkskillet]

@buggy For option 2, how do you get the access token for a logged in user to be from User Pools. Right now I have it set up using IAM auth but both unauthenticated and authenticated tokens are from Federated Identities which has no user info.

[mixja]

@joemastersemison - you can do password-less authentication using a custom authentication workflow but the challenge here is that you need something to initiate that workflow using the AdminInitiateAuth API call (this allows you to invoke the workflow without user authentication) and it requires permissions to do so. I'd say having a guest user with a default password, as ugly as it is, would be simplest.

The other option might be to use the User Migration hook, which will be called if a user is not found in Cognito. This would require your client-side code to determine it is running as a Guest, generate a GUID and random password for the user ID, and then attempt to authenticate. The User Migration hook would then accept the user with associated attributes, which would cause Cognito to provision the Guest user (with GUID user ID) into Cognito.
This would result in a large number of "guest" users (which you could clean up), and bear in mind Cognito charges based upon Monthly Active Users.

[joemastersemison]

@mixja - thanks, I think the hardcoded guest user with public password is definitely the best option. Been playing with it for a few weeks now, and it's not awful.

[buggy]

PR #566 will add support for passwordless logins so you don't need to hard code a password into the application.

[Vluf]

@buggy Thanks for the many suggestions and a guest user is definitely the easiest option. One question though:
How would you prevent a malicious guest user from calling a GlobalSignOut or ForgotPassword and thus potentially breaking other sessions?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sammartinez]

Resolving as there has been no traction on this issue since December and it looks like buggy was able to help with answering questions. This seemed to be more of a question and a documentation vs. a feature request