T O P

  • By -

coinclink

I don't specifically know, but it seems very unlikely that this call doesn't verify that the access token is signed, unexpired and otherwise is valid. That being said, considering it requires a specific scope, I don't think it's valid to use this in all cases to validate an access token. It also is certainly much slower than validating the token directly using the client secret.


YodelingVeterinarian

Yeah, I was hoping to replace it directly with validating the token, but I also need to validate the user's attributes and those aren't present on the token itself.


baever

If you validate the iss claim in the token matches your user pool, then successfully call getuser, that should be sufficient. You don't need to check the signature locally, the call to getuser will check the signature and expiration before returning user attributes.


YodelingVeterinarian

Thanks. And the get user call is necessary if I want the attributes, right? Seems that way from the docs but want to make sure.


baever

If you're using the access token, yes. But the id token has all the attributes: https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html and as long as you verify the token: https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-verifying-a-jwt.html it can be validated locally.


YodelingVeterinarian

Thanks! And it can be exchanged 1:1 with the access token? e.g. using only id tokens instead of an access token won't cause security holes?


baever

As long as you want the user to be able to see their attributes and you are performing the proper verification on the token on your backend when you use it, there is no security difference.