If you’re using AWS Cognito User Pools for user authentication in your application, there’s a good chance that eventually you’ll want to start using social identity logins. This will let your users log in to your application using their social media accounts, or their corporate credentials. In turn this means users don’t have to worry about creating another account for your system. You can also work with corporate clients to use their access control processes allowing only authorized staff access to your systems.
This can all make things much more convenient for your users, but it means there are some things you need to consider when you’re developing your system.
You need to take the possibility of using social media logins and third party ID providers into account when you’re creating the user pool(s) for your application. One of the options you have during the user pool creation process is to set the attributes that you want to be compulsory for the users to provide. It’s tempting to select quite a few of these, as they all look “useful”; don’t do this. As well as making it more likely you’ll have to worry about the GDPR and other privacy laws because of the amount of data you hold on your users, there’s also a good chance you’ll make it harder, if not impossible, to configure your user pool to work with social ID providers.
The only attribute you really need is:
email
That’s it. If you want to be able to personalize your user interface with the user’s name then you may also want:
given_name
family_name
But even these details aren’t really essential. The user’s email address provides the unique value you need to associate a user’s identity with a specific account on your system.
I mentioned that adding more compulsory fields can make it harder to work with social ID providers, and it’s definitely worth exploring this a little more. The AWS Cognito documentation can be a little vague in places, and this is one of them.
When you use social ID providers with Amazon Cognito user pools, you need to provide your social login account’s credentials to your user pools in Cognito. During the authentication process, your application will query Cognito with the user’s credentials. The user credentials will then be used to validate against the ID provider that you specify, whether that’s Google, Facebook, and OpenID provider, SAML/Active Directory or something else.
Part of this process can involve the retrieval of the user’s profile information from that provider. This is why, when you add an ID provider to a Cognito User Pool, you need to map the attributes of your user pool to those of the ID provider. The actual data that is returned depends on how the user has configured their profile on that system, and what attributes the provider themselves ask for. This is where the problems can start. Maybe the user has provided every attribute requested by the ID provider, maybe they have missed out some, or even most of the values.
If your user pool has an attribute declared as compulsory, but that attribute is not returned by a third party ID provider that you’re using to validate your users’ credentials, all of your attempts to validate your users’ credentials will fail. Once you’ve fixed any other problems disguising it, you’ll get errors from the ID provider saying that the attribute(s) you want cannot be retrieved from the provider.
There is no way to fix this other than to recreate the user pools. If you already have users in your production system, you’ll need to migrate them in some way. This is one of the many reasons you should have separate environments at least for your development, testing and production environments. As always, making mistakes in development and correcting them there is much cheaper and easier than doing it in production.
