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
- https://technet.microsoft.com/ru-ru/library/mt617220(v=ws.11)
- https://blogs.technet.microsoft.com/maheshu/2015/04/28/oauth-2-0-support-in-adfs-on-windows-server-2012-r2/
- https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-scenarios-for-developers
- https://medium.com/@robert.broeckelmann/saml2-vs-jwt-understanding-oauth2-4abde9e7ec8b