Check User Auth During Sync

Yes I found out, and unfortunately it seems like the refresh token is being ignored.

1 Like

This is pretty troublesome. So user logins are currently persisting forever when using Cognito?

2 Likes

Apparently, so long as they don’t physically log out.

1 Like

Even disabling or physically removing the user from the user-pool is not logging them out, preventing them from moving between applications, synchronizing data, or making changes. Uhh?!

So once a user has logged in, there is no way for me to prevent them accessing the applications, beyond asking them nicely to log out?

Edit:

This isn’t really a feature request; this is a massive security vulnerability when using Cognito that should be fixed.

I suppose a workaround for the time being is adding a security filter rule to all tables, to check against a user whitelist table. Although doing this will eliminate some of the benefits (e.g. delta sync).

1 Like

@praveen @Phil

We currently retain user login information in a browser cookie — this ensures that the user doesn’t have to sign too often. This is maintained for a long time (I think 60 days).

When we check app access control permissions, we are currently only checking that the user successfully signed in via that specific Cognito endpoint (but we do not check if they are still valid members). Point taken – we will add that.

The refresh token stuff is nothing to do with this. That is meant for a different kind of OAuth scenario, not the simple case we are using here.

3 Likes

Curious, how often does this happen, or what triggers this?
(I hope you’re enjoying that google life!)

1 Like

Don’t know if this is possible or not, but it would be helpful if this 60 days could be extended, or maybe as a pro account feature. My users are not great with tech, and often mess up the log in stage, so it would be great to extend this as much as possible. I realize 60 days is already a long time though. Thank you!

On the flip side, it would nice to be able to reduce this. Some organizational policies mandate that login sessions not persist beyond a certain timeframe.

Thanks for the response @praveen

1 Like

I trust in @praveen to make the right call.

Yep, maybe make it custom per app? Thank you @praveen

@Jonathon, @praveen, @Phil

Jonathon is quite right saying:
This isn’t really a feature request; this is a massive security vulnerability when using Cognito that should be fixed.

Add Google authentication provider to that, please.
is it possible to have a single click to log off everybody from an APP?
thanks.

We check access permissions every time an app is accessed in our cloud service (approximates to every sync, but also a number of other operations). For apps using whitelists, the moment you remove the user from the whitelist, that user will fail on their next sync (which could even be a background sync) and after that the app becomes unusable. For apps using domain auth and groups, it is expensive to check group membership, so we cache this membership for upto 15 mins. Which means that if you remove a user from the group that has access to the app, then within 15 mins, AppSheet will know that this change has happened, and on the next sync, that user’s app stops working. In the case of Cognito, we have not yet implemented groups at all — we’re just associating access with membership in a user pool. As Jonathon pointed out, we are checking for membership during initial access/login, but not during repeated access. We have active dev work to fix that and should be deploying it soon.
@Scott_Haaland @vinothp FYI

PS: the lifetime of a login cookie is raised in this thread. I think we could provide a knob to control that, but we have been hesitant to provide knobs that control low-level behaviors that most people don’t understand well. For every informed person who sets it intentionally, there’s usually five who set it wrong and run into trouble. So that’s where I currently stand on this – we could learn of course that this is an important issue to enough people, but so far, it does not come up much.

4 Likes

@Jonathon @Grant_Stead @MultiTech_Visions @Eso_Surveyors

Hi All, I have some good news for you. We’ve been working on fixing this issue with Cognito, and it was just released to AppSheet. Here’s what we did:

  1. The App Creator will need to provide some extra configuration for the AWS Congnito Auth setup in AppSheet. We need to get an AWS User Key ID and Secret (With AmazonCognitoReadOnly permission in AWS IAM) configured so that we can read the Congnito UserList.

  2. We will check that the app user’s auth is valid on every Sync. However, we will cache the auth status of the app user and only hit the Cognito back end after 15 minutes, otherwise, continual syncs during that 15 minute window will use the cached auth check. This should minimize the extra latency of an Auth check on every sync.

    • If the user does not have access (for example, if you remove them from the Cognito UserList), then they will receive this error message when they try to access the app (after the 15 min cache time) : “Your account xyz@xyz.com (1321237) is not authorized to access appxyz-1233213.”.
  3. If you have an App that is already created and you haven’t provided the extra Cognito Id/Secret information, AppSheet will continue to work as it did before the fix. We will just check the local auth cache and not hit the backend Cognito Auth.

  4. We will update the docs to reflect this asap.

A big shout out to engineering who jumped on this and got it fixed quickly. I hope it works for your “Remove a Terminated employee from your app” use case. Let us know if you have any questions.

Thanks,
Scott

6 Likes

Boom, get it on.
Loving the resources y’all have been putting into this product. So good!

2 Likes

Super awesome - thanks for addressing this. :slight_smile:

3 Likes

Thank you so much! This is awesome :clap:

3 Likes

I made the appropriate updates to the auth domain in my AppSheet account, created the role in AWS IAM; and updated the Cognito user pool. Pretty simple process assuming I did it all correctly!

Doesn’t appear to work in my apps yet, but I suspect that the change has yet to propogate to my account.

2 Likes

Thanks Jonathon for the feedback. I can have engineering check to see if your account is updated, but I suspect that if you saw the extra id/secret configs in the Cognito setup screen, then it should be there already. Can you send your account info to me in a DM.

Can you let us know how you are running your test, step by step, and we can try to reproduce it?

Thanks!
Scott

2 Likes

Looks like I jumped to the wrong conclusion then. The change is working!

I was testing on an account which was also explicitly whitelisted in the app definition… :sweat_smile:

3 Likes