Category: Amazon Cognito

One of the challenges in building applications has been around user authentication and management.  Let’s face it, not many developers want to build yet another user identification and authentication system for their application nor would they want to cause a user to create yet another account unless needed.  Amazon Cognito makes it simpler for developers to manage user identities, authentication, and permissions in order to access their applications’ data and back end systems.  Now, if only there were a service feature to make it even easier for developers to assign different permissions to different users of their applications.

Today we are excited to announce Cognito User Pools support for groups and Cognito Federated Identities support for fine-grained Role-Based Access Control (RBAC).  With Groups support in Cognito, developers can easily customize users’ app experience by creating groups which represent different user types and app usage permissions.  Developers have the ability to add users and remove users from groups and manage group permissions for sets of users.

Speaking of permissions, support for fine-grained Role-Based Access Control (RBAC) in Cognito Federated Identities allows developers to now assign different IAM roles to different authenticated users.  Previously, Amazon Cognito only supported one IAM role for all authenticated users.  With fine-grained RBAC, a developer can map federated users to different IAM roles; this functionality is available for both user authentication using existing identity providers like Facebook or Active Directory and using Cognito User Pools.

Groups in Cognito User Pools

The best way to examine the new Cognito group feature is take a walkthrough of creating a new group in the Amazon Cognito console and adding users to the different group types.

After selecting my user pool, TestAppPool, I see the updated menu item; Users and groups.  Upon selection of the menu option, a panel is presented with tabs for both User and Groups.  To create my new group, I select the Create group button.

A dialog box will open to allow for the creation of my group.  Here I will create a group for admin users named AdminGroup.  I will fill in the name for the group, provide a description for the group, and setting the order of precedence the group is ready to be created.  Note that setting the numerical precedence a group determine which group permission is prioritized and therefore utilized for users that have been assigned to multiple groups.  The lower the numerical precedence the higher the prioritization of the group to be used by the user.  Since this is my AdminGroup, I will give this group the precedence of zero (0).  After I click the Create group button, I have successfully created my user pool group.

Now all that is left to do is add my user(s) to the group. In my test app pool, I have two (2) users; TestAdminUser and TestUnregisteredUser as shown below. I will add my TestAdminUser to my newly created group.

To add my user to the AdminGroup user pool group, I simply go into the Groups tab and select my AdminGroup.  Once the AdminGroup details screen is shown, a click of the Add users button will bring up a dialog box displaying users within my user pool.  Adding a user to this group is a straightforward process, which only requires me to selecting the plus symbol next to the username desired to be added.  Once I receive the confirmation that the user has been added to the group, the process is complete.

As you can see from the walkthrough is easy for a developer to create groups in user pools. Groups can be created and managed groups in a user pool from the AWS management console, the APIs, and the CLI. As a developer you can create, read, update, delete, and list the groups for a user pool using AWS Credentials. Each user pool can contain up to 25 groups.  Additionally, you can add users and remove users from groups within a user pool, and you can use groups to control permissions to access your resources in AWS by assigning an AWS IAM roles for the groups.  You can also use Amazon Cognito combined with Amazon API Gateway to control permissions to your own back end resources.

Fine-grained Role-Based Access Control in Cognito Federated Identities

Let’s now dig into the Cognito Federated Identities’ feature, fine-grained Role-Based Access Control, which we will refer to going forward as RBAC. Before we dive into to RBAC, let do a quick review of features of Cognito Federated Identities.  Cognito Identity assigns users a set of temporary, limited privilege credentials to access the AWS resources from your application without having to use AWS account credentials. The permissions for each user are controlled through AWS IAM roles that you create.

At this point let’s journey into RBAC by doing another walkthrough in the management console.  Once in the console and selected the Cognito service, we will now select Federated Identities.  I think it would be best to show Cognito user pools and Federated Identities in action while examining RBAC, so I am going to create a new identity pool that utilizes Cognito user pools as its authentication provider.  To create a new pool, I will first enter a name for my identity pool and select the Enable access to unauthenticated identities checkbox.  Then under Authentication Providers, I will select the Cognito tab so that I can enter my TestAppPool user pool ID and the app client ID.  Please note, that you must have created an app (app client) within your Cognito user pool in order to obtain the app client ID and to allow the app leveraging the Cognito identity pool to access the associated user pool.

