A version of this article originally appeared on TechTarget Search AWS as AWS Cognito makes a mark in mobile app development
A major challenge when developing applications in the post-PC era, where the average person uses three devices and expects to access and have a consistent view of their data from each one of them, is the difficulty of keeping user identities, application settings and user state synchronized. Compounding the problem is the fact that each device may be running a different OS, multiplying the work for developers. The salvation is constant connectivity that allows apps to almost always rely on backend services. This makes the cloud a natural spot to unify the user experience. Mobile devices in particular are prime candidates for cloud backends given their limited local storage and (at least until recently) CPU resources: running an SQL database on your iPhone is not recommended.
AWS recognized the opportunity in mobile backends as a service (MBaaS) and has gradually built a compelling portfolio of mobile services that includes remote compute (Lambda), push notifications (SNS), database and storage (DynamoDB and S3), API management (API Gateway), data streaming (Kinesis), Mobile Analytics and user identity and data synchronization (Cognito). Cognito is arguably the lynchpin to all of these mobile services since identity and state management are critical to providing a consistent app experience across platforms.
Cognito Foundation: Identity and Credentials Management
Managing credentials on mobile devices is difficult since unlike a PC or server the OS doesn’t support local user accounts. Even native OS features like backup and find-my-phone rely upon a cloud login and backend services. Apps that eschew cloud authentication and embed credentials within the executable risk exposure via disassemblers like Hopper (Linux, iOS) and APK Studio (Android). But the rise of federated identity protocols like OpenID and OAuth and their wide-scale adoption by major services like Facebook, Google, Twitter and Amazon itself mean that most users already have online credentials that can be used for application authentication and data access, credentials that Cognito can exploit.
Cognito eliminates the need for embedded API tokens by providing a key-based system for authenticating users and sharing credentials over a secure backend. Cognito issues public/private keys, i.e. AWS access keys and secret keys, for each user and establishes a secure transmission channel to the backend service. Credentials expire after a short time meaning that even should a malicious attacker grab the keys, they won’t be usable for very long. Credentials also have limited access rights as defined by the identity pool in the Cognito management console. Furthermore, permissions granted to unauthenticated guests can be different than those given to authenticated users. In sum, the foundation of Cognito is user identity management: user authentication, secure credential management (getting them onto a device, limiting their lifetime and enforcing key rotation) and security enablement linking credentials to policies that control user access to online resources.
Cognito follows a hierarchical model for user identity. The apex is the developer AWS account providing access to Cognito and other AWS services. Within the Cognito service, the next layer is an identity pool, essentially a list of applications, each with their own ID and credentials. Within the identity pool is a set of individual identities for user and device accounts. Each of those identities can then have zero or more logins associated with it. Users with no logins are granted guest privileges, but why would a user have more than one?
Since people not only use many different devices, but have multiple identities with popular online platforms, why make them create another login just to access your app? Cognito doesn’t. If an app supports multiple identity providers, say Google, Facebook and Amazon, Cognito can bind these into a single identity meaning a user can authenticate with any one of them and see the same account and data. Besides brokering identities, Cognito allows apps to do their own authentication. Developers can register and authenticate users via an existing authentication process, while using Cognito to synchronize user data and access AWS resources. In sum, Cognito authentication is a multi-step process that results with a secure token on the device.
Cloud Sync Too
Data synchronization is the other major Cognito feature, with a service and client APIs that synchronize user data across mobile devices and Web apps. For example, game developer Concrete Software uses Cognito to save user data and sync game state across multi-platform devices while using one or more of a gamer’s existing online logins (Facebook, Google, etc.).
Like most cloud file and sync services, Cognito locally caches data should a device be temporarily offline, automatically synchronizing with the AWS backend when a connection is re-established. Cognito saves users data in key-value pairs with apps always writing to the local cache, which the service replicates to a master backend database. Synchronized datasets are capped at 1 MB, however each user identity can be associated with up to 20 datasets. Synchronization can be initiated via an API call or automatic push, which notifies every instance whenever data changes. In the case of conflicts, the last write wins: Cognito first reads changes from the cloud database and then writes local changes to the cloud, however the default behavior can be overridden with custom code.
In sum, Cognito provides secure identity management and data synchronization that gives users a consistent profile and view of data across all devices and logins. It works with many existing authentication systems and includes sample code for both major mobile platforms and Web applications.