3

aws sts assume-role returns three fields as the issued Temporary Security Credentials.

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY
  • AWS_SESSION_TOKEN

The first two are with the same format of a user's Access Key, but the 3rd field, AWS_SESSION_TOKEN, is special to the temporary credential.

I have two questions:

  • If AWS_SESSION_TOKEN is to represent/encode the temporary validity, why we still needs the first two fields (because after the expiration, we will need to get another AWS_SESSION_TOKEN anyway)?
  • If my client call the STS API twice, between two responses returned from aws sts assume-role, will/could AWS_ACCESS_KEY_ID be same?
chen
  • 3,850
  • 3
  • 31
  • 62

1 Answers1

1

I think there is only one assumption you can relay on: This is the interface provided by AWS and what is not worded specifically in the AWS documentation is not supported.

When a new programmatic access key is created it always differs, so it does not make much sense that it will "stay the same between calls". I think the "AWS_SESSION_TOKEN" hits that you should use it during one session. If it was for one call, it may had been named "AWS_ONECALL_TOKEN". I would assume that the STS assume-role is a much slower operation than a reguler API call. My suggestion is to consider this to be "three part password for one session" and not thing much about it unless you want to create your own implementation for a similar thing. Then it may be very instructive to analyze what are the advantages and disadvantages of this approach.

petrch
  • 957
  • 7
  • 15