Now that we have created our identity pool, let’s assign role-based access for the Cognito user pool authentication method.  The simplest way to assign different roles is by defining rules in a Cognito identity pool.  Each rule specifies a user attribute or as noted in the console, a claim.  A claim is simply a value in a token for that attribute that will be matched by the rule and associated to a specific IAM role.

In order to truly show the benefit of RBAC, I will need a role for our Test App that gives users that are in the Engineering department access to put objects in S3 and access DynamoDB.  In order to create this role, I first have to create a policy with PutObject access to S3 and GetItem, Query, Scan, and BatchGetItem access to DynamoDB. Let’s call this policy, TestAppEngineerPolicy.  After constructing the aforementioned policy, I will create an IAM role named, EngineersRole, which will leverage this policy.

At this point we have a role with fine grained access to AWS resources, so let’s return to our Cognito identity pool.  Click Edit identity pool and drop down the section for Authentication providers.  Since the authentication provider for our identity pool is a Cognito user pool, we will select the Cognito tab.  Since we are establishing fine-grained RBAC for the federated identity, I will focus my attention to the Authenticated role selection section of the Authentication provider to define a rule.  In this section, click the drop down and select the option Choose role with rules.

We will now setup rule with a claim (an attribute), a value to match, and the specific IAM role, EngineersRole.. For our example, the rule I am creating will assign our specific IAM role, i.e. EngineersRole, to any users authenticated in our Cognito user pool with a department attribute set as ‘Engineering’. Please note: The department attribute that we are basing our rule on, is a custom attribute that I created in our user pool, TestAppPool, as shown in graphic below.

Now that we have that cleared up, let’s focus back on the creation of our rule.  For the claim, I will type the aforementioned custom attribute, department.  This rule will be applicable when the value of department is equal to the string “Engineering”, therefore, in the Match Type field I will select the Equals match type.  Finally, I will type the actual string value, “Engineering”, for the attribute value that should be matched in the rule.  If a user has a matching value for the department attribute, they can assume the EngineersRole IAM role when they get credentials. After completing this and clicking the Save Changes button, I have successfully created rule that allows for users that are authenticated with our Cognito user pool who are in the Engineering department to have different permissions than other authenticated users using the application.

Since we’ve completed our walkthrough of setting up a rule to assign different roles in a Cognito identity pool, let us discuss some key points to remember about fine-grained RBAC.  Firstly, rules are defined with an order and the IAM role for the first matching rule will be applied. Secondly to set up RBAC, you can define rules or leverage the roles passed via the ID token that was assigned by the user pool. For each authentication provider configured in your identity pool, there is a maximum of a total of 25 rules that can be created. Additionally, user permissions are controlled via AWS IAM roles that you create.

Pricing and Availability

Developers can get started right away to take advantage of these exciting new features.  Learn more about these new features and the other benefits of leveraging the Amazon Cognito service by visiting our developer resources page.

Great news is that there is no additional cost for using groups within a user pool. You pay only for Monthly Active Users (MAUs) after the free tier. Also remember that using the Cognito Federated Identities feature for controlling user permissions and generating unique identifiers is always free with Amazon Cognito.  See the Amazon Cognito pricing page for more information.

– Tara

A few months ago I wrote about the new Your User Pools feature for Amazon Cognito. As I wrote at the time, you can use this feature to easily add user sign-up and sign-in to your mobile and web apps. The fully managed user directories can scale to hundreds of millions of users and you can have multiple directories per AWS account. Creating a user pool takes just a few minutes and you can decide exactly which attributes (address, email, gender, phone number, and so forth, plus custom attributes) must be entered when a new user signs up for your app or service. On the security side, you can specify the desired password strength, require the use of Multi-Factor Authentication (MFA), and verify new users via phone number or email address.

Now Generally Available
We launched Your User Pools as a public beta and received lots of great feedback. Today we are making Your User Pools generally available and we are also adding a large collection of new features:

• Device Remembering – Cognito can remember the devices that each user signs in from.
• User Search – Search for users in a user pool based on an attribute.
• Customizable Email Addresses – Control the email addresses for emails to users in your user pool.
• Attribute Permissions – Set fine-grained permissions for each user attribute.
• Custom Authentication Flow – Use new APIs and Lambda triggers to customize the sign-in flow.
• Admin Sign-in – Your app can now sign in users from backend servers or Lambda functions.
• Global Sign-out – Allow a user to sign out from all signed-in devices or browsers.
• Custom Expiration Period – Set an expiration period for refresh tokens.
• API Gateway Integration – Use user pool to authorize Amazon API Gateway requests.
• New Regions – Cognito Your User Pools are now available in additional AWS Regions.

