6

My colleague and I are trying to enable OAuth in ADFS 2.2. Everything is working except the server only passes back an access token (w/ expiration) and does not include a refresh token after successful login. There is very little documentation on this, but does anyone know what setting needs to be updated to return refresh tokens?

Edit: The proposed OAuth 2.0 spec states:

Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token

Since I am receiving an access token, but no refresh token, and since ADFS currently only implements OAuth's code flow, my guess is the ADFS team chose not to return refresh tokens. I would love to hear this definitively though.

Edit: Like Travis said below, make sure

  • RP's IssueOAuthRefreshTokensTo is set correctly
  • RP's AlwaysRequireAuthentication is false
  • RP's TokenLifetime is lower than ADFS' SSOLifetime
Community
  • 1
Matt Dearing
  • 113
  • 1
  • 6

1 Answers1

3

There is a configuration switch named IssueOAuthRefreshTokensTo on the ADFS relying party object which controls what type devices refresh tokens are emitted to. By default this value is set to "NoDevice" which implies that ADFS will not release refresh tokens. Possible values are

  1. NoDevice = never issue refresh tokens
  2. AllDevices = always issue refresh tokens
  3. WorkplaceJoinedDevices = only issue refresh tokens on workplace joined devices i.e. Ones that have been registered using the DRS service.

In addition to verifying if the relying party allows issuance of refresh tokens ADFS will also verify the following.

  1. The SSO token presented to ADFS will not expire before the access token to the RP expires. As long as you haven't changed the default configuration values and are coming in with a clean browser session ( i.e. no SSO cookie ) this case shouldn't come into play.
  2. The relying party is not marked to always required fresh credentials.

Can you also verify that you are sending a valid resource parameter in the authorization request?

ADFS has a debug log, If you can reproduce this behavior on a non-production system the easiest way to identify the issue might be to enable debug logs.

This article covers how to enable debug logs on an ADFS 2.0 system. ADFS 3.0 ( 2012 R2 ) is similar, the node names are slightly different and you don't need to enable WIF or WCF tracing in the config file.

http://social.technet.microsoft.com/wiki/contents/articles/1407.how-to-enable-debug-logging-for-active-directory-federation-services-2-0-ad-fs-2-0.aspx

Travis Querec
  • 91
  • 2
  • Travis, looking at our relying parties the switch is already set to "AllDevices" and still only an access token is returned. Is it possible there is another global setting that must be set first? – Matt Dearing Feb 07 '14 at 22:24
  • Travis, the only other thing I can think of is I'm going straight to ADFS starting the oauth flow (via a GET like https://domain.com/adfs/oauth2/authorize?response_type=code...) instead of requesting the actual resource I want and allowing a redirect to take place. I do pass the resource name in the authorize request and I end up getting an access_token that works with the intended resource, but I wonder if going straight to ADFS changes something with the flow that doesn't trigger the relying parties OAuthRefreshTokensTo switch. Could that be possible? – Matt Dearing Feb 08 '14 at 02:36
  • when using OAuth I would expect you to issue a GET directly to ADFS and not expect a redirect from the relying party. This won't affect the issuance of refresh tokens. – Travis Querec Feb 10 '14 at 20:29
  • Matt, I updated the answer with a few more details. Hope this helps. – Travis Querec Feb 10 '14 at 20:38
  • Travis, the resource parameter is correct for my resource. I get the access token successfully and if I tweak my resource parameter i get a 400 response. I'll check out the other things you suggested and write back with what I find. Thank you for responding to this. – Matt Dearing Feb 11 '14 at 02:36
  • Do these look okay? Is there something else we should be looking at? `PS C:> Get-AdfsRelyingPartyTrust |fl Name,IssueOAuthRefreshTokensto,alwaysrequireauthentication, tokenlifetime Name : domain.com IssueOAuthRefreshTokensTo : AllDevices AlwaysRequireAuthentication : False TokenLifetime : 960 PS> Get-AdfsProperties|fl SsoLifetime, PersistentSsoLifetimeMins, PersistentSsoEnabled, PersistentSsoCutoffTime SsoLifetime : 960 PersistentSsoLifetimeMins : 10080 PersistentSsoEnabled : True PersistentSsoCutoffTime : 1/1/0001 12:00:00 AM` – Matt Dearing Feb 19 '14 at 03:08
  • Travis, We were able to figure this out with your help. It appears the `TokenLifetime` is used for the access token expiration, while the `SsoLifetime` is used for the refresh token expiration. Thank you so much for your help! – Matt Dearing Feb 20 '14 at 18:04
  • Great! I'm glad you got it working. – Travis Querec Feb 21 '14 at 05:43