At Flowcase, we use AWS Cognito to log in to our internal tools. We have a range of in-house administrative tools that help us get things done, from deploying new versions of our software to production, to onboarding new users into our product.
While Cognito works well for us, it hasn’t been entirely smooth sailing. This post is a write-up of the problems we’ve encountered and we hope it helps you make your own decision on whether or not to use Cognito.
What is Cognito?
Cognito is Amazon’s authentication and authorisation service. With it, you can set up a secure way of having users log in to your product (authentication) and specify the things those users have access to (authorisation).
Cognito also supports federated sign-on, so if you already use some identity provider (say, Google) you can allow users to sign in using their existing credentials.
Why Cognito?
It would have been possible to make our internal tools only accessible through a VPN. If we did that, we could be sure that only employees can access the tool, so why make things more difficult?
There are two key reasons:
- Not all employees have a need to be on the company VPN, and
- Not all employees need access to all internal tools.
It wouldn’t make sense for someone working on customer success to have the ability to deploy to production. Ideally employees would only have access to what they need to do their job, and no more.
Cognito has the concept of “groups,” and in our tools we can use the groups a user is a member of to figure out what they have access to. If you’re in the “Deployer” group, you can deploy to production. If you’re not, you can’t.
We have separate Cognito setups for each of our AWS accounts. We use multiple AWS accounts to keep real user data separate from our development and testing environments. If you haven’t already, check out the post from our lead platform engineer James Denness about working with multiple AWS accounts.
Having separate Cognito setups for each of our accounts allows us to give people broader access to tools when not working with real user data, which helps them develop and test changes faster.
All of the above makes Cognito a compelling choice for us. We already have Google accounts, and being able to set up fine grained permissions easily makes our tools safer and more scalable as the business grows.
Cognito and CloudFormation woes
We use AWS CloudFormation to describe and deploy our infrastructure, and we wanted Cognito to be no exception. You can get most of the way there, but it’s not as fully automated as we’d like.
Here’s an example of a CloudFormation file describing a Cognito setup using Google as an identity provider[1]. With this you can automate the creation of everything except individual users and the groups they’re in.
If you’re using an external identity provider, like Google, the only way to set up users in your user pool is to have them physically log in themselves. When they do this, an entry in the user pool is created for them. This is called an “external user” in Cognito parlance, and as far as we can tell there’s no other way to create one. The CloudFormation documentation shows that you can create user records, but not link them with a federated provider.
Because you can’t create external users through CloudFormation, you may as well assign people to groups manually as well. CloudFormation does offer a way to associate a user with a group, but if the user doesn’t exist it will fail. If we were bringing up Cognito in a new environment from scratch having user-to-group associations that fail if the user doesn’t exist would be a bad idea.
Another part of the process that cannot be automated is whitelisting your redirect URI in Google. Part of the authentication process involves redirecting the user to Google, having them log in, and then redirecting them back to a URL you control with an authentication code. Google, and most other providers, have you whitelist the URLs you want to redirect users back to, as the authentication codes they send are sensitive
Other Gotchas
When you assign a user to a group in Cognito, that change won’t be reflected until they log out and back in again. We haven’t been able to find a way around this. It’s a minor annoyance, but one we can live with.
Having this setup also makes it a bit tricky to do local development. What we’ve settled on is having our local environment connect to our development Cognito setup. This works fine in practice, but feels a bit icky.
Conclusion
Cognito works well for us. Employees can use their existing company Google account to log in to internal tools, and we have fine-grained control over the tools each employee has access to.
There’s a small overhead getting each new employee set up, and setting up new internal tools, but it’s not a big source of pain for us at the moment. For bigger organisations, not being able to automatically provision users could be a showstopper, so do be sure to carefully consider the pros and cons before jumping in to Cognito.
