Authentication with Social Linking
Anyone building consumer facing apps, be it mobile or web, has spent time looking at different options for authentication and not just the standard username/password model but how to get the joy of federated social logins.
When stepping into the world of federated logins, there are decisions to be made and solutions to be picked and I thought I’d give some assistance to some of the options.
Google Firebase Authentication or AWS Cognito User Pools?
When looking at the two major Authentication SaaS offerings by Google and AWS it became clear that they didn’t view authentication the same way.
Out of the box Firebase is really nice to use. It allows for many different authentication methods that will all link back to one user, assuming matching email address. This was great since it took removed a lot of development work to match up accounts. Stepping over the AWS Cognito it was clearer that the backend setup was going to be much more complex. Cognito is more of an LDAP platform that allows for capturing of user details beyond username and password in addition to deep customization of messages and actions.
Part of your decision here is also going to come down to what you are doing for backend technology. The solution I was working with was in the AWS platform so it made sense to see if I could make Cognito perform the way I wanted it to. If I was starting fresh I may have used Google Firebase for it’s simplicity.
User Pools? Federated Identities? What’s going on?
While setting this up I had to really try to understand the different options with AWS since they give two Cognito services, User Pools and Federated Identities. When you first start working with this you will feel confused at the two services because they are linked, yet not.
User Pools
Let’s start with User Pools. This is your standard user database like authentication service. It can collect details about the user on signup, manages confirmation emails, processes lost passwords, and generally handles anything related to sign-in. If you are in the AWS Console we will ignore the “Federation” section, we’ll come back to this. If all you are looking for is to authenticate users then you have your service.
Identity Pools
Now let’s look at Federated Identities. This is the service that will grant Roles and Policies to the authenticated user inside the AWS platform. If you have technology in the AWS cloud this is a very important part and will allow users discrete access to databases, API’s, or anything else you want to connect them to.
What did you just say?
You might now be completely confused. You look at the diagrams and see Social Logins connected to both and are now thinking it’s time to stop reading and just pretend none of this exists. But let me try to help.
Users Pools holds your users data. Identity Pools grant authorization to services. It’s really that simple. You can link a social login directly to an Identity Pool and NOT store any user data, just grant access if they are a valid, Google, or Facebook user. It’s when you want to know your user that you need to now blend the User Pool in there. You’ll see that Identity Pools view User Pools as just another Identity Provider, it just so happens it’s in the same service in AWS and that makes this confusing.
Federated Social Login Options
Here is where we get into some decision making. I’ll go into some design with one of the options (the one I think makes most sense) but I wanted to give everyone the information of what seems to exist.
Unique Accounts
I think this one is the least desirable one by anyone but is the default that User Pools supports so I did want to mention it. With this setup every login from every Identity Provider gets it’s own account. That means if you have a user setup with username/password and they then use sign-in with Google you end up with 2 accounts that are not connected. Pretty crazy if you ask me.
Identities only
This one relies on the setup of Federated Identities in the Identity Pool. The app would do that authentication and just pass in a valid token from the Identity Provider and then the user would have access. With this model you aren’t actually storing any details about the user and the identities in the pool could change over time. Might suit some use cases but not the one I had.
Single Account for All!
Saving the most likely one for last, this is the the setup where there is an account in the User Pool and all the identity providers link to it. Easy right? While even here has a few options for configuration.
Option 1 (username setup first)
This option forces the user to create a User Pool account. Why you ask? Well you could collect details from the user this way that won’t come from the Identity Provider for one reason. It allows for your signup flow to be consistent. Once the user is created then if the user tries to sign in with an Identity provider that has a matching email it will automatically link them.
Option 2 (automatic creation)
It might be desirable to let the user sign up using an Identity Provider account if you have not extra data to collect. The trick on this one is you should still create that you need to create that username User Pool account first and then link to it. Why you ask? If the user ever stops having access to that Identity Provider or wants to just drop using it if you don’t have that account they can’t revert back to username/password.
Option 3 (force linking)
Force linking is the final option. It’s a blend of 1 and 2. The way this one would work is you make the user create an account like in option 1 but instead of then letting them sign in immediately from the social buttons they have to go into the settings and link their identity providers to the account. Why would you even think this is a good idea, you might be thinking. Option 2 is great if you can match on email, but what if the user has a different email address attached to their Google account then the one they signed up with. No Social login utopia for them. Making them manually link accounts would allow for complete flexibility in setting up the identity provider linkage.
So What’s Next?
I hope this initial understanding of how AWS Cognito works along with some options to do social logins has been useful.
Let me know if this helped, or not and I’ll try to update the article to make everyone feel like they are masters of AWS Cognito.
