What Is a Security Token Service (STS)?

A contractor signs in to your corporate identity provider once, in the morning. By noon their browser has presented credentials to a SaaS analytics app, an internal wiki, and an AWS account, and not one of those systems ever saw the contractor's password. Each handed off to something that vouched for the identity and minted a short-lived token scoped to exactly what that app was allowed to do. The thing doing the minting is a security token service.

A security token service (STS) is a component that issues, validates, and exchanges security tokens so that one system can trust an identity authenticated by another. Instead of every application holding its own copy of a user's password, the STS authenticates once (or trusts an identity provider that did) and hands out a signed token the relying party can verify. That token says who the subject is, what they are allowed to do, and how long the grant lasts.

This guide covers what an STS is, how token issuance works across SAML, OAuth, and OpenID Connect, how AWS STS issues temporary credentials, how federation uses an STS to cross trust boundaries, and the risks a blue team has to watch around token issuance and theft. It is written for defenders who keep seeing "STS" in identity logs and cloud trails and want to know exactly what it is doing.

What is a security token service?

A security token service is an authority that issues security tokens. A token is a signed, time-bound assertion about an identity: it carries claims (who the subject is, which groups or roles they hold, what scope they were granted) and a signature the recipient can verify against the issuer's key. Because the recipient trusts the issuer's signature, it does not need the user's password, and it does not need to call back to the identity provider on every request.

The point of the pattern is to separate authentication from authorization and to keep long-lived secrets out of circulation. The STS does the trust-establishing work once, then issues a credential that is deliberately short-lived and narrowly scoped. If that token leaks, it expires on its own and only ever granted access to a slice of what the user could do. This is the same principle identity access management is built on: issue the least privilege needed, for the least time needed.

"STS" shows up in three places that are worth keeping straight:

• The WS-Trust STS, the original SOAP-era definition: a service that issues and exchanges tokens, often SAML tokens, in a request-and-response protocol called WS-Trust.
• The token endpoint of a modern identity provider, which issues OAuth access tokens and OpenID Connect ID tokens. An identity provider like Microsoft Entra ID or Okta acts as an STS in this sense.
• AWS STS, a specific AWS service that issues temporary AWS credentials. This is the meaning most cloud defenders hit first.

They are the same idea in different clothes: a trusted issuer hands out short-lived, verifiable tokens so a relying party never has to handle the original credential.

How token issuance works

The flow is consistent regardless of the protocol. An STS sits between a subject that wants access and a relying party that controls the resource.

1. Authenticate or trust. The subject proves who they are to the STS, or presents proof from an upstream identity provider that the STS already trusts.
2. Evaluate policy. The STS decides what claims and scope the subject should get based on its rules: group membership, requested audience, requested permissions.
3. Mint and sign. It builds a token containing the claims, an audience (who the token is for), an issue and expiry time, and signs it with its private key.
4. Return the token. The subject receives the token and presents it to the relying party.
5. Validate. The relying party checks the signature against the issuer's public key, confirms the audience and expiry, reads the claims, and grants access accordingly. No password ever touches the relying party.

The signature and expiry are what make the model safe. A relying party can validate a token offline using the issuer's published key, so issuance scales without a central bottleneck. The expiry bounds the blast radius: a stolen token is only useful until it lapses.

SAML, OAuth, and OpenID Connect

Three token standards dominate, and they answer different questions.

• SAML (Security Assertion Markup Language) is an XML-based standard built for enterprise single sign-on and federation. The STS issues a signed SAML assertion the relying party consumes. SAML answers "who is this user and what are their attributes," and it is the workhorse of corporate web SSO.
• OAuth 2.0 is an authorization framework, not an authentication protocol. It issues access tokens that grant a client delegated permission to call an API on a user's behalf, scoped to specific actions. OAuth answers "what is this client allowed to do."
• OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. It adds an ID token (a JSON Web Token) that asserts the user's identity. OIDC answers "who is this user," in the modern JSON/REST world that has largely replaced SAML for new applications.

