4.5 Security Token for Accessing a Third-Party Service with Extensions

 In this example, the client tries to access a resource on a third-party service. The service responds with an HTTP 401 challenge that lists the security token issuers it trusts in the trusted_issuers field. An example of such a challenge is as follows.

 HTTP/1.1 401 Unauthorized
 Server: Fabrikam/7.5
 request-id: 443ce338-377a-4c16-b6bc-c169a75f7b00
 X-FEServer: DUXYI01CA101
 WWW-Authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0001-0000-c000-000000000000@*"
 WWW-Authenticate: Basic Realm=""
 X-Powered-By: ASP.NET
 Date: Thu, 19 Apr 2012 17:04:16 GMT
 Content-Length: 0
  1. The client sends its credentials to the indicated security token issuer, which is an STS. The credentials include an appctx claim that contains additional user information to be provided to the service. The STS does not examine or modify the user information in the appctx claim.

  2. The STS authenticates the client and issues an actor token to the client that includes the appctx claim provided by the client.

  3. The client uses the actor token to access the resource it requested on the service. The actor token includes the appctx claim that was previously supplied by the client and contains additional user information to be provided to the service. This scenario is analogous to the use of outer and inner tokens to convey additional user information to a server beyond what is required to authenticate to an STS, as described in section 4.3 and section 4.4.

The following is an example of a security token that is used to access a third-party service and contains user information. For more information about the claim values contained in this security token, see section 2.2.