STS

A Security Token Service (STS) is a trusted service that issues, validates, and exchanges security tokens so users, applications, and workloads can access resources without sharing long lived credentials.

What Is a Security Token Service?

A Security Token Service is the part of an identity system that turns a verified identity into a token another system will accept.

After a user, application, or workload authenticates, the STS issues a signed token. The token carries claims about who the requester is and what it is allowed to do.

The receiving application, often called the relying party, trusts the STS rather than the requester. It checks the token’s signature, issuer, audience, and expiry, then makes its own access decision.

Common token formats include:

• SAML assertions
• JSON Web Tokens (JWTs) used by OAuth 2.0 and OpenID Connect
• Temporary cloud credentials, such as AWS access keys paired with a session token
• Kerberos tickets in Windows environments

The STS concept was first formalized in OASIS web services standards and later carried into modern protocols. OAuth 2.0 Token Exchange (RFC 8693) defines how a client can ask an STS to swap one token for another.

How Does a Security Token Service Work?

1. A user or workload authenticates with an identity provider, using a password with MFA, a certificate, or an existing token.
2. The requester asks the STS for a token scoped to a specific application, role, or resource.
3. The STS checks the request against its trust policies and decides which claims to include.
4. The STS signs the token and sets a short validity period.
5. The requester presents the token to the target service.
6. The target service validates the signature and claims, then grants or denies access.
7. The token expires, and the requester returns to the STS for a new one.

Because the target service only needs to trust the STS signing key, organizations can connect many applications, partners, and clouds without distributing passwords to each of them.

Where Are Security Token Services Used?

• Federation and SSO: Microsoft Active Directory Federation Services (AD FS) acts as an STS. It issues SAML or OIDC tokens so employees can sign in to SaaS applications with corporate credentials.
• Cloud access: AWS STS issues temporary credentials when a user or service assumes an IAM role, including roles assumed through SAML or web identity federation.
• Workload identity federation: Google Cloud’s STS exchanges tokens from external identity providers, such as a CI/CD platform, for short lived cloud credentials. Pipelines can deploy without stored service account keys.
• API delegation: A backend service exchanges a user’s token for a narrower token before calling a downstream service.
• Cross account access: Teams in one cloud account assume roles in another without creating duplicate users.

Why Is an STS Important for Security?

Static credentials are one of the most common causes of cloud breaches. Long lived access keys get committed to source code, copied into scripts, and forgotten after projects end.

An STS reduces that risk by issuing credentials that:

• Expire automatically, often within minutes or hours
• Are scoped to a specific role, audience, or resource
• Carry context such as MFA status, session tags, or source identity
• Leave an audit trail of who requested access and when

This makes the STS a building block for least privilege, just in time access, and Zero Trust, where access is granted per session rather than permanently.

It is also central to governing nonhuman identities. Workloads that use an STS can drop hard coded secrets entirely.

What Are the Main STS Security Risks?

An STS is a high value target. If attackers can sign tokens, every system that trusts the STS will trust them too.

• Stolen token signing keys: In a Golden SAML attack, attackers who steal an AD FS token signing certificate can forge tokens for any user and bypass MFA. MITRE ATT&CK tracks this as Forge Web Credentials: SAML Tokens.
• Overly permissive trust policies: A role that any principal, or any repository in a CI/CD provider, can assume opens a path for outsiders.
• Long token lifetimes: Sessions that last many hours give stolen tokens more time to be abused.
• Weak token validation: Applications that skip audience or issuer checks may accept tokens meant for another service.
• Token theft from endpoints: Session tokens copied from browsers or developer machines can be replayed until they expire.
• Limited monitoring: Unusual role assumptions, token exchanges, or new federation trusts often go unreviewed.

How Can Organizations Secure a Security Token Service?

Start by treating the STS and its signing keys as tier 0 assets, on the same level as domain controllers.

Organizations should then:

• Protect signing keys in hardware security modules or managed key services, and rotate them on a schedule.
• Restrict trust policies to named principals, accounts, and conditions such as specific repositories or branches.
• Keep token lifetimes as short as workloads allow.
• Require MFA before issuing tokens for privileged roles.
• Validate issuer, audience, signature, and expiry in every relying application.
• Log every token request and alert on unusual role assumptions, new identity provider trusts, or tokens issued from unexpected locations.
• Review federation trusts and assumable roles as part of regular access reviews.

Sennovate’s Identity and Access Management services help organizations design federation, configure cloud role assumption, and monitor token activity across Okta, Microsoft Entra ID, AWS, and Google Cloud.

STS vs. Identity Provider

In practice the line blurs, because many identity platforms authenticate users and issue tokens in one product. The distinction matters when designing trust: whoever controls token issuance controls access.

Frequently Asked Questions About STS

Is AWS STS the Same as a Security Token Service?

AWS STS is one implementation of the concept. It issues temporary credentials for AWS resources, while the broader term covers any service that issues and exchanges security tokens.

What Is the Difference Between an STS and OAuth?

OAuth 2.0 is an authorization framework. The authorization server in an OAuth deployment often performs STS functions, and RFC 8693 defines how clients exchange tokens through one.

Does an STS Replace MFA?

No. MFA verifies the person during authentication. The STS issues tokens after that check and can include MFA status as a claim, so applications can enforce it.

Why Do STS Tokens Expire So Quickly?

Short lifetimes limit the damage a stolen token can do. Workloads request fresh tokens automatically, so short expiry rarely affects users.

Make Token Issuance a Governed Control

Every federated login, cloud role, and automated pipeline depends on tokens that an STS issues. That makes token issuance one of the most powerful controls in an identity program.

A mature approach protects signing keys, keeps tokens short lived and narrowly scoped, and monitors every exchange.

Learn how Sennovate approaches identity first security and Zero Trust across users, workloads, and cloud platforms.