Let’s take a closer look at each of these new features!

Device Remembering
Cognito can now remember the set of devices used by (signed in from) each user. You, as the creator of the user pool, have the option to allow your users to request this behavior. If you have enabled MFA for a user pool, you can also choose to eliminate the need for entry of an MFA code on a device that has been remembered. This simplifies and streamlines the login process on a remembered device, while still requiring entry of an MFA code for unrecognized devices. You can also list a user’s devices and allow them to sign out from a device remotely.

You can enable and customize this feature when you create a new user pool; you can also set it up for an existing pool. Here’s how you enable and customize it when you create a new user pool. First you enable the feature by clicking on Always or User Opt-in:

Then you indicate whether you would like to suppress MFA on remembered devices:

The AWS Mobile SDKs for iOS, Android, and JavaScript contain new methods that you can call from your app to remember devices.

User Search
You, as the creator of a Your User Pool, can now search for users based on a user attribute such as username, given_name, family_name, name, preferred_user_name, email, phone_number, status, or user_status.

You can do a full match or a prefix match using the AWS Management Console, the ListUsers API function, or the list-users command line tool. Here’s a Console-powered search:

Customizable Email Addresses
You can now specify the From and the Reply-To email addresses that are used to communicate with your users. Here’s how you specify the addresses when you create a new pool:

You will need to verify the From address with Amazon Simple Email Service (SES) before you can use it (read Verifying Email Addresses in Amazon SES to learn more).

Attribute Permissions
You can now set per-app read and write permissions for each user attribute. This gives you the ability to control which applications can see and/or modify each of the attributes that are stored for your users. For example, you could have a custom attribute that indicates whether a user is a paying customer or not. Your apps could see this attribute but could not modify it directly. Instead, you would update this attribute using an administrative tool or a background process. Permissions for user attributes can be set from the Console, the API, or the CLI.

Custom Authentication Flow
You can now use a pair of new API functions (InitiateAuth and RespondToAuthChallenge) and three new Lambda triggers to create your own sign-in flow or to customize the existing one. You can, for example, customize the user flows for users with different levels of experience, different locations, or different security requirements. You could require the use of a CAPTCHA for some users or for all users, as your needs dictate.

The new Lambda triggers are:

Define Auth Challenge – Invoked to initiate the custom authentication flow.

Create Auth Challenge – Invoked if a custom authentication challenge has been defined.

Verify Auth Challenge Response – Invoked to check the validity of a custom authentication challenge.

You can set up the triggers from the Console like this:

Global Sign-out
You can now give your users the option to sign out (by invalidating tokens) of all of the devices where they had been signed in. Apps can call the [GlobalSignOut] function using a valid, non-expired, non-revoked access token. Developers can remotely sign out any user by calling the [AdminUserGlobalSignOut] function using a Pool ID and a username.

Custom Expiration Period
Cognito sign-in makes use of “refresh” tokens to eliminate the need to sign in every time an application is opened. By default, the token expires after 30 days. In order to give you more control over the balance between security and convenience, you can now set a custom expiration period for the refresh tokens generated by each of your user pools.

API Gateway Integration
Cognito user pools can now work hand-in-hand with Amazon API Gateway to authorize API requests. You can configure API Gateway to accept Id tokens to authorize users based on their presence in a user pool.

To do this, you first create a Cognito User Pool Authorizer using the API Gateway Console, referencing the user pool and choosing the request header that will contain the identity token:

Navigate to the desired method and select the new Authorizer:

New Regions
As part of today’s launch we are making Cognito available in the US West (Oregon) Region.

In addition to the existing availability in the US East (Northern Virginia) Region, we are making Your User Pools available in the EU (Ireland), US West (Oregon), and Asia Pacific (Tokyo) Regions.

Available Now
These new features are available now and you can start using them today! To learn more, watch Getting Started with Your User Pools in Amazon Cognito.

— Jeff;

Amazon Cognito makes it easy for mobile and web apps to easily add authentication, user management, and data synchronization without having to write backend code or manage any infrastructure. In the last year we have added some powerful new features to Cognito including AWS CloudTrail support, the use of Twitter and Digits as login providers, the ability to run AWS Lambda functions in response to events in Cognito, and the streaming of user identity data into Amazon Kinesis.

