Securing AWS Cognito User Pool and Client ID on a static web page Securing AWS Cognito User Pool and Client ID on a static web page angular angular

Securing AWS Cognito User Pool and Client ID on a static web page


Their recommendation applies when you use both the App Client ID and the Secret (typically in mobile development).

When you create an app, you can optionally choose to create a secret for that app. If a secret is created for the app, the secret must be provided to use the app. Browser-based applications written in JavaScript may not need an app with a secret.

When you are using Cognito on the web, you don't need to generate the Secret (uncheck the box when creating the application in your User Pool). This indeed leaves the App Client Id in clear text on the client, but there's no extra risk to this scenario than it is to having the login page exposed to the open internet: an attacker could attempt to brute force your login, regardless.

What I'm sure Amazon does in this case (which is what people should do in the case of a custom login implementation anyways) is to defend against throttled requests, blacklisting IPs etc., which essentially slows down attackers to the point where it's infeasible or not worth it to perform brute force attacks.

In short, you need not worry about leaving the App Client Id embedded in your web frontend code.

Hope this helps!


To shed some light on the topic. Client Secret is a concept that comes from OAuth2 here:

If the developer is creating a “public” app (a mobile or single-page app), then you should not issue a client_secret to the app at all. This is the only way to ensure the developer won’t accidentally include it in their application. If it doesn’t exist, it can’t be leaked!

A Client Secret should only be used if you are building a web sever app, or an app that is not public facing.