What are the key Security Token Service best practices?

What an STS must do before it issues a token

A security token service is only trustworthy when it treats token issuance as a control point, not a convenience layer. The service should authenticate the requester strongly, ensure the token is meant for the correct audience, and sign it with keys that downstream systems can validate consistently. That prevents a valid token from becoming a generic bearer credential that works everywhere.

Token audience and issuer checks matter because they define where a token can be accepted. If either check is loose, a token minted for one application can be replayed against another, or an application can accept a token from the wrong authority. Consistent signature validation is the other half of the trust decision, because applications need to verify the token was issued by the expected STS and has not been altered.

For a practical treatment of token lifetimes, validation, revocation, and replay resistance, see Token and Session Security Guide.

How to keep the STS itself from becoming the weak point

An STS concentrates trust, so it deserves the same hardening discipline as an authentication boundary. Abuse resistance is part of the design: rate limits, careful request validation, and tight control over who can request which token shapes all reduce the chance that the service becomes a token factory for an attacker. Logging issuance and failure events is essential because token abuse often looks like normal traffic until the pattern is reviewed.

Key rotation is also a trust-management issue, not just a crypto task. If signing keys change abruptly or without a controlled overlap, downstream services may reject valid tokens or continue trusting stale ones. The goal is to rotate keys in a way that preserves verification continuity while retiring old keys promptly enough to reduce the blast radius if a signing key is exposed.

When token exchange or on-behalf-of flows are part of the design, follow RFC 8693: OAuth 2.0 Token Exchange so delegation is explicit rather than improvised.

What downstream applications should trust, and what they should still verify

Downstream services should trust the STS only after they have verified the parts of the token that define scope and provenance. That means checking issuer, audience, signature, expiry, and any claims that constrain how the token may be used. If one of those checks is skipped, the application is no longer relying on the STS as an authority, it is relying on whatever token string arrives at the door.

Short-lived tokens reduce exposure if a token is copied, logged, or intercepted, but lifetime alone is not enough. The application still needs to reject tokens that are expired, wrongly scoped, or issued for a different relying party. In practice, the safest pattern is to assume the token can move and make the verification rules strict enough that movement does not equal reuse.

For audience restriction and sender-constrained token handling, RFC 8707: Resource Indicators for OAuth 2.0 and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) are the right reference points.

Risk and Threat Considerations

An STS failure is high impact because it can turn one compromise into many valid tokens. If issuance controls are weak, an attacker can obtain tokens that look legitimate to multiple downstream services, then reuse them until expiration or until signing keys are rotated. The same risk appears when logs miss failed issuance attempts, because probing and abuse may go unnoticed.

Failure mechanism: Weak audience validation, weak issuer checks, or stale signing keys let an attacker present a token outside its intended trust boundary, or let an application keep accepting tokens that should no longer be trusted.

Impact: Unauthorized access can spread across connected applications, and recovery may require mass token invalidation, key rotation, and review of all services that accept the affected issuer.

Practitioner Guidance

What to verify: Treat the STS as a policy engine, not just an issuing endpoint. Verify that the token profile in use actually enforces audience, issuer, expiry, and signing key checks in every relying application, because partial enforcement is the most common reason a “secure” token flow still fails in production.

Common mistake: Teams often focus on token creation and forget token consumption. The service may issue correctly, but if one downstream application accepts stale keys, ignores audience, or tolerates long-lived tokens, the weakest verifier defines the real security posture.

Practitioner takeaway: The core judgment is whether every token is both narrowly issued and narrowly accepted; if either side is loose, the STS becomes a distribution channel for reusable trust instead of a control boundary.

Related resources from NHI Mgmt Group

• What are the key Service Mesh Security best practices?
• What are the key Web Service Security best practices?
• What are the key endpoint security best practices?
• What are the key FIDO Security Key best practices?