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.
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)|
|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.