Amazon Cognito use cases
User authentication for application access
The simplest design pattern to accommodate when using Amazon Cognito is fully externalized user account management and authentication. In this pattern, the Cognito user pool acts as the IDP and user store for the application:
Applications can take advantage of Amazon Cognito's hosted account management, sign-up, and verification process to register new user accounts in the user pool if a user does not have credentials to access the application. Once the user registers their account and sets up their credentials, the app looks to Amazon Cognito as its identity provider. Using a standards-based authentication flow, the application receives confirmation from Amazon Cognito that the user has been authenticated by being issued a signed, Amazon Cognito-provided ID token and access token.
This model can also be extended to look at external, federated identity providers for user authentication:
Under this model, the only significant difference is the option to change where the user is authenticated, as well as where their credentials are managed. The Amazon Cognito user pool may look to the locally managed accounts within its directory or to a federated provider at user authentication time; the application continues to only respect Amazon Cognito as its source of user identity. Though federated users may delegate authentication to an identity provider, they still exist as records within the user pool, and any information that's presented to the application about those users will come from Amazon Cognito using attributes from that pool.
The next model builds upon this one but adds authorization into the mix.
User authentication and authorization for access to application resources
This model is similar to the previous one, with one key exception: the application that uses Amazon Cognito for its identity provider also acts as a resource server. In addition to the user authentication and registration features, the application will also use the Amazon Cognito user pool as its authorization server in an OAuth2 pattern:
In the preceding diagram, the application looks to Amazon Cognito for user authentication, new user sign-up, and account verification. The Amazon Cognito user pool may optionally look to a federated identity provider for user authentication. However, this time, the application also needs those users to be able to access either or both of its available resources once they have been authenticated to the application. Amazon Cognito user pools can facilitate this through group assignments within its user directory. We can assign entitlements, such as members of group 1 may access resource 1, that map to scopes that Amazon Cognito (as the authorization server) and the application (as the resource server) use to limit the access that's granted by the access token that's issued at user authentication time.
With all this talk of scopes, resource servers, and authorization servers, you would think that APIs would be in the mix somewhere in this model. To be fair, they could be as resources available on the application/resource server. However, since leaving API endpoints exposed is not a security best practice, AWS recommends pairing the Amazon Cognito user pool with AWS API Gateway:
In this relationship, on top of all the previously established relationships and services between Amazon Cognito user pools and the application, we must also establish a relationship between the user pool and the Amazon API Gateway service, so that Amazon API Gateway knows that Amazon Cognito can act as an authorization server for the application APIs that it proxies. Just as in the earlier variant of this pattern, user groups within the Amazon Cognito user pool map to scopes that determine which APIs the access token is permitted to call. This pattern is very platform-specific to the AWS services that are referenced in it. The documentation on implementing it is available here: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html
The next pattern drops the Amazon API Gateway in favor of Amazon Cognito identity pools.
User authentication and access to AWS services exposed through an application
The next pattern is the first to include both Amazon Cognito identity pools and a use case where an application and its users would have need to access AWS resources. Let's imagine we have an application that uses Amazon Cognito for its identity management, and part of that app's functionality includes file uploads and downloads from a repository, which is really just an S3 bucket:
All the capabilities and features of Amazon Cognito user pools remains the same as they did previously. What's new here is that the application calls the identity pool to exchange the user's Amazon Cognito user pool tokens for AWS IAM credentials, which will allow them to access AWS resources in accordance with a predefined trust policy. The application delegates authorization to AWS IAM. Once the user assumes those credentials – more specifically, a role that was defined and scoped to allow access from that identity pool – they can interact with the AWS resource through the application.
Though this pattern is common, in the next section, we will see that an Amazon Cognito identity pool does not require a user pool to operate.
Federated user authentication and access to AWS services exposed through an application
This pattern is nearly identical to the previous one, except it sidesteps the use of Amazon Cognito user pools entirely in favor of only depending on federated identity providers. This may be confusing as an Amazon Cognito user pool may also use a federated identity provider for user authentication; the key difference is that a user pool provides authentication and user management for the application that looks to it for those things, regardless of whether the user pool itself federates to an external IDP. On the other hand, an Amazon Cognito identity pool is indifferent to the identity provider the application looks to for user authentication. Identity pools only care about the tokens that are issued by the authoritative identity provider since those attributes can be used to determine authorization and entitlement mapping:
Many of the same mechanics from the previous architecture are in play here as well, except this time, in lieu of an Amazon Cognito user pool token, the token from the federated provider is used to identify the user, collect critical attribute mappings, and align the user to the appropriate trust policy that governs the assumed role they will get during token exchange.