Your User Pools
You can now use Amazon Cognito to easily add user sign-up and sign-in to your mobile and web apps. With the user pools feature, you can create your own user directory that can scale to hundreds of millions of users, and is fully managed so you don’t have to worry about the heavy lifting associated with building, securing, and scaling authentication to your apps. This feature also provides enhanced security functionality such as email verification, phone number verification, and multi-factor authentication. As an app developer, you already had the option to use an external identity provider such as Amazon, Facebook, Google, Twitter or Digits for this purpose using the Cognito feature that we now call Federated Identity Pools.

Using a user pool gives you detailed control over the sign-up and sign-in aspects of your web and mobile SaaS apps, games, and so forth. Building and running a directory service at scale (potentially tens or even hundreds of millions of users) is not easy, but is definitely undifferentiated heavy lifting, with the added security burden that comes when you are managing user names, passwords, email addresses, and other sensitive pieces of information. You don’t need to build or run your own directory service when you use Cognito Identity.

Multiple User Pools per Account
You can create multiple user pools within your AWS account (the identities in one pool are separate and distinct from those in any other pools). Each user pool is named, and you have full control over the attributes (address, email, phone number(s), locale, and so forth) that you want to store for each user. After you create a user pool, you can use the AWS Mobile SDKs (available for iOS, Android, and JavaScript) to authenticate users, get access credentials, and so forth.

Your users will benefit from a number of security features including SMS-based Multi-Factor Authentication (MFA) and account verification via phone or email. The password features use the Secure Remote Password (SRP) protocol to avoid sending cleartext passwords over the wire.

Creating a User Pool
Let’s walk through the process of creating a user pool from the AWS Management Console (API and CLI support is also available). My (hypothetical) app is called PaymentApp so I’ll create a pool named PaymentAppUsers:

I can either review and accept the defaults, or I can step through all of the settings. I’ll choose the latter course of action. Now I choose the set of attributes that must be collected when a new user signs up for my service:

I can also set up custom attributes. For my app, I would like to track the user’s preferred payment currency:

Then I set up the desired password strength. Since this is payment app, I’ll check all of the options:

Next, I enable Multi-Factor Authentication, and indicate that email addresses and phone numbers must be verified. I also customize the messages that are associated with each method of verification:

My app will have a mobile client so I’ll arrange to create a unique ID and a secret key for it:

Now I can arrange to have Cognito invoke some Lambda functions during the sign-up, verification, authentication, and confirmation steps (this is optional, but very useful if you want to customize the sign-up workflow by validating custom attributes):

Finally, I review my choices and create my pool:

At this point I am ready to build my web or mobile app.

Cognito at Asurion
Asurion provides over 200 million customers with insurance policies for high-value devices such as smartphones. Asurion plans to use Cognito to manage the user directory for their new device protection app. This app will collect device-related data and make recommendations that are aimed at optimizing usage.

Asurion chose Cognito due to its support for a wide variety of identity models. They can have their own fully managed directory or they can have users authenticate through third-party social identity providers without having to deal with the heavy lifting involved in scaling and security an identity system.

Ravi Tiyyagura (Asurion’s Director of Enterprise Architecture) told us:

It is critical for us to provide a secure and simple sign-up and sign-in experience for our tens of millions of end users. With Amazon Cognito, we can enable that without having to worry about building and managing any backend infrastructure.

Public Beta
We are launching user pools today as a public beta. All of the primary functionality is in place and you can use it to start building and testing your app. We expect to make it available for production use within a couple of months.

— Jeff;

Amazon Cognito makes it easy for you to save user data such as app preferences in the AWS Cloud without writing any backend logic or managing any infrastructure. You can focus on creating a great app instead of worrying about creating server-side code to handle identity management, network state, storage, and sync.

Today we are giving you the ability to receive events (in the form of a Amazon Kinesis stream) when data managed by Cognito is updated or synchronized. You can use this stream to monitor user and app activity in real time. You can also route the event information to Amazon Redshift and analyze it using SQL queries or a wide selection of Business Intelligence (BI) tools.

To learn more about this feature, take a look at Announcing Amazon Cognito Streams on the AWS Mobile Development Blog.

— Jeff;

We’ve made some important updates to Amazon Cognito! As you may already know, this service makes it easy for you to save user data such as app preferences or game state in the AWS cloud without writing any backend code or managing any infrastructure.

Here’s what’s new:

1. Developer-oriented access to the sync store.
2. Updated AWS console interface for developers.
3. Identity pools role association.
4. Simplified SDK initialization.

