So 2 questions.
What am I missing here. It seems like you give any malicious user with JS access keys to the Cognito kingdom with these 2 pieces of information.
A User Pool Client resource represents an Amazon Cognito User Pool Client that provides a way to generate authentication tokens used to authorize a user for an application. Configuring a User Pool Client then connecting it to a User Pool will generate to a User Pool client ID.
With a user pool, your app users can sign in through the user pool or federate through a third-party identity provider (IdP). Identity pools are for authorization (access control). You can use identity pools to create unique identities for users and give them access to other AWS services.
No, they are not. They are supposed to be public. The only way they can be exploited is that someone can use them to make a large amount of SignUp calls to your userpool.
They are not secret.
In fact, the ID token contains the iss
claim (property), which is the User Pool ID, and the aud
claim, which is the App Client ID.
The Access token contains the iss
claim, which again is the User Pool ID, while it's the client_id
claim which represents the App Client ID.
Should either of these tokens be intercepted by a bad actor, then they can decode the tokens, as they are just base64 encoded (not encrypted).
However, just knowing these 2 pieces of information is not usually terribly useful for an attacker, as long as the JWTs are validated correctly.
It does not give the attacker access to the User Pool itself as that requires AWS credentials, which are only assigned to users, or identities that have already been properly authenticated (and then issued credentials e.g. by ID Pools).
In terms of accessing an api, an attacker might want to modify the payload in some way in order to change the data in the request. For instance they may want to change a hypothetical role
claim from user
to admin
in order to escalate privileges and access areas that they shouldn't. This is mitigated by correctly validating the JWT tokens server-side to ensure that the payload has not been tampered with.
Another type of api attack could be to use a token that was correctly authenticated for one api to access another api (JWT substitution). This is mitigated by validating the iss
and aud
claims in order to confirm that the JWT was specifically issued to the expected User Pool and App Client.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With