I have setup an enterprise ADFS connection, with the user going through the PKCE authorization grant with offline access added to the scope. This retrieves for me a refresh token. I mistakenly thought that using this refresh token → new access token → user data would refetch the user data from the original identity provider. It does not appear to do this, and just fetches the cached user data from within auth0’s user information. This information is never updated unless the user goes through the login page against the original identity provider again.
Is there a way to re-authenticate against the primary identity provider for a user without them actually entering their password if they have given offline scope. Can the use of the refresh token actually re-fetch the user data from the identity provider?
To my knowledge that would be a no because the enterprise ADFS connection is configured to be based on WS-Federation which has no concept of refresh tokens. Refreshing the information obtained after the initial end-user authentication in Auth0 would require interacting again with ADFS which could technically not require the end-user to provide a password again, but that would not be because of refresh tokens or offline scope, it would be if the end-user still had an authenticated session and ADFS decided to reuse it instead of prompting credentials.
The above in conjunction with the fact that refresh token obtained from the direct interaction with your Auth0 tenant is scoped to the tenant itself; that is, it allows to obtain refreshed tokens that would grant access to what’s within the domain of the tenant and any updates to information happening in the primary IdP would not be within that domain until a new authentication operation is performed that retrieves it.
As additional information and just something for you to consider because it would take some additional work when compared to using the built-in ADFS connection. In theory, ADFS also supports OAuth2 which means you could broker the communication between Auth0 and ADFS through a custom OAuth2 connection. Given that custom OAuth2 connection allow to store a refresh token associated with the primary identity provider you could then obtain that refresh token to directly obtain newer tokens from ADFS itself which could address you situation, although with additional overhead.
Thanks for the detailed answer @jmangelo. At the time of implementation I didn’t realize WS-Fed didn’t allow for the refresh token cycle. This may be my naiveté but the doc for [enterprise ADFS][1] only implies that the connection uses WS-Federation via the use of federation metadata, and this may be unclear for other users. It may be useful to have that spelled (that this is a WS-Federation connection) with a link to WS-Federation limits at the top of that documentation. I will look into the custom O-Auth2 connection. Thanks again [1]: Connect Your App to ADFS
Thanks for the detailed answer @jmangelo. At the time of implementation I didn’t realize WS-Fed didn’t allow for the refresh token cycle. This may be my naiveté but the doc for [enterprise ADFS][1] only implies that the connection uses WS-Federation via the use of federation metadata, and this may be unclear for other users. It may be useful to have that spelled (that this is a WS-Federation connection) with a link to WS-Federation limits at the top of that documentation. I will look into the custom O-Auth2 connection. Thanks again [1]: Connect Your App to ADFS