OAUTH 2.0 protocol support level for ADFS 2012R2 vs ADFS 2016


Active Directory Federation Services (ADFS) is a software component developed by Microsoft that can be installed on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries. It uses a claims-based access control authorization model to maintain application security and implement federated identity.

OAuth 2.0 is an open standard created by the IETF for authorization and is documented by RFC 6749 (https://tools.ietf.org/html/rfc6749). Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.

Starting from Windows Server 2012 R2 ADFS (Version 3.0) supports OAUTH 2.0 authorization protocol, and this post tries to clarify what this means. OAUTH 2.0 define various authorization grants, client and token types. ADFS started with the support of a subset of these, and  increased this support over time with Windows Server 2016 and his ADFS Version 4.0.

Authorization Grants

authorization grant type ADFS 2012R2 ADFS 2016
Authorization code grant

used to obtain both access tokens and refresh tokens and is optimized for clients (i.e. mobile apps) able to interact with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.

yes yes
Implicit Grant

is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI.  These clients are typically implemented in a browser using a scripting language such as JavaScript.

no yes
Resource owner password credential no yes
Client credential grant no yes

Client Types

Client Types ADFS 2012R2 ADFS 2016
Public Client Yes Yes
Confidential Client No Yes

Oauth confidential client authentication methods:

  • Symmetric (shared secret / password)
  • Asymmetric keys
  • Windows Integrated Authentication (WIA)

Token Types

Token Type ADFS 2012 R2 ADFS 2016
id_token

A JWT token used to represent the identity of the user. The 'aud' or audience claim of the id_token matches the client ID of the native or server application

no yes
access_token

A JWT token used in Oauth and OpenID connect scenarios and intended to be consumed by the resource. The 'aud' or audience claim of this token must match the identifier of the resource or Web API.

yes yes
refresh_token

This token is submitted in place of collecting user credentials to provide a single sign on experience. This token is both issued and consumed by AD FS, and is not readable by clients or resources.

yes yes

ADFS issues access tokens and refresh tokens in the JWT (JSON Web Token) format in response to successful authorization requests using the OAuth 2.0 protocol. ADFS does not issue SAML tokens over the OAuth 2.0 authorization protocol.

Further information

Comments (0)

Skip to main content