Let’s dive in!

Developer-Oriented Access to the Sync Store
The Cognito sync store lets you save end-user data in key-value pairs. The data is associated with a Cognito identity so that it can be accessed across logins and devices.  The Cognito Sync client (available in the AWS Mobile SDK) uses temporary AWS credentials vended by the Security Token Service. The credentials give the client the ability to access and modify the data associated with a single Cognito identity.

This level of access is perfect for client apps, since they are operating on behalf of a single user. It is, however, insufficiently permissive for certain interesting use cases. For example, game developers have told us that they would like to run backend processes to award certain users special prizes by modifying the data in the user’s Cognito profile.

To enable this use case, we are introducing developer-oriented access to the Cognito sync store. Developers can now use their AWS credentials (including IAM user credentials) to gain read and write access to all identities in the sync store.

The detailed post on the AWS Mobile Development Blog contains sample code that shows you how to make use of this new feature.

Updated AWS Console Interface
On a related note, the AWS Management Console now allows you to view and search (by Identity ID) all of the identities associated with any of your Cognito identity pools:

You can also view and edit their profile data from within the Console:

Identity Pool Role Association
The updated console also simplifies the creation of IAM roles that are configured to access a particular identity pool. Simply choose Create a new IAM Role when you create a new identity pool (you can click on View Policy Document if you would like to see how the role will be configured):

Cognito saves the selected roles and associates them with the pool. This gives Cognito the information that it needs to have in order to be able to show you the “Getting Started” code at any time:

Even better, it also simplifies SDK initialization!

Simplified SDK Initialization
Because Cognito now saves the roles associated with a pool, you can now initialize the SDK without passing the ARNs for the role. Cognito will automatically use the roles associated with the pool. This simplifies the initialization process and also allows Cognito to call STS on your behalf, avoid an additional network call from the device in the process.

Available Now
These new features are available now and you can start using them today! Read the Cognito documentation to learn more and to see how to get started.

— Jeff;

This past summer, we launched Cognito to simplify the task of authenticating users and storing, managing, and syncing their data across multiple devices. Cognito already supports a variety of identities — public provider identities (Facebook, Google, and Amazon), guest user identities, and recently announced developer authenticated identities.

Today we are making Amazon Cognito even more flexible by enabling app developers to use identities from any provider that supports OpenID Connect (OIDC). For example, you can write AWS-powered apps that allow users to sign in using their user name and password from Salesforce or Ping Federate. OIDC is an open standard enables developers to leverage additional identity providers for authentication. This way they can focus on developing their app rather than dealing with user names and passwords.

Today’s launch adds OIDC provider identities to the list. Cognito takes the ID token that you obtain from the OIDC identity provider and uses it to manufacture unique Cognito IDs for each person who uses your app. You can use this identifier to save and synchronize user data across devices and to retrieve temporary, limited-privilege AWS credentials through the AWS Security Token Service.

Building upon the support for SAML (Security Assertion Markup Language) that we launched last year, we hope that today’s addition of support for OIDC demonstrates our commitment to open standards. To learn more and to see some sample code, see our new post, Building an App using Amazon Cognito and an OpenID Connect Identity Provider on the AWS Security Blog. If you are planning to attend Internet Identity Workshop next week, come meet the members of the team that added this support!

— Jeff;

Amazon Cognito, as you may already know, simplifies the task of authenticating users and storing, managing, and syncing their data across multiple devices. We launched Cognito this past summer with support for three public identity providers. The identity providers (Google, Facebook, and Amazon) are used to create unique Cognito identifiers (there’s also support for unauthenticated guest users). This allows new users to start using your app without taking the time to register a new identity. You can read my blog post, New AWS Mobile Services, to learn more about Cognito and its role as an identity provider.

Enhanced Identity Support
Today we are making Cognito even more flexible by allowing you to make use of the user identity system of your choice. You can use this feature to allow your users to create an identity that is separate and distinct from their existing social identity.

With today’s launch, Cognito takes an identifier that you supply and uses it to manufacture unique Cognito IDs for each person who uses your app. You can use this identifier to save and synchronize user data across devices and to retrieve temporary, limited-privilege AWS credentials through the AWS Security Token Service.

To use this new facility, you must first implement a backend identity provider of your own. Then you call the new GetOpenIdTokenForDeveloperIdentity function and supply it with the name of your identity pool. The function will return a unique Cognito ID and an OpenID connect token. To learn more about how to do this and to see some sample code, read the post Amazon Cognito: Announcing Developer Authenticated Identities on the AWS Mobile Development Blog.

— Jeff;

The Mobile App Development Challenge
We want to make it easier for you to build sophisticated cloud-powered applications for mobile devices! User expectations are at an all-time high: they want to run your app on the device of their choice, they want it to be fast and efficient, and they want it to be secure. Here are some of the challenges that you will face as you strive to meet these expectations:

• Authenticate Users – Manage users and identity providers.
• Authorize Access – Securely access cloud resources.
• Synchronize Data – Sync user preferences across devices.
• Analyze User Behavior – Track active users and engagement.
• Manage Media – Store and share user-generated photos and other media items.
• Deliver Media – Automatically detect mobile devices and deliver content quickly on a global basis.
• Send Push Notifications – Keep users active by sending messages reliably.
• Store Shared Data – Store and query NoSQL data across users and devices.
• Stream Real-Time Data – Collect real-time clickstream logs and react quickly.

Meeting the Challenge
Today we are introducing three new AWS products and services to help you to meet these challenges.

Amazon Cognito simplifies the task of authenticating users and storing, managing, and syncing their data across multiple devices, platforms, and applications. It works online or offline, and allows you to securely save user-specific data such as application preferences and game state. Cognito works with multiple existing identity providers and also supports unauthenticated guest users.

Amazon Mobile Analytics will help you to collect, visualize, and understand app usage, engagement, and revenue at scale. Analytics can be collected via the AWS Mobile SDK or a set of REST APIs. Metrics are available through a series of reporting tabs in the AWS Management Console.

The updated and enhanced AWS Mobile SDK is designed to help you build high quality mobile apps quickly and easily. It provides access to services specifically designed for building mobile apps, mobile-optimized connectors to popular AWS data streaming, storage and database services, and access to a full array of other AWS services. This SDK also includes a common authentication mechanism that works across all of the AWS services, client-side data caching, and intelligent conflict resolution. The SDK can be used to build apps for devices that run iOS, Android, and Fire OS.

Taken as a whole, these services will help you to build, ship, run, monitor, optimize, and scale your next-generation mobile applications for use on iOS, Android, and Fire OS devices. The services are part of the full lineup of AWS compute, storage, database, networking, and analytics services, which are available to you and your users from AWS Regions location in the United States, South America, Europe, and Asia Pacific.

Here is how the new and existing AWS services map to the challenges that I called out earlier:

• Authenticate Users – Amazon Cognito (Identity Broker)
• Authorize Access – AWS Identity and Access Management (IAM)
• Synchronize Data – Amazon Cognito (Sync)
• Analyze User Behavior – Amazon Mobile Analytics
• Manage Media – Amazon Simple Storage Service (S3) Transfer Manager
• Deliver Media – Amazon CloudFront (Device Detection)
• Send Push Notifications – Amazon Simple Notification Service (SNS) Mobile Push
• Store Shared Data – Amazon DynamoDB (Object Mapper)
• Stream Real-Time Data – Amazon Kinesis (Kinesis Recorder)

Let’s take a closer look at each of the new services!

Amazon Cognito
Amazon Cognito helps you identify unique users, retrieve temporary, limited-privilege AWS credentials and also offers data synchronization services.

As you might know, an Identity Provider is an online service that is responsible for issuing identification information for users that would like to interact with the service or with other cooperating services. Cognito is designed to interact with three major identity providers (Amazon, Facebook, and Google). You can take advantage of the identification and authorization features provided by these services instead of having to build and maintain your own. You no longer have to worry about recognizing users or storing and securing passwords when you use Cognito.

Cognito also supports guest user access. In conjunction with AWS Identity and Access Management (IAM) and with the aid of the AWS Security Token Service, mobile users can securely access AWS resources and app features, and even save data to the cloud without having to create an account or log in. However, if they choose to do this later, Cognito will merge data and identification information if the user ultimately decides to log in. Here’s how it all fits together:

Here’s what you need to do to get started with Cognito:

1. Sign up for an AWS Account.
2. Register your app on the identity provider’s console and get the app ID or token. This is an optional step; you can also choose to use only unauthenticated identities
3. Create a Cognito identity pool in the Management Console.
4. Integrate the AWS Mobile SDK; store and sync data in a dataset.

You can create and set up the identity pool in the Console:

Once your application is published and in production, you can return to the Console and view the metrics related to the pool:

Let’s talk about Cognito’s data synchronization facility! The client SDK manages a local SQLite store so that the application can work even when it is not connected. The store functions as a cache and is the target of all read and write operations. Cognito’s sync facility compares the local version of the data to the cloud version, and pushes up or pulls down deltas as needed. By default, Cognito assumes that the last write wins. You can override this and implement your own conflict resolution algorithm if you’d like. There is a small charge for each sync operation.

Each identity within a particular identity pool can store multiple datasets, each comprised of multiple key/value pairs:

Each dataset can grow to 1 MB and each identity can grow up to 20 MB.

You can create or open a dataset and add key/value pairs with a couple of lines of code:

DataSet *dataset = [syncClient openOrCreateDataSet:@"myDataSet"];
NSString *value = [dataset readStringForKey:@"myKey"];[dataset putString:@"my value" forKey:@"myKey"];

Charges for Cognito are based on the total amount of application data stored in the cloud and the number of sync operations performed on the data. The Amazon Cognito Free Tier provides you with 10 GB of sync store and 1,000,000 sync operations per month for the first 12 months of usage. Beyond that, sync store costs $0.15 per GB of storage per month and $0.15 for each 10,000 sync operations.

Take a look at the Cognito documentation (Android and iOS) to learn more about this and other features.

Mobile Analytics
Once you have built your app, you need to track usage and user engagement, improving and fine-tuning the app and the user interaction in response to user feedback. The Amazon Mobile Analytics service will give you the information and the insights that you need to have in order to do this.

Using the raw data (“events”) collected and uploaded by your application, Amazon Mobile Analytics automatically calculated and updates the following metrics:

• Daily Active Users (DAU), Monthly Active Users (MAU), and New Users
• Sticky Factor (DAU divided by MAU)
• Session Count and Average Sessions per Daily Active User
• Average Revenue per Daily Active User (ARPDAU)
• and Average Revenue per Paying Daily Active User (ARPPDAU)
• Day 1, 3, and 7 Retention
• Week 1, 2, and 3 Retention
• Custom Events

In order for your application to be able to upload events, you can create an identity pool and use the AWS Mobile SDK (or the REST API) to call the appropriate reporting functions. There are three types of events:

• System – Start or end of a session
• In-App Purchase – Transaction.
• Custom – Specific actions within your application.

When you use the AWS Mobile SDK, the system events denoting the start and end of each session are sent automatically. Your application code is responsible for sending the other types of events at the appropriate time.

All of the metrics are available from within the AWS Management Console, broken down by tab:

The main page includes plenty of top-level information about your app and your users:

You can click on a tab to learn even more:

You can also filter by application, date range, and/or platform, as needed:

Pricing is based on the number of events that your app generates each month. The first 100 million events are free; beyond that, you will be charged $1.00 for each million events.

AWS Mobile SDK
Last, but definitely not least, I would like to say a few words about the updated and expanded AWS Mobile SDK! This SDK makes it easy for you to build applications for devices that run the iOS, Android, or Fire OS operating systems.

Here are some of the new features:

Object Mapper – A new DynamoDB Object Mapper for iOS makes it easy for you to access DynamoDB from your mobile apps. It enables you to map your client-side classes to Amazon DynamoDB tables without having to write the code to transform objects into tables and vice versa. The individual object instances map to items in a table, and they enable you to perform various create, read, update, and delete (CRUD) operations on items, and to execute queries.

S3 Transfer Manager – Amazon S3 Transfer Manager makes it easy for you to upload and download files from Amazon S3 while optimizing for performance and reliability. Now you can pause, resume, and cancel file transfer using a simple API. We have rebuilt the iOS S3TransferManager to utilize BFTask. It has a clean interface, and all of the operations are now asynchronous.

Android and Fire OS Enhancements – In addition to support for the services announced in this post, the SDK now supports Amazon Kinesis Recorder for reliable recording of data streams on mobile devices, along with support for the most recent SQS, SNS, and DynamoDB features. It also allows active requests to be terminated by interrupting the proper thread.

iOS / Objective-C Enhancements – The SDK supports ARC and BFTask, and conforms to the best practices for the use of Objective-C. It also supports Cocoapods, and can be accessed from Apple’s new Swift language.

— Jeff;

PS – Special thanks to my friend and colleague Jinesh Varia for creating the screen shots and diagrams in this post!