Delen via

OAuth 2.0 support in ADFS on Windows Server 2012 R2

  • Artikel

Hi, there! A previous post talked about the new features we’ve added to ADFS on Windows Server 2012 R2. This post continues along that theme and talks about support for the OAuth 2.0 authorization framework in ADFS.

OAuth 2.0 is an open standard created by the IETF for authorization and is documented by RFC 6749. The OAuth 2.0 authorization framework is widely implemented across the industry.

Supported authorization grants

Authorization grant type ADFS (Windows Server 2012 R2)
Authorization code grant Supported
Implicit grant Not supported
Resource Owner Password Credentials grant Not supported
Client Credentials grant Not supported

 

Supported client types

Client type ADFS (Windows Server 2012 R2)
Public client Supported
Confidential client Not supported

Since ADFS on Windows Server 2012 R2 does not support confidential clients, it does not implement any client authentication method described in RFC 6749. Additionally, the ADFS server does not support the use of unregistered clients – clients that are not registered with ADFS will not be issued access tokens. 

 

Supported token types with OAuth 2.0

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. JWTs are much easier to work with than SAML tokens and can be easily manipulated in a wide variety of programming languages. Note that ADFS does not issue SAML tokens over the OAuth 2.0 authorization protocol.

Access Tokens: ADFS issues short-lived access tokens whose lifetime is governed by the per-Relying Party Trust setting called TokenLifetime. This defaults to 1 hour and can be configured by administrators to issue longer-lived access tokens. In line with industry-wide security recommendations, we encourage the use of short-lived access tokens.

Refresh Tokens: ADFS issues refresh tokens in response to the authorization code grant. The refresh token lifetime is longer for workplace joined devices (i.e. up to 7 days) and is comparatively short-lived for unregistered devices (i.e. up to 24 hours). This experience is consistent with persistent SSO lifetime semantics on ADFS. Refresh tokens are encrypted and not meant for the consumption of clients.

 

Registering OAuth 2.0 clients with ADFS

You can register clients with ADFS and manage them using PowerShell cmdlets. The following cmdlets can be used to do so:

  • Add-AdfsClient – Registers an OAuth 2.0 client with ADFS.
  • Get-AdfsClient - Retrieves registration information for an OAuth 2.0 client.
  • Set-AdfsClient - Modifies registration settings for an OAuth 2.0 client registered with AD FS.
  • Enable-AdfsClient - Enables the use of an OAuth 2.0 client registration by AD FS.
  • Disable-AdfsClient - Disables an OAuth 2.0 client that is currently registered with AD FS.

ADFS enables you to register multiple redirect URIs for a single client. Dynamic client registration is not supported and clients must be registered statically using PowerShell cmdlets. This provides IT administrators greater degree of control over the client applications that are registered on their ADFS server. 

 

Microsoft’s extensions to RFC 6749

In order to better support enterprise authorization scenarios, we have included a few extensions to the core OAuth 2.0 RFC. These are documented in the MS-OAPX (OAuth 2.0 Protocol Extensions) document available on MSDN.

That’s it for now! I’ll cover OAuth configuration with a sample application in a subsequent blog post.

-----------------------

Mahesh Unnikrishnan