🐛 Bug Report: auth.getAccessToken doesn't survive page reloads anymore

[kunickiaj]

📜 Description

When calling auth.getAccesToken for the GitHub provider, it forces the user to login even if they're already logged in. This session can withstand route changes and subsequent calls, but not a page reload. The user will see a login popup again.

👍 Expected behavior

It should work as it used to where if the provider has already been authorized, a token should be returned.

👎 Actual Behavior with Screenshots

It actually props the user to login on every page load.

👟 Reproduction steps

Using backstage 1.18.3 try something like the PR plugin (https://github.com/RoadieHQ/roadie-backstage-plugins/tree/main/plugins/frontend/backstage-plugin-github-pull-requests)

I'm experiencing the same behavior on an internal techdocs addon that calls the GH api.

📃 Provide the context for the Bug.

No response

🖥️ Your Environment

Chrome Version 117.0.5938.132 (Official Build) (arm64)

👀 Have you spent some time to check if this bug has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

Yes I am willing to submit a PR!

[kunickiaj]

Relates to #20103 which doesn't seem to be fully fixed

[kunickiaj]

Can anyone else confirm that they're experiencing this issue?

[gusevda]

@kunickiaj I can confirm the issue.

After some investigation I think there is a problem in the session refresh handler. I see that the scope previously saved in cookie is being used to refresh a session but is missed in the response. I guess this line should be fixed, like this e.g.:

scope: authenticator.shouldPersistScopes ? scope : result.session.scope,

[shoeletz]

@kunickiaj I updated and am encountering this issue as well, using Okta auth.

[kunickiaj]

@kunickiaj I can confirm the issue.

After some investigation I think there is a problem in the session refresh handler. I see that the scope previously saved in cookie is being used to refresh a session but is missed in the response. I guess this line should be fixed, like this e.g.:

scope: authenticator.shouldPersistScopes ? scope : result.session.scope,

Not very familiar with this implementation so going to try to add some more details to what i'm observing if it helps..

When loading a page that has a plugin that wants gh repo scope (to make some gh requests) i see:
/api/auth/github/refresh?optional&scope=repo&env=production called in the browser -- which is correct afaict

it returns a response that even includes the accessToken, however scope is ""
e.g.

{
...
  "providerInfo": {
    "accessToken": "ghu_....",
    "scope": "",
    "expiresInSeconds": "28800"
  }
...
}

Once i click on the login popup i see that GH requests are made with a different ghu_ token from the one above.

I think this might confirm your suspicions that the requested scope is not being returned in the response.

[kunickiaj]

I can confirm that modifying one of our internal plugins to request an access token for '' scope instead of 'repo' scope successfully returns an access token that still work with repo scope.

I'm happy to open a PR with the suggested change, just not entirely sure how to best test it (or add a unit test for it).

[kunickiaj]

nvm, was able to repro/verify fix using yarn dev on the demo backstage. will work on getting a PR together shortly.

what is the process for getting this backported as 1.18.4 ?