Security token service
In a typical usage scenario, a client requests access to a secure software application, often called a relying party. Instead of the application authenticating the client, the client is redirected to an STS. The STS authenticates the client and issues a security token. Finally, the client is redirected back to the relying party where it presents the security token. The token is the data record in which claims are packed, and is protected from manipulation with strong cryptography. The software application verifies that the token originated from an STS trusted by it, and then makes authorization decisions accordingly. The token is creating a chain of trust between the STS and the software application consuming the claims. This process is illustrated in the Security Assertion Markup Language (SAML) use case, demonstrating how single sign-on can be used to access web services.
Security token services can be offered as web services, through the use of application programming interfaces (APIs), or for native applications in conjunction with software development kits (SDKs).
Broadly speaking, there are three types of Secure Token Services:
- IP-STS (Identity Provider Secure Token Service): authenticates clients directly. For an example see the diagram for OpenID Connect at this site.
- FS-STS (Federated Provider STS): Takes authentication tokens from an IdP and translates them for use by an RP. For an example see Active Directory Federation Services.
- RP-STS (Relying Party Secure Token Service): delegates client authentication to an IP-STS. The example at this site also shows how an RP can get tokens from a Federated Identity.
- sometimes also written as R-STS (Resource STS) or A-STS (Application STS)
|This computer security article is a stub. You can help Wikipedia by expanding it.|