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.
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.
