1

After a user logons to cognito, he receives access and ID tokens. the ID token contains sensitive info like phone number, email, etc..

From all standards - ID token should not be used to gain access to an API: https://auth0.com/docs/tokens?_ga=2.253547273.1898510496.1593591557-1741611737.1593591372

In the backend, to get a session credential (to work with AWS resources) - you typically do this:

identity_id_response = boto3.client('cognito-identity').get_id(
    IdentityPoolId=identity_pool_id,
    Logins={
        provider: id_token #ID token! not access token
    }
)

Then:

provider = f'cognito-idp.{region}.amazonaws.com/{user_pool_id}'

response = boto3.client('cognito-identity').get_credentials_for_identity(
    IdentityId=identity_id_response,
    Logins={
        provider: id_token #access token again
    },
)

Then, you can use AccessKeyId, SecretKey, SessionToken etc..

This is problematic as what if you want to send the ID token to multiple services (via SNS, etc..) so you could perform processing on behalf of the user? you basically send a sensitive token that contains sensitive user data over the backend.

So - it requires an encryption before sending this token, which seems like an overhead.

Any thoughts?

0

From Question:

From all standards - ID token should not be used to gain access to an API: https://auth0.com/docs/tokens?_ga=2.253547273.1898510496.1593591557-1741611737.1593591372

Example from Documentation:

 if there's an app that uses Google to log in users and to sync their calendars,
 Google sends an ID Token to the app that includes information about the user. ......
    In the Google example above, Google sends an Access Token to the app after the user logs in 
and provides consent for the app to read or write to their Google Calendar.
Whenever the app wants to write to Google Calendar, it sends a request to the Google 
Calendar API, including the Access Token in the HTTP Authorization header.

It seems the documentation is referring to the APIs on Identity Provider's end (Which is Google in this case). The example discusses a use case which involves both authentication and authorization. The ID token is used for authentication and the access token is used for the API calls (modifying Google calendar on behalf of the user, also called "delegated authorization"). Delegated authorization was the basic idea behind OAuth.

The message they want to convey is: use access token to write to Google calendar on behalf of the user and use ID token to identify the user as the relying party.

I am guessing your use case with Cognito only involves authentication hence the ID token is used. The access token is gibberish from the perspective of AWS STS.

More from question:

This is problematic as what if you want to send the ID token to multiple services 
(via SNS, etc..) so you could perform processing on behalf of the user? 
you basically send a sensitive token that contains sensitive user data over the backend.

I am not sure if I understand your use case. Why is it that the initial set of temporary security credentials returned by STS are not having the required access?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.