Have cognito setup and working and I'm using pinpoint for analytics to track user sign-ups, sign-ins. etc. the problem is I have setup pinpoint according to this doc (http://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-pinpoint-integration.html) and have connected it to the app client in cognito but I am not getting any data in pinpoint when I sign up a new user etc. Specifically when I create a new user in my webapp I confirm that the new user has indeed been created in cognito and then check pinpoint and pinpoint shows zero users have signed up.
What SDKs are you exactly using to interact with the services? If you are using any of the Javascript SDKs, you need to populate the AnalyticsMetadata https://github.com/aws/aws-sdk-js/blob/master/apis/cognito-idp-2016-04-18.normal.json#L2344 in the particular requests since the Javascript AWS frameworkds don't provide this functionality on your behalf (similar to the Android and iOS SDKs).
Related
I've built an application which is connected with Amazon Cognito to take the sign in and sign-ups of users. Currently, application support three different subscriptions (Free, Basic, Premium). If the user signs in for basic Subscriptions, I want to give them least access to DynamoDB for download the parts of applications which is required to run the application service.
How to connect DynamoDB with Cognito directly
I am not sure, what's the best approach to follow this scenario?
(Please note- this is not a mobile-based application, so do not give suggestion to use AWS Amplify or relatable services)
When I was first learning about Cognito, I had made the same set of assumptions you are currently making. I knew that User Pools could act as my application's user directory, and Identity Pools would magically unlock all my authorization needs. I was mistaken :)
At the risk of oversimplifying, AWS Cognito exists to answer two questions:
Who are you? (authentication)
What can you do? (authorization)
Cognito addresses these concerns with two distinct offerings: User Pools (authentication) and Identity Pools (authorization).
At a high level, User Pools let you handle user registration, authentication, account recovery, and supports authentication with third-party identity providers like Facebook, Google, etc. Sounds like you might have this part figured out.
Cognito Identity Pools, on the other hand, provides a way to authorize users to use various AWS services. You can think of it as a vending machine for handing out AWS credentials. For example, if you needed to give your users access to upload a file to an S3 bucket or to invoke an endpoint in API Gateway, you could do so with an Identity Pool. You can even allow item-level access to DynamoDB based on an Amazon Cognito ID. However, this might not work the way you expect since your application users are probably not directly connecting to DynamoDB.
In most web/mobile applications, users are not connecting directly to DynamoDB. Instead, they are interacting with a web/mobile app that communicates to the back-end of your application via an API. That API would then communicate with DynamoDB. If your stack is in AWS, the path may look something like this:
Client (web/mobile app) <-> API Gateway <-> Lambda <-> DynamoDB
In this architecture, your users would authenticate via Cognito. Cognito would then authorize the user to make calls to API Gateway. API Gateway would execute your lambda, which would then interact with DynamoDB. The "user" of DynamoDB in this example is your Lambda, not the user of your application.
That last bit is important, so I'll repeat it: Unless your users are directly connecting to DynamoDB (not recommended), they are not the "user" operating on DynamoDb. Therefore, restricting DynamoDB access based on a user's Cognito ID is not going to be an option for you.
So, what can you do? Your application needs to provide the business logic around what effect your users can have on DynamoDB. Perhaps free users have read-only access to a specific partition, while premium users can modify the same partition. That logic has to be handled directly by you.
I know you said you weren't looking for Amplify suggestions since your application is not mobile-based. However, Amplify offers SDKs that aren't specific to mobile development. The folks at Serverless have made a fantastic tutorial on building a full-stack serverless web app, which includes a very readable chapter on serverless auth with Cognito. They use Amplify in a web app to integrate with Cognito, S3, and API Gateway. If that's something you are trying to do, I'd recommend checking it out.
We are building an application with mobile authentication and we decided to use Aws. I searched a little and decided to use Aws Cognito. I read the documentation and while reading I noticed that, for the application side I need to use Aws Amplify. I tried some examples but I am not sure I understand the concept right.
Can you give me some insight about this model.
Amazon Cognito is a managed Identity Provider in the cloud, it provides you with a user repository, federation, GUI for signin, signup, lost password and other user flows, it supports OTP, email address verification etc ...
It can be integrated into your app through the provided UI or through its API if you want to control the look and feel of theusre interfaces.
Amplify is a command line tool and client library to make it easy to provision and to use cloud services, including Cognito, from your web or mobile application.
The Amplify CLI will help you to provision Cognito in the cloud, without requiring you to click through all the options in the console. The Amplify client side library will provide high level programming constructs to make it easy to access cloud based services, such as Cognito, from your apps.
You can watch this 45 minute talk that shows Amplify in action : https://www.youtube.com/watch?v=QxOcvOMnAuQ and this github repo with a sample application : https://github.com/sebsto/amplify-react-workshop
We are building complete serverless architecture using AWS services for all of our api's (using API Gateway + Lambda functions + DynamoDB) and to control our devices we are using aws-iot platform. Mobile to devices interaction will happen over the aws-iot. On mobile side for user management we are using firebase and all business logic is in Lambda function. Now we want to work with Alexa with our existing architecture flow, but we are confused with the account linking part. Do we have to implement our own auth server which will take care of authorization part or should we move to cognito user pool + login with Amazon, so that we will have user management and auth at the same platform.
Yes, you usually have to set up your own oAuth 2.0 if you want to do Account Linking with a user in your system. As you mentioned, there is also the possibility to use "Login with Amazon" (LWA) which makes things a little easier. However, you will only get a user's email address and name (often, this is enough).
If you don't want to set up your own oAuth server, there are also tool providers that can do user management for you, like Auth0. For example, Auth0 can be used to connect different identity providers like Facebook, Google logins, but also allows for username + password.
You can find a detailed step by step guide to set up Alexa Account Linking with Auth0 here. Let me know if you have any more questions!
The documentation states the following providers can be used for authentication Github, Facebook, Twitter, Google. I don't see how you'd be able to link in with Amazon / Alexa. Also I'm not sure why you would want to use Firebase and not AWS Cognito.
We're trying to figure out whether to create our own Parse server or migrate to AWS stack. We're looking for AWS alternative to Parse login, where it extracts user info such as email and name.
The closest one I could find is AWS Cognito, but it doesn't seem to store any user info (email/name). It seems that the only way to get them is through the developer authenticated identities, which means I have to deal with user's credentials (encrypt the user's password), handle the fb/google registration, etc.
I'm new to AWS Mobile, but I was hoping that these should be a standard feature that BaaS solution should provide. Am I missing something here? For those who uses AWS Mobile stack, how do you handle this?
Thanks!
We are using aws mobile analytics stack (sdk and export events to redshift) in our ios application and we run into the same issue you are describing. The only way we have to handle it is to ask the user to provide these details as part of the registration process.
At least in ios there is no way to get the user email and name from the os or through aws.
Currently Amazon Cognito does not support user registration. We have heard this request from multiple customers and we will consider adding this feature in future releases.
Note: If you do decide to do your own authentication using developer authenticated identities, you can use Amazon Cognito to store your user data such as email and other profile information. It also provides offline access and synchronizes data across devices for authenticated users.
Cognito User Pools does what you want (authentication, username, email all sorts of claim data).
It is integrated with Cognito Identity in a fork off of the github repository aws-mobile-hub-helper (here)
That repo contains an AWSSignInProvider for Cognito User Pools. It is also modified to support identity merging across any provider with an AWSSignInProvider implemented (Google, Cognito Your User Pools, and Facebook in that repository).
I have looked for resources on this particular problem with little luck so far so I thought I would try here.
I am attempting to create an Amazon Web Service Simple Notification Service app in the AWS-SNS console using GCM. I have created the APNS app for the iOS version with no troubles, however, when attempting to create the GCM version I receive the error: "The credentials you entered are invalid. Please enter valid credentials and try again."
In the Google APIs - API Access dashboard I have created both a key for server app and a key for android app. Below are a few screenshots to illustrate the problem.
Any suggestions as to what the problem may be or any instructional documentation recommendations would be tremendously appreciated.
More on what Rohan has said, it would be on Google's end rather than Amazon's.
Delete the Server API Key in the Google API Console, and create a new one, allowing all IP addresses. Add the new key in AWS SNS, and you should be good to go!
Amazon documentation is very old and not accurate anymore.
When you created your Application and the Credentials on Google Developers Console, from the left menu on Google developer console select:
APIs & auth -> APIs -> Google Cloud Messaging for Android -> Enable API
Google recently migrated a lot of the GCM service/credential handling to Firebase. As a result you need to create a Server Key in the Firebase Console now.
See: Amazon SNS: "Platform credentials are invalid" when re-entering a GCM API key that previously worked
You need to use the API key listed under Key for server apps (with IP locking) in the Google Console. The key listed under Android app will not work.
The Amazon SNS Getting Started with GCM documentation provides step-by-step guidance on setting up your app. If you are still having issues, please contact us via AWS Support or the Amazon SNS forum and we can troubleshoot further.
full disclosure: I am an Amazon SNS engineer.