Using social federation

Social federation allows you to build your applications to request temporary credentials. Much like in the previous discussion relating to enterprise federation where we used SAML, these temporary credentials with social federation map to an AWS IAM role that has the relevant permission to access your DynamoDB database.

Instead of using your internal ADFS servers to authenticate users, the users of your app can use widely known social IdPs, for example, Facebook, Amazon, and Google. In fact, as long as the IdP is OpenID Connect (OIDC) compatible, then you can use them for authentication. Using these social IdPs, the user can get an authentication token, which in turn is exchanged for temporary credentials, and these credentials are associated with your specific IAM role with the required permissions.

When creating applications that require social IdPs for authentication, you need to write specific code to interact with the IdP to allow you to call the AssumeRoleWithWebIdentity API, which allows you to replace the token with temporary credentials. However, if you want to remove the need to have to write this specific code for the IdP, then there is another method, and it's actually recommended by AWS. This preferred and best practice method is to use Amazon Cognito.

Amazon Cognito

Amazon Cognito was built purely for the simplification of enabling secure authentication and access control for new and existing users accessing your web or mobile applications. It not only ingrates well with enterprise federation but also social federation. One of the biggest features of Amazon Cognito is that it has the capability to scale to millions of new users, which is great when working with mobile applications, which will be the focus of this discussion.

There are two main components of Amazon Cognito that you should be aware of, these being user pools and identity pools, and they perform different actions that we will see in the following topics.

User pools

User pools are essentially scalable user directories that allow new and existing users to log in to your mobile application using the user pool or they can alternatively federate their access via a social or enterprise IdP. Either way, a profile within the user pool is created for each and every user. These profiles contain no permissions for access to your AWS infrastructure; they allow them to log in to your mobile app as a user and use it.

Once a user is authenticated via the user pool, either from the user pool itself or via a third-party IdP, Amazon Cognito will generate tokens that manage the access to your mobile app.

It is also possible to enable additional features using user pools, such as the ability to enable multi-factor authentication (MFA), providing additional security to your user base. You can also create user pool groups and assign different permissions to different groups. This provides greater access control and prevents all users from having the same access, which might cause a security risk.

Identity pools

Identity pools are different from user pools. Identity pools actually provide you with the ability to assign permissions to users to access your AWS resources used within the mobile app by using temporary credentials. This access can be granted to both federated users and anonymous guest users. Identity pools support federated access for users that have been authenticated by user pools, OpenID Connect IdPs, SAML IdPs, social IdPs, and developer-authenticated identities. These permissions are assigned through IAM roles and can be mapped to different users to provide different permissions sets.

Once a user has authenticated either via a user pool or a social IdP, the token received and managed by Amazon Cognito can then be exchanged for temporary credentials using the identity pools. These credentials can then be used to access the AWS services required when using your mobile app.

Gaining access using user and identity pools

These two types of pool, both user and identity, can be used together or separately, depending on the functional requirements of your mobile app. The following diagram shows gaining access to AWS resources via the user pool for token generation:

This diagram is explained in the following steps:

1. Tokens are received from a third-party IdP, such as Facebook. The user pool then manages these tokens and authenticates the user to the app.  
2. The tokens are then exchanged for temporary credentials, based upon an associated IAM role with set permissions through the identity pool.
3. When these permissions have been assumed, the user of the mobile app is then authenticated and authorized to access the appropriate AWS services.

The diagram that follows shows users gaining access to AWS resources via the identity pool without the user pool:

This diagram is explained in the following steps:

1. A user authenticates with a third-party IdP, such as Facebook. The social IdP generates tokens, which are sent back to the mobile app.  
2. The tokens are then sent to the Amazon Cognito identity pool to be exchanged for temporary credentials, based upon an associated IAM role.
3. When these permissions have been assumed, the user of the mobile app is then authenticated and authorized to access the appropriate AWS services.

If you are building applications to run on a mobile client, then using Amazon Cognito is a great way to implement access management with simplicity and ease using social federation.