Refresh token not available after initial login.

[mark-robustelli]

Refresh token not available after initial login.

Description

When using Google Login, the refesh token is not always available in the Access Token Response. It is available the first time the user logs into the application but not in subsequent logins. This was discovered in this this community thread.

Affects versions

Currently tested with 1.48.1

Steps to reproduce

Steps to reproduce the behavior:

1. Create an Application and enable debugging. I used fusionauth-quickstart-dotnet-web as a base.
   

2. Set up the application in Google
   

3. Create and Open ID Connect Identity Provider and enable if for the application

   • Need to do this so you can supply the access_type=offline to the Authorization endpoint.
     

4. Login to the application using the Open ID Connect button.
   

5. Choose your Google account.
   

6. Consent to access.
   

7. View the debug log and you can view the refresh token
   

8. Logout of Application.
   

9. Log back into Application using the Open ID Connect button.

10. Look at the logs and see there is now no refresh token.
    

11. Log out.

12. Go into the Google account you are using to test with and remove all connections with the test application.
    

13. Go to web application and login again using Open Id Connect Button.

14. View the logs and see the refresh token again.
    

Expected behavior

I expect the refresh token to be available every time the user logs in.

Platform

(Please complete the following information)

• Device: Desktop
• OS: macOS
• Browser + version Chrome 119.0.6045.159
• Database PostgresSQL with image.

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

Additional context

N/A

[robotdan]

The current design is that we take whatever the IdP returns and store it. So that means this is working how I expect.

We could optionally keep the previous value of the current login response doesn't return a refresh token.

The potential issue here is that we would just have to guess that the reason the IdP doesn't return a refresh token is because it thinks the prior one is still valid (assuming that is why Google is not retuning it on the second login - because the current session is still active).

Maybe this is a safe assumption? It just means we may hold onto old tokens unknowingly.

[jschatz1]

@robotdan @mark-robustelli I am confused. As a user of FusionAuth, I supposed to call Google to get the access token using the refresh token that is initially returned? I know that's how OAuth works but I was under the impression that fusionauth was handling much of the heavy lifting.
It does not say this in the docs that this is a refresh token.

[jschatz1]

To be clear all I need is the access token so I can call Google API's and I need that to be refreshed somehow. The token that comes back from retrieveUserLinksByUserId the typescript sdk is some times blank. This is my problem. @robotdan is right that we wouldn't expect the refresh token every time. I just need access to that access token so I can call Google APIs.

[mooreds]

@jschatz1 From https://fusionauth.io/docs/apis/identity-providers/openid-connect

FusionAuth will also store the refresh_token returned from the external OpenID Connect provider, if such a token is provided, in the identityProviderLink object, in the identityProviderLink.token field. This object is accessible using the Link API.

It varies based on the identity provider, but is documented in the API.

We should continue the support questions on the forum post, because this issue is for the bug that you uncovered (thank you!), not for support.

[mooreds]

@robotdan I agree that this is "working as designed" but it seems to me that nulling out an existing refresh token is not exactly behavior that the user will expect or desire. I think it is reasonable to think of the token field as remaining present. I think there are two options:

• document that the refresh token may be lost (on a provider by provider basis, depending if they send back the refresh token for subsequent logins)
• if the refresh token is not present, don't update the value.

the latter feels more in keeping with the documentation:

FusionAuth will also store the refresh_token returned from the external OpenID Connect provider, if such a token is provided, in the identityProviderLink object

Since the refresh token is not provided in the second login above, as Mark's screenshots show, we shouldn't update it. Basically, we should test if we get back a refresh token.

[jschatz1]

Honestly @mooreds if it was clearer that the token is a refresh token I might expect it to disappear. In many flows a refresh token is only provided once.

The API for the Link API does not re mention that this is a refresh token and instead it says it is an opaque token.

[mooreds]

Thanks for the feedback @jschatz1 . I'll take a look at the documentation and see if it can be made clearer.

[Noblebrown]

Pinging to see if there has been any further movement on this issue. Has anything been prioritized or investigated further, or is just a matter of updating the docs for clarity?

[mooreds]

@Noblebrown at this point, this is not in plan. The documentation may be clarified, but I don't expect any changes to the OIDC behavior.