We are developing a Saas application on AWS and were looking for ways to store application user login credentials on AWS. User volume will grow quite a lot and would be in thousands presumably. I looked at IAM too but looks like it has a limit of 5000 user profiles whcih we might exhaust down the line.
I dont want to store these on RDS in even a hashed form.
Thanks!!
IAM is for your AWS account users, not for your application users. It sounds like Cognito might be what you're looking for.
Amazon Cognito lets you easily add user sign-up and sign-in to your mobile and web apps. With Amazon Cognito, you also have the options to authenticate users through social identity providers such as Facebook, Twitter, or Amazon, with SAML identity solutions, or by using your own identity system
You can use AWS Cognito user pools to save your application users. It will allow your web/mobile app users to sign up and sign in.
Have a look at this
Related
I'm developing a mobile app that must access some AWS resources, so it needs authentication to AWS endpoint. The app doesn't manage users (sign-in, sign-out, register and so on).
My first solution was to create a IAM user dedicated to the mobile app and embed its credentials in the mobile app code. The app authenticate itself to AWS using the embedded credentials. It works, however AWS suggests to avoid embedding credentials directly in the app.
I think a better solution is Cognito. Because I don't need users management, I should use unauthenticated (guest) identity to request temporary AWS credentials.
However I don't understand why a guest Cognito identity is more secure than an embedded credentials. The mobile app receive a temporary AWS credentials by sending a Cognito Identity Pool ID, that is a long-term "number" embedded in the mobile app. If someone is able to find this Identity Pool ID, she can receive AWS credentials and access AWS resources as my official mobile app. It seems there's no difference between embedded AWS long-term credentials and huest Cognito access.
Why Cognito solution is better than embedded AWS credentials?
If you are creating unauthenticated access using identity pool, you are allowing public to access your AWS resources. Make sure you write your policy carefully and it won't matter if you use a single IAM user or cognito unauthenticated access as far as security is concerned.
Using federated identity will provide you benefits like getting statistics on usage and adding triggers to events. Also keep in mind that creating a single IAM user and then allowing multiple people to use these credentials is a "hack" way of doing what cognito federated unauthenticated idenity was designed to do. You might run into unexpected complications later if AWS decides to throttle this behavior of IAM.
I have an authentication service currently integrated with CA layer 7 API Gateway. When user presents username/password to L7, it forwards the call to the auth-service, which returns JWT and session id if credentials are valid.
I am looking to integrate this auth service with AWS API gateway through cognito federated identities. I am not clear on how to integrate this set up and migrate the existing users to the user pools. I am looking for an option to eliminate the need of saving credentials in internal database. Is it possible once I migrate the users to user pools? Also, what all the features my auth-service should be able to support as added to federated identities.
It would be really helpful if you could share the relevant implementation samples.
You can import users into the cognito user pool. This will transfer all information except for the password. All users will need to create a new password when they try to log in for the first time.
If you don't want to use user pools you can just add your current authentication as a federated identity provider.
I think you should stick to just using federated identity unless you are not satisfied with your authentication app since cognito user pool requires passwords. It will be far simpler to just created a federated identity pool and configure your app with it.
It has come to my attention that recently AWS added support for federated social providers to authenticate into user pools:
AWS cognito: sign in with usernam/password OR facebook (the last answer seems to be from someone over at AWS)
This is extremely useful as now I can have all my users under one directory. My question is if I set up federation to login to user pools and generate the sample app from mobile hub will it have the functionality I am looking for? Or do I need to code it myself? As it stands in the mobile hub there are no options to generate a user pool with federation from a social identity provider.
AWS MobileHub currently doesn't support the functionality of authenticating federated social providers into user pools. Please let us know if you have any further questions. Regards, Nidhi
I want to integrate a pretty standard functionality: give option to user (mobile and web) to either login with email/password or with facebook (google) account with RBAC (different users may have different roles, like users, moderators, admins, creators, etc). Here is basically what I want from sign in:
I went through a number of AWS tutorials and other materials. I got some grasp on how to implement it, but I still don't have a full picture. Hope someone can help me here.
Here is my current understanding (please correct me where I'm wrong).
1) For the email/password signup/signin I use a User Pool. When user signs-in I call authenticateUser (I'm using JS SDK):
cognitoUser.authenticateUser(authenticationDetails, {
..
})
where onSuccess
I store identity, access and refresh tokens, so, user
doesn't have to enter his credentials every time
Because users will be accessing AWS servicess (e.g. S3) I exchange idToken to AWS credentials
Store AWS creds in LocalStore for further use, when access resources
2) For the facebook sign-in I use Federated Identity
get a facebook access token
with fb token get a cognito identity
exchange a cognito identity to AWS creds and store those in LocalStore
Questions:
Q1. Is it valid and fairly complete logic for sign-up/sign-in? Did I miss anything?
Q2. How should I store facebook users? Can I do it in User Pools? I have impression that it's not possible, but that means I have 2 different user directories: one in UserPool and another one in another place (lets say in DynamoDB)
Q3. If I have to store users in different places (UserPool and DynamoDB) that means I have 2 users for essentially one user, who first registered with email/password and then decided to use facebook - this is inconvenience for both me as app admin and user. How to deal with this situation?
Q4. How to manage groups for users, who signed-in with facebook token (like users, moderators, admins, creators, etc)?
Q5. How should I restrict access to resources other than AWS for facebook signed-in users?
Q6. Any working example for this?
Thanks!
We added support for Federation through Facebook, Google and LoginWithAmazon for User Pools. This will create a user in user pool when a user logs in with federation. You can also capture the attributes from the identity provider using the attribute mapping feature.
Also if you use the app integration feature, Amazon Cognito User Pools wil generate a sign-in page like this for you.
Steps to SignIn/SignUp with a social provider through Amazon Cognito Console:
Configure a domain for your user pool like .auth..amazoncognito.com
Add any social provider and configure attribute mapping.
Enable the provider on the App Client.
Configure the callback URI, OAuth response type and allowed scopes.
Access your hosted UI at https://.auth..amazoncognito.com/login?client_id=&response_type=&redirect_uri=
Click on the button to SignUp/SignIn with Facebook (or your provider).
Authenticate with the provider, you will be redirected to the callback URI with tokens/code.
Check the newly created user in Amazon Cognito console.
I'm human and may have missed something, but that sounds pretty good to me.
You can't store a federated identities login in user pools. Thing of user pools as another identity provider, just like Facebook is. Dynamo (or something else) would be the way to go.
If a user logged in with both, linking those logins, you might want to consider avoiding user pools attributes entirely and only using dynamo. With two logins linked, Cognito federated identities only requires one login token to proceed, but user pools requires it's login token to see/update attributes. The user would have to login with the user pool to touch those attributes, it'd get messy.
I don't know that this is supported out of the box, like it is with user pools. You might have to do this using your hypothetical user database described above.
You can also link your user pool to Cognito as a provider, much like you do for Facebook. That's how you exchange an id token for credentials.
No official example from the service, though I can't speak for others.
I am planning to write a mobile app with AWS handling the backend work. Like many common apps, mine will support user registration and login. All backend resources should be secure based on the user's role.
After reading AWS Cognito, it handles both Open authentication provider and Developer Authentication provider. This helps to support third party login. The capacity of syncing data is a big plus.
However, I have some questions about Cognito when I try further implementation.
What are the user credentials stored?
I need to add more user attributes (eg. email, profile image etc.) when a new user is created. Can Cognito handle this? Or do I need to use storage like S3 to store the entire user profile?
Does Cognito support email verification for user registration?
Does Cognito handle 'forgot password' feature?
All advices are welcomed.
There is now Amazon Cognito User Pools (currently in beta), allowing to store user credentials, see here
Update: Cognito has since added a new feature that does allow storing credentials. See Cognito User Pools for more information.
Amazon Cognito does not store credentials. Instead, it allows you to offload the task of securely storing credentials to any OpenID Connect-complaint credential provider such as, but not limited to, Facebook, Google, and Login With Amazon.
If you have a credential provider that is not OpenID Connect compliant, you can use the Developer Authenticated Identities capability to leverage another authentication system as a credential store (such as your own back-end service). Registration, email verification, and forgot password features would be handled by the Identity Provider: Either an OpenID Connect provider (e.g. Facebook) or your own provider via Developer Authenticated Identities.
Cognito's Sync capability gives you the ability to store profile information or any other information specific to the current user (referred to as "identity" in Cognito). There is a good blog post about using Cognito Sync to store & synchronize data here.