2.2.1.3 OAuth and OpenID Connect
Note When this overview document references OAuth, it is referring to the OAuth 2.0 Authorization Framework (as opposed to the OAuth 1.0 protocol, which has been deprecated and is not implemented in AD FS).
OAuth is a framework for authorization that is suited to a situation where a user, or resource owner in OAuth terms ([RFC6749] section 1.1), owns resources (or data) that are kept on a remote server, or resource server, and where the resource owner needs actions to be performed on that data by a client.
Note In OAuth terms, the client is an application or device that is performing actions on the data on behalf of the resource owner.
Traditionally in this type of situation, when the resource owner needed some action to be performed on data that resided on a remote server, the resource owner's credentials (for example, username and password) would need to be passed through the client that would be performing the action. This presented a potential security flaw in that the client now had access to the resource owner's credentials and would need to take certain steps to ensure the integrity and secrecy of those credentials. From the resource owner's perspective, this is a chancy situation. If the resource owner uses only a few clients, the problem of securing credentials and keeping them up-to-date can potentially be managed manually. This solution does not scale, however, in a more realistic scenario where the resource owner makes use of many different clients.
Using OAuth, the resource owner can authenticate with one authoritative source, an authorization server in OAuth terms ([RFC6749] section 1.1), and can then refer the client to the authorization server. The authorization server provides to the client the security materials that it needs in order to access the resource owner's data. In this way, the resource owner's credentials are known to only the authorization server, never to the clients. This is a more defensible position for resource owners and a simpler position for clients where they do not need to take on additional responsibility.
There are a number of ways in which OAuth can be implemented to provide the security advantages described above, as described in [RFC6749] section 1.3. AD FS supports the authorization code grant described in [RFC6749] section 1.3 and 4.1.
While it is true that an implementation of OAuth provides the security advantages described above, OAuth itself does not enable a relying party to verify the identity of the end user who can authorize the client to access protected resources, the resource owner in OAuth terms. For this, AD FS implements two parts of OpenID Connect: OIDC Discovery [OIDCDiscovery] and OIDC Core [OIDCCore]. Using OIDC Discovery, the relying party can discover the OpenID Connect services that need to be used for a particular end user. Given successful discovery of the relevant OpenID Connect services, the relying party then uses OIDC Core to verify the identity of the end user and obtain additional information about the end user.
An STS in AD FS acts as an authorization server. See [RFC6749] section 1.1 for a definition of this role.
OAPX (OAuth 2.0 Protocol Extensions)
When an OAuth 2.0 client [RFC6749] requests authorization from a resource owner, it is advantageous to include a reference to the actual resource that is needed. In this way, authorization requests can be processed more efficiently. This additional information is specified in the OAuth 2.0 Protocol Extensions [MS-OAPX].
The primary entities that are affected by these extensions are the OAuth 2.0 client that is requesting access to protected resources and the AD FS server.
OAPXBC (OAuth 2.0 Protocol Extensions for Broker Clients)
As an extension to the OAuth 2.0 protocol [RFC6749], a special OAuth client can be implemented that is able to retrieve tokens from an authorization server on behalf of other clients. This special client is called a broker client. The definition and mechanism of an OAuth broker client is specified in [MS-OAPXBC].
The primary participants in this protocol are the broker client and the authorization server.
ADFSOAL (Active Directory Federation Services OAuth Authorization Code Lookup Protocol)
An AD FS deployment can consist of just one AD FS server. In larger scenarios, however, it is more likely to have multiple AD FS servers, configured as an AD FS farm, that share the burden and that are placed behind some kind of load balancer.
In these scenarios, it cannot be assumed that the AD FS server that issues an authorization code to an OAuth 2.0 client [RFC6749] will be the same AD FS server that redeems that code for an access token. As such, a mechanism to communicate information about authorization codes is required among the servers in the AD FS farm. This mechanism is defined in the Active Directory Federation Services OAuth Authorization Code Lookup Protocol [MS-ADFSOAL].
The primary participants in this protocol are the AD FS servers that are part of an AD FS farm.
OIDCE (OpenID Connect 1.0 Protocol Extensions)
OpenID Connect provides for an identity layer on top of OAuth. This identity layer allows clients to verify end-user identity through an authorization server. OIDCE [MS-OIDCE] defines extensions to select parts of OpenID Connect. The extensions specified in OIDCE define additional claims to carry information about the end user, including the user principal name (UPN), a locally unique identifier, a time for password expiration, and a URL for password change. These extensions also define additional provider metadata that enable the discovery of the issuer of access tokens and give additional information about provider capabilities.