Check User Auth During Sync

Would it be possible to pull a check on the user auth? We’re using AWS Cognito, and it would be cool to check if the user is in the pool or disabled during a sync.

Is this due to migrating someone out of a group, but the app still letting them access whatever the group was controlling access too???

Pretty much… I just figured we should at least b be able to validate before a sync

You might be able to pseudo-fix this with setting the Refresh token expiration to a lesser number. I have my set to the min (1 day), which causes users to log in every 24 hours - this would cause a re-check of their group by default.

1 Like

Umm. Where do you set that?

1 Like

Inside the details for the App Client:

https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html#amazon-cognito-user-pools-using-the-refresh-token

1 Like

Interesting, does it force them to login every day then?

I’m checking with clients now to see what their users actually report.

For me, when I log into the app, it kicks me straight in (because I’ve already logged in) - there is no login check made. Which is exactly the problem I think you are seeing.

1 Like

Did you ever find out if people were having to log in every day?

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