A practical way to hold them apart: SAML and OIDC tell a relying party who you are; OAuth tells an API what you may do. Modern identity providers issue all three from the same token service, picking the format the relying party speaks.

AWS STS and temporary credentials

AWS Security Token Service is the cloud-native version most defenders meet in logs. It is a web service that issues temporary, limited-privilege credentials for AWS Identity and Access Management users or federated users, so you never have to distribute long-lived access keys.

Every set of credentials it returns has three parts: a temporary access key ID (these begin with the prefix ASIA, which is how you spot a temporary credential in logs), a secret access key, and a session token that must accompany every signed request. The set carries an explicit expiration, after which it is dead.

The service exposes a handful of actions a defender should recognize:

• AssumeRole. Take on an IAM role to get temporary credentials, the basis of cross-account access and of roles attached to EC2 instances and Lambda functions. Default session is 1 hour; the maximum is 12 hours.
• AssumeRoleWithSAML. Assume a role using a SAML assertion from an enterprise identity provider, for federated corporate users.
• AssumeRoleWithWebIdentity. Assume a role using an OIDC or OAuth identity provider such as Amazon Cognito, Google, or Facebook, for mobile and web apps.
• GetSessionToken. Issue temporary credentials for an existing IAM user, commonly used to enforce MFA. Default session is 12 hours; the maximum is 36 hours.
• GetFederationToken. Issue temporary credentials for a federated user, for example a third party or partner.
• GetCallerIdentity. Return the account ID, user ID, and ARN of whoever is making the call. It is read-only and is the standard way to answer "whose credentials are these," which makes it a frequent sight in both legitimate debugging and reconnaissance.

A short example shows the shape of an AssumeRole call: aws sts assume-role --role-arn arn:aws:iam::123456789012:role/MyRole --role-session-name MySession --duration-seconds 3600. The response carries the temporary AccessKeyId, SecretAccessKey, SessionToken, and Expiration. From there the caller acts as that role, with that role's permissions, until the credentials expire. STS is reachable at a global endpoint (sts.amazonaws.com) and at regional endpoints (for example sts.us-east-1.amazonaws.com); regional endpoints are the recommended default for latency and resilience.

This is the same least-time, least-privilege idea as privileged access management: rather than hand a workload a permanent key, you grant it a role it can assume for a bounded window.

Federation: crossing trust boundaries

Federation is the reason an STS exists at scale. It lets one trust domain accept identities authenticated by another, so a user in a corporate directory can reach a cloud or SaaS resource without a separate account there.

The STS is the broker. A user authenticates to their home identity provider, which issues a token; the STS in the resource domain trusts that issuer, validates the token, and exchanges it for one the local relying party accepts. Token exchange is the core move: the service trades a token from a trusted source for a new token scoped to the target. AWS AssumeRoleWithSAML is exactly this. A user signs in to the corporate IdP, the IdP issues a SAML assertion, and AWS STS exchanges that assertion for temporary AWS credentials tied to an IAM role.

This is what makes single sign-on across organizational boundaries work, and on Amazon Web Services it is how a workforce reaches cloud resources without anyone minting standing IAM users. The trade-off is that the trust relationship itself becomes the thing an attacker targets. If the home IdP is compromised, every relying party that federates to it inherits the breach.

Security risks defenders watch

The STS model removes one class of risk (long-lived passwords spread across apps) and concentrates another (the token and the issuer become high-value targets). For a blue team, the issuance service and the tokens it mints are both worth monitoring.

Two patterns deserve naming. The first is token theft: because a relying party trusts any holder of a valid token, an attacker who steals one needs neither the password nor MFA until it expires. This is why short lifetimes and binding a token to its intended audience matter. The second is the forged token: in a Golden SAML attack, an adversary who steals the SAML signing key of an identity provider can mint assertions for any user, with any privileges, that every federated relying party will accept. The token service is trusted by design, so its keys are crown jewels.

