---
title: Introduction to STS
description: The Security Token Service (STS) lets AM bridge identities across existing federated environments to establish cross-domain trust relationships using token transformations. For example, you can federate two different environments by transforming OIDC ID tokens into SAML 2.0 assertions.
component: pingam
version: 8.1
page_id: pingam:sts:chap-sts-introduction
canonical_url: https://docs.pingidentity.com/pingam/8.1/sts/chap-sts-introduction.html
keywords: ["Security Token Service (STS)"]
page_aliases: ["sts-guide:chap-sts-introduction.adoc"]
section_ids:
  supported_features: Supported features
---

# Introduction to STS

The Security Token Service (STS) lets AM bridge identities across existing federated environments to establish cross-domain trust relationships using token transformations. For example, you can federate two different environments by transforming OIDC ID tokens into SAML 2.0 assertions.

To do this, AM provides a [REST STS framework](sts-rest.html) for token transformations. This framework is loosely based on the SOAP [WS-Trust](https://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html) specification.

A WS-Trust model involves communication between the components, a requestor, web service, and the STS:

* The *requestor* is a web client or programmatic agent that wants to use a service offered by the web service.

* The *web service* lets authenticated and authorized clients access resources or applications.

* The *identity provider* stores claims about subjects and works with the STS to issue security tokens.

* The *STS* acts as a trusted third-party web service. It asserts the identity of a requestor across different security domains through the exchange of security tokens and brokers a trust relationship between the requestor and the web service provider. The STS issues tokens based on its configurations, which model the identity of a given identity provider, and issues tokens to a specific relying party.

* A *security token* is an STS data structure representing a set of claims that assert the identity of a subject. A single claim is identity information, such as a subject's name, age, gender, and email address.

Web services and requestors (that is, consumers or clients) are typically deployed across different security domains and topologies. Each domain may require a specific security token type to assert authenticated identities. The STS provides a way to exchange tokens across these different domains without re-authenticating or re-establishing trust relationships while allowing the requestor access to a web service's protected resources.

## Supported features

The STS supports the following features:

* REST endpoints

  REST endpoints are exposed upon instance creation.

* Token transformations

  The STS issues OpenID Connect V1.0 (OIDC) and SAML 2.0 tokens (bearer, holder-of-key, sender vouches).

  * OIDC

    Username token → OIDC\
    OIDC → OIDC\
    X.509 token → OIDC\
    AM Session token → OIDC

  * SAML 2.0

    Username token → SAML 2.0\
    X.509 token → SAML 2.0\
    OIDC token → SAML 2.0\
    AM Session token → SAML 2.0

* Publish service

  You can configure STS instances using the AM admin UI or programmatically. AM provides an STS publish service that lets you publish these instances with a POST request to the endpoints. Because a published instance can have only a single encryption key, you need one published instance per service provider that the web service invoking the STS intends to call.

* Custom SAML assertion plugins

  AM supports customizable SAML assertion statements. You can create custom plug-ins for `Conditions`, `Subject`, `AuthenticationStatements`, `AttributeStatements`, and `AuthorizationDecisionStatements` statements.

* Custom token validators and providers

  The STS provides the ability to customize tokens. For example, you can configure STS to transform a token of type CUSTOM to a SAML 2.0 token.