With AWS Cognito doing its thing with authentication does this mean I no longer need a traditional 'users' table in my database?
Currently the app I have inherited has the traditional 'users' table I reference with sql queries looking for many-to-many and many-to-one joins with organisation, message boards, etc tables.
Do I query the Cognito user groups (that feels wrong) or is there some 'sync' method to have an updated 'users' table in my database.
Reading to docs and watching a few tutorials is great but no one seams to do more than authenticate. Where is the authorisation, and getting user names, email with join queries.
Be gentle, trying to work and study with a new baby in the room
Amazon Cognito organizes user profile data into datasets. Each dataset can contain up to 1MB of data in the form of key-value pairs. A dataset is the most granular entity that you can synchronize. Read and write operations performed on a dataset only affect the local store until the synchronize method is invoked.
You can programmatically create a data set associated with Cognito Identity and start saving data in the form of key/value pairs. The data is stored both locally on the device and in the Cognito sync store. Cognito can also sync this data across all of the end user's devices.
With a user pool, your app users can sign in through the user pool or federate through a third-party identity provider (IdP). Identity pools are for authorization (access control). You can use identity pools to create unique identities for users and give them access to other AWS services.
The two main components of Amazon Cognito are user pools and identity pools. User pools are user directories that provide sign-up and sign-in options for your app users. Identity pools enable you to grant your users access to other AWS services. You can use identity pools and user pools separately or together.
My experience has been it does not obsolete the need for a users table, for a couple of reasons.
The design I ended up on was to set a post-confirmation trigger on the Cognito user pool and have it copy all the user data into a relational database or DynamoDB when a user signed up. The primary key of the users table would be the Cognito username so if necessary I could lookup the user in both the database and Cognito. Basically I just use Cognito for authentication and not as a primary user database
You can certainly use Cognito User Pools service to manage authentication instead of your 'user' table, but not necessarily. You can also integrate other identity providers and login with Twitter, Amazon, etc, or even your own database. A benefit of using Cognito User Pools is that you don't have to code the authentication flows, as they are implemented by the service correctly and securely.
Best of luck with the code and the baby!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With