Authentication Error | User not found [Google Provider]

Expected Behavior

Authentication Plugin allow the user to access the platform.

Actual Behavior

Error message.

Steps to Reproduce

packages/backend/src/plugins/auth.ts

import {
  createRouter,
  providers,
  defaultAuthProviderFactories,
} from '@backstage/plugin-auth-backend';
import { Router } from 'express';
import { PluginEnvironment } from '../types';

export default async function createPlugin(
  env: PluginEnvironment,
): Promise<Router> {
  return await createRouter({
    ...env,
    providerFactories: {
      ...defaultAuthProviderFactories,
      google: providers.google.create({
        signIn: {
          resolver:
            providers.google.resolvers.emailLocalPartMatchingUserEntityName(),
        },
      })
    },
  });
}

Context

After releasing https://github.com/backstage/backstage/blob/master/plugins/auth-backend/CHANGELOG.md#0130 we started to encounter this issue.

Your Environment

Node.js v16.14.2 Yarn 1.22.17 Ubuntu 20.04.4 LTS

[Rugvip]

Sorry we didn’t document the pattern of bypassing the catalog during login more clearly. It’s apparent it’s something a lot of you do. Here’s an example of a sign-in resolver that uses the local part of the email directly as the user entity name, without looking up the user in the catalog:

okta: providers.okta.create({
  signIn: {
    resolver: async ({ profile }, ctx) => {
      if (!profile.email) {
        throw new Error(
          'Login failed, user profile does not contain an email',
        );
      }
      const [localPart] = profile.email.split('@');

      const userEntityRef = stringifyEntityRef({
        kind: 'User',
        name: localPart,
        namespace: DEFAULT_NAMESPACE,
      });
      return ctx.issueToken({
        claims: {
          sub: userEntityRef,
          ent: [userEntityRef],
        },
      });
    },
  },
}),

The example here is with the Okta provider, but the general pattern applies to all providers. stringifyEntityRef and DEFAULT_NAMESPACE are both imported from @backstage/catalog-model. We’ll probably have a few more of these built in in the future, gonna make sure we add it to docs too.

Regarding the removal of the default sign-in resolver for each provider, it was partly to remove confusion, but most importantly a security fix. Allowing all providers to be used for sign-in by default leads to at best confusing behavior, and at work an insecure setup.

[Alan-pad]

Seems to affect more than only the Google provider, got the issue on Github Provider as well. It seems that the default behavior before was to create the user entity if it wasn’t found during lookup. Now the entity is not created, thus we’re getting “User Not Found”. Does anyone have a workaround for that ? For Github I think enabling the organization auto-discovery feature will make it work but it does not really address the elephant in the room for other providers 😄