ADFS – OAuth Access Token Lifetime in Windows Server 2019

It looks like what you are trying to do is have a dev server federated with adfs from domain 1 and then have the adfs from domain1 to accept tokens from adfs in domain2 using a claims provider trust. This way, users from domain1 and domain2 will be able to logon and access the dev server's app provided the claims rules are configured correctly.

So the answer to your 2nd question is to configure a claims provider trust on the adfs in domain1 to point to adfs in domain 2 and claims rules to transform/passthrough claims received from adfs in domain1. Then the adfs in domain 2 will also need a relying party trust configured to point to adfs 1 where you choose what claims to gather and send on.

as for question1, it definitely looks like the private key for the service communications certificate in adfs is inaccessible. If you installed the adfs as a farm, you will have a domain based service account. if you built it as a standalone adfs it will be using the builtin network service account. This choice decides how you configure permissions on the cert.

you mention adfs role and adfs 2.0 so i am not sure if you are using adfs 2 on both servers or the inbuilt role shipped with windows 2008/R2. Please clarify.

these step by step guides should help.

http://technet.microsoft.com/en-us/library/adfs2-federation-wif-application-step-by-step-guide(v=ws.10).aspx

for all things adfs please see

http://social.technet.microsoft.com/wiki/contents/articles/2735.ad-fs-2-0-content-map.aspx

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