Replace AWS Cognito Hosted UI

Cognito Hosted UI is far more than a UI and replacing it considerable harder than you might think.

Cognito Hosted UI

Amazon Cognito offers a user directory that scales to millions of users at an incredible competitive price. We’ve been using Cognito for the last couple of years and love its simplicity, robustness and pre-integration with other AWS services.

Cognito comes with a built-in web UI. In combination with the Amplify SDK, this makes adding an authorization experience to any web app trivial: add a couple of lines of code to get a secure web experience for users.

What’s the issue with Cognito Hosted UI?

That sounds all fantastic, right? Yet, there are some serious limitations to Cognito Hosted UI:

• The UI feels a bit dated and the look & feel can be customized only to a limited degree (ticket).
• The UI is only available in English and it’s impossible to support any other language (ticket).
• The UI would be the place to implement a workaround for Cognito’s case-sensitive username/email matching (ticket) — but it doesn’t do that.
• In a multi-tenant application, each tenant requires its own Cognito User Pool for data separation, password policies, SAML support, etc. Yet, Cognito supports max 4 custom domains per account for the Hosted UI (documentation). This means, users can access the UI on tenant.your-company.com only for the first 4 tenants. For the everybody else it’s going to be the less pretty tenant.auth.<region>.amazoncognito.com .

In summary, there are many good reasons to replace Cognito Hosted UI once you leave “standard land”.

What’s the Cognito Hosted UI really?

Replacing a UI can’t be that hard, right? Two input boxes, a submit button, and a click handler. Right? Wrong!

As a starter, there are many more screens and flows aside the username/password entry screen: failed login, password recovery, MFA, SAML/AD, error states, etc.

Beyond that lurks an even bigger challenge: The Cognito Hosted UI is far more than a UI. It’s a full blown OAuth server, backed by the Cognito API. Redirecting access tokens to the web application, redirect URL validation, SAML flows: all handled by the Cognito Hosted UI. Replacing the Hosted UI therefore requires to reimplement these functions as well.

Do we want to have our own OAuth server?

By now, it’s clear that replacing the Hosted UI is a far larger endeavor than creating a UI. So, is it worth it?

Authorization is one of the most security-sensitive parts of a web application. Attackers and pen-tester will therefore scrutinize it very carefully. There are standards and protocols like OAuth and OpenID. Yet, they tend to be complex and security experts continuously learn about weaknesses and new best practices, e.g. [1], [2].

We opted for Cognito precisely to not stand on the forefront of security research. Instead, we want to tap into Amazon’s vast experience in this field. Maintaining our own OAuth server deployment would add a considerable amount of risk.

Happy coding!

PS: In case you’re wondering, we decided for now to stick to the Cognito Hosted UI.