In AWS specifically, watch CloudTrail for the STS API. A burst of AssumeRole calls from an unexpected principal, GetSessionToken from a never-before-seen source, or GetCallerIdentity followed by privilege probing are classic markers of an attacker who has a credential and is testing what it can reach. Because temporary keys begin with ASIA, they are easy to distinguish from long-lived AKIA keys when triaging. Token issuance is normal traffic, so the signal is in the deviation, not the action.

STS in practice

Across all three meanings, the STS earns its place by doing one job well: it is the trusted issuer that lets systems share identities without sharing secrets. A WS-Trust STS exchanges SAML tokens between SOAP services; an OAuth/OIDC token endpoint issues access and ID tokens for modern apps; AWS STS hands workloads and federated users temporary credentials instead of permanent keys. The mechanics differ, the principle does not.

For a defender, the practical takeaways are short. Tokens are bearer credentials, so a valid one is access regardless of who holds it; keep them short-lived and tightly scoped. The issuer and its signing keys are the highest-value target in the identity stack; protect and monitor them as such. And the STS API is a rich source of detection signal: in the cloud especially, who is assuming which roles, how often, and from where tells you a great deal about both normal operations and an intruder testing the locks.

Frequently asked questions

What is a security token service (STS)?

A security token service is a component that issues, validates, and exchanges security tokens so one system can trust an identity authenticated by another. It authenticates a subject (or trusts an upstream identity provider that did), then issues a signed, time-bound token carrying claims about who the subject is and what they may do. The relying party verifies the signature instead of handling the original password, which keeps long-lived secrets out of circulation.

What is AWS STS used for?

AWS Security Token Service issues temporary, limited-privilege credentials for AWS IAM users and federated users, so you avoid distributing long-lived access keys. It powers cross-account access, roles attached to EC2 and Lambda, and federated sign-in from corporate or web identity providers. Each credential set is a temporary access key, secret key, and session token with an explicit expiration, and temporary access keys begin with the prefix ASIA.

What is the difference between SAML, OAuth, and OpenID Connect?

SAML is an XML standard for enterprise single sign-on that asserts who a user is and their attributes. OAuth 2.0 is an authorization framework that issues access tokens granting a client delegated permission to call an API, answering what a client may do. OpenID Connect is an authentication layer on top of OAuth that adds an ID token asserting the user's identity, in the JSON world that has largely replaced SAML for new applications.

What is token exchange in an STS?

Token exchange is when the STS trades a token issued by a trusted source for a new token scoped to a different target. It is the mechanism behind federation: a user authenticates to their home identity provider, which issues a token, and the resource domain's STS validates that token and exchanges it for one the local relying party accepts. AWS AssumeRoleWithSAML is a concrete example, swapping a corporate SAML assertion for temporary AWS credentials.

What is a Golden SAML attack?

In a Golden SAML attack, an adversary who steals the SAML token-signing key of an identity provider can forge valid SAML assertions for any user with any privileges. Because every federated relying party trusts the identity provider's signature, it accepts the forged tokens without the user ever authenticating. It targets the trust at the heart of the token service, which is why protecting and monitoring signing keys is critical.

Why are STS tokens short-lived?

Short lifetimes bound the damage of a stolen token. A token is a bearer credential, so anyone holding a valid one gets access without the password or MFA. Keeping the lifetime short means a leaked or replayed token expires on its own before it can be used widely, and pairing short lifetimes with narrow scope ensures any single token grants only a slice of what the subject could do.

The bottom line

A security token service is the trusted issuer at the center of modern identity: it authenticates once, then hands out short-lived, signed tokens so systems can share an identity without ever sharing a password. The same pattern appears as a WS-Trust STS issuing SAML tokens, as the OAuth and OpenID Connect token endpoint of an identity provider, and as AWS STS issuing temporary credentials in the cloud. For defenders, two facts carry the weight: a valid token is access for whoever holds it, so short lifetimes and tight scope are the controls that matter, and the issuer's signing keys are the crown jewels of the identity stack. Watch the issuance, protect the keys, and the token service does exactly what it was built to do.