1.3 Overview

Active Directory Federation Services (AD FS) servers can be deployed in AD FS farm configurations, often behind a load-balancer, for increased scalability and reliability. The AD FS server implements the authorization server role for the OAuth 2.0 authorization framework and supports the Authorization Code Grant as defined in [RFC6749].

[RFC6749] section 4.1 illustrates the steps required to implement the Authorization Code Grant. In cases where AD FS servers are deployed in an AD FS farm with standalone artifact store, an OAuth client can receive an OAuth authorization code from any AD FS server that is part of the AD FS farm. Subsequently, when the OAuth client attempts to redeem that authorization code for an access token according to the steps outlined in [RFC6749] section 4.1, it might be redirected to a different member of the AD FS farm. Thus, a server that belongs to the AD FS farm with standalone artifact store might receive a request to redeem an OAuth authorization code that was issued by another server in the farm. Under these circumstances, the AD FS servers use the Active Directory Federation Services OAuth Authcode Lookup (ADFSOAL) Protocol defined in this specification in order to detect which server in the farm issued the authorization code and to retrieve the corresponding artifact from that server. The artifact thus retrieved contains the OAuth access token that is thereafter provided to the OAuth client in response to its request to redeem the OAuth authorization code. Note that the ADFSOAL Protocol does not apply to AD FS servers that are deployed in an AD FS farm with shared artifact store.

Sequence diagram for the ADFSOAL Protocol

Figure 1: Sequence diagram for the ADFSOAL Protocol

The above sequence diagram illustrates this flow. Two servers "AD FS server 1" and "AD FS server 2" are deployed in an AD FS farm with standalone artifact store configuration. In this scenario, the OAuth client initially received an OAuth authorization code from "AD FS server 2" using the steps defined in [RFC6749]. The OAuth client then attempts to redeem this OAuth authorization code for an access token by using the mechanism defined in [RFC6749]. However, the OAuth client is connected to "AD FS server 1", a different server than the one that originally issued the OAuth authorization code. In this scenario, "AD FS server 1" uses the ADFSOAL Protocol defined in this document to look up the artifact identifier contained within the OAuth authorization code on "AD FS server 2" and to retrieve the corresponding artifact from the artifact store on "AD FS server 2". The artifact thus retrieved contains the OAuth access token that is thereafter returned to the OAuth client in response to its access token request, according to the procedure defined in [RFC6749].

The ADFSOAL Protocol defines a client role and a server role. The client role of the ADFSOAL Protocol corresponds to the AD FS server that is part of the AD FS farm and needs to look up the artifact identifier contained within the authorization code presented to it by the OAuth client. The server role of the ADFSOAL Protocol corresponds to the AD FS server that is part of the same AD FS farm and originally issued the authorization code to the OAuth client.