Login via Auth0 does not persist

After login into Backstage application via Auth0 auth-provider, the login session does not persist.

Expected Behavior

Post login via Auth0 or any Oauth2.0 based authentication provider, the local storage should have saved session details. Subsequent refreshes or new tabs should not request user login again.

Current Behavior

After login to Backstage via Auth0, the session details do not get saved in the local storage. This leads to repeated user login requests upon refresh/new tab. All the information required for the session schema is available. The error is in the session local storage.

Possible Solution

https://github.com/backstage/backstage/blob/master/packages/core-app-api/src/lib/AuthSessionManager/RefreshingAuthSessionManager.ts does not have a saveSession implementation.

Taking Github as an example because this error is not present in login via Github. Github is using a mux for session storage comprised of AuthSessionStore https://github.com/backstage/backstage/blob/master/packages/core-app-api/src/lib/AuthSessionManager/AuthSessionStore.ts#L132 that has a saveSession.

A possible fix could be to have a similar saveSession available for OAuth2.

Steps to Reproduce

1. Setup Auth0 configuration by providing clientId, clientSecret and domain in app-config.yaml file.
2. Follow https://backstage.io/docs/api/deprecations#generic-auth-api-refs to setup auth0

Add the following code to apis.ts file:

export const acmeAuthApiRef: ApiRef<
  OAuthApi &
  ProfileInfoApi &
  BackstageIdentityApi &
  SessionApi
  > = createApiRef({
  id: 'internal.auth.acme',
});

  createApiFactory({
    api: acmeAuthApiRef,
    deps: {
      discoveryApi: discoveryApiRef,
      oauthRequestApi: oauthRequestApiRef,
      configApi: configApiRef,
    },
    factory: ({ discoveryApi, oauthRequestApi, configApi }) =>
      OAuth2.create({
        discoveryApi,
        oauthRequestApi,
        provider: {
          id: 'auth0',
          title: 'Auth0',
          icon: () => null,
        },
        defaultScopes: ['openid', 'email', 'profile'],
        environment: configApi.getOptionalString('auth.environment'),
      }),
  })

Add the following to identityProvider.ts file

  {
    id: 'auth0-auth-provider',
    title: 'Auth0',
    message: 'Sign In using Auth0',
    apiRef: acmeAuthApiRef,
  },

Add the following to App.tsx

    <Route
      path="/settings"
      element={
        <UserSettingsPage
          providerSettings={
            <ProviderSettingsItem
              title="AUTH0"
              description="Provides sign-in via Auth0"
              apiRef={acmeAuthApiRef}
              icon={Star}
            />
          }
        />
      }
    />

1. yarn start both the backend and frontend
2. Login via Auth0
3. Inspect the local session storage. It will not have any session stored.
4. Press refresh/open another Backstage app tab. The login does not persist.

Context

Inability to configure login via Auth0 or OAuth2 based auth-providers.

Your Environment

• NodeJS Version (v14): v14.18.3 Output of yarn backstage-cli info command on my Backstage App

OS:   Darwin 20.6.0 - darwin/x64
node: v14.18.3
yarn: 1.22.1
cli:  0.10.2 (local)

Dependencies:
  @backstage/catalog-client       0.3.19
  @backstage/core-app-api         0.1.24
  @backstage/core-components      0.3.3, 0.4.2, 0.5.0, 0.6.1, 0.7.6
  @backstage/core-plugin-api      0.1.13, 0.2.2
  @backstage/plugin-catalog-react 0.4.6, 0.5.2
✨  Done in 1.25s.

[Rugvip]

Hmm, alright, so at least we know that it’s not being lost somewhere then. It may be that Auth0 requires a particular scope to be passed for refresh to be allowed. You could try adding 'offline_access' here, like for example the OneLogin provider does.

[Rugvip]

Oh that would explain it 😁

Looks like it’s explicitly disabled, and has been since it was added. I’m not really seeing anything in the original PR that makes it look like that was intentional, so I’m assuming it’s just a bug.

Do you have a setup where you can try disabling it easily? I think it’s enough that we just verify that refresh works as expected and we can prolly then get rid of the flag