The chained use case means the Clientprovides an Access Tokenissued by another Authorization Serviceacting as an Identity Provider. This use case is illustrated in Figure 23.

image026.png

Figure 23– Chained Authorization

The Target Serveris the Serverthat the Clientwishes to access. The initial interactions are the same as with the Implicit use case described in 9.2.

The Sessionmay be created explicitly with a call to CreateSessionor it can be implicit via a Session-less Method Call.

After creating the Session, the Clientreads the available UserTokenPoliciesfrom the AuthorizationService Objectif it has not previously cached the information.It then chooses one that references an Identity Providerfor the user identities that it has available. The user identities may be provided out-of-band or they may be provided by an interactive user. The Clientthen requests an Access Tokenfrom the Identity Provider.

The Clientthen calls the RequestAccessToken Methodon the AuthorizationService Objectand passes the Access Tokenfrom the Identity Provider.

The Authorization Serverdetermines if the Clientis permitted to receive an Access Tokenbased on the claims granted by the Identity Provider. The rest of the interactions are the same as described in 9.2.