Would an IAM token without X-Amz-Security-Token work?

[bow-fujita]

Hi,
I came across to this old issue because my app had intermittently failed with IAM authentication to RDS Proxy due to missing the X-Amz-Security-Token parameter. The issue was closed as it started working by executing aws sts get-caller-identity and it was said "The tokens are still missing the field X-Amz-Security-Token but still seem to work fine without it".
I get confused because the IAM API reference is saying that X-Amz-Security-Token must be included while using temporary security credentials from AWS STS. Can anyone elaborate how an IAM token without X-Amz-Security-Token generated by aws rds generate-db-auth-token would be authenticated and how the GetCallerIdentity would help?

[uldyssian-sh]

If you are using temporary AWS credentials (anything from STS: assumed roles, SSO, IMDS role creds, MFA sessions), then the session token is part of the credentials and it must be sent with the request as X-Amz-Security-Token (either as a header or as a query-string parameter). That requirement is part of SigV4 with temporary credentials.

So, an “IAM auth token” for RDS/RDS Proxy that is generated from temporary credentials but does NOT include X-Amz-Security-Token should not be expected to work reliably. If it ever “works”, it is almost always because the credentials used at that moment were actually long-term credentials (no session token), or because the client was using a different credential source than you assumed.

How aws rds generate-db-auth-token relates to this

aws rds generate-db-auth-token produces a SigV4-presigned token (a signed string used as the DB password). If the underlying credentials include a session token, the presign step must include X-Amz-Security-Token too; otherwise the server-side verification of the signed request will fail for STS-based credentials.

Why “aws sts get-caller-identity made it work” in the old issue

Calling aws sts get-caller-identity does not change how RDS Proxy validates auth tokens.

What it can do is force the AWS credential provider chain to resolve/refresh credentials so the process has a complete, consistent set of credentials (AccessKeyId + SecretAccessKey + SessionToken when applicable). After that refresh, subsequent token generation can include the session token correctly.

Intermittent missing X-Amz-Security-Token is usually caused by one of these:

You are sometimes generating the token with incomplete environment variables (e.g., AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY set, but AWS_SESSION_TOKEN missing).

You have multiple credential sources (env vars + shared config + SSO/IMDS) and the process occasionally picks a source that lacks a session token.

Your application caches credentials and does not refresh them consistently, so sometimes it generates tokens with stale/partial creds.

What to do (reliable fix)

Ensure that when you are using temporary credentials, you always provide the full trio:

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

AWS_SESSION_TOKEN

Or avoid env-var partials and let the SDK/CLI resolve credentials from a single consistent provider (SSO profile, role, IMDS, etc.).

And verify which credentials you are actually using at runtime by checking the caller identity once per session (or on refresh), not on every request:

aws sts get-caller-identity

Summary

Temporary credentials require X-Amz-Security-Token.
A token missing it should not be considered valid for STS-based creds.

GetCallerIdentity only “helps” by triggering a credential refresh/selection so the token generator uses complete credentials.

[uldyssian-sh]

Thanks! If this helps, please consider marking it as “Helpful” or “Accepted” 😊