Chapter 4
Identity as a Service with Amazon Cognito

Identity is an essential concept in most applications. Any software that collects data from users must have some way to organize, access, and secure that data. In a traditional web app, the application server often manages identity through the use of browser cookies. Because of the rules that browsers enforce, cookies from different origins^[39] are not shared. This means that if you have an application server that manages identity tokens using cookies, then all your other web services must share the same origin in order to access that cookie and authenticate the request.

However, if you treat identity management as just another web service, you can separate a lot of these concerns. Security credentials managed at the application layer (in JavaScript) don’t have to worry about the same origin policy. That means you can use a wide array of services directly from the browser, without an intermediary holding all the keys and acting as a proxy.

With a serverless app, you can shift responsibility for managing identity to a third-party web service…along with all of the headaches and risks that go with it. Having a secure web service that can manage identities and provide authorization for other web services completely changes the way we can build web applications. One such identity management service is Amazon Cognito.

Amazon’s Cognito service allows us to manage identity through identity federation. This means that we can use identities from a variety of identity providers (such as Google, Facebook, or even our own app) and link them with a single identity record provided by Cognito. Cognito stores these records in what it calls an identity pool. Amazon’s IAM console lets us define policies that grant users in this identity pool access to any of Amazon’s web services based on a number of different criteria. This allows our application to make requests on behalf of an authenticated user—right from the browser—without having to route our requests through an application server. Authorization then becomes a concern of the infrastructure, rather than of the app.

With a traditional web application, identity information like this would normally be stored in the database. You’d have a table of users, and you’d probably use the primary key from the rows in that table to join with records in other tables. If you know what you’re doing, this record would include properly salted and hashed passwords. If the phrase “properly salted and hashed” sounds like directions out of a cookbook to you, then Cognito is your godsend. Instead of managing our own user records, we’ll use the identifier that Cognito creates, and we’ll include it in any records we write to the database. By using Cognito, we can not only avoid having to manage all of that infrastructure, but we’ll also avoid the security concerns inherent in managing other people’s passwords.

In this chapter, we’ll see how to manage identity without requiring an application server that holds all the keys. To enable social logins to our app, we’ll create an identity pool to act as a repository for our user identities. We’ll connect our app with third-party identity providers such as Google and Facebook. Then we’ll create profiles that will let our app directly access any Amazon web service right from the browser. After that, we’ll be able to take the next step: storing user data in a database.