Fixing Backstage sign-in errors

It means the frontend asked for a sign-in method that the backend has no provider configured for. The usual cause is that the provider is missing from the auth configuration, or the sign-in page lists a provider that was renamed or removed. Check the auth section of app-config.yaml and app-config.production.yaml for a providers block with the provider ID the login page requests. Add the provider under auth.providers with its client settings, restart the backend, and confirm the sign-in page only offers providers that exist. Keep the provider key identical in the frontend sign-in component and the backend configuration, because a mismatch produces the same message. The Backstage authentication documentation describes the provider configuration structure for each supported identity provider.

The provider authenticated the user, but no sign-in resolver turned that result into a Backstage identity. Backstage needs a resolver for each provider that maps the external profile to a User entity in the catalog. Without a resolver, or with one that throws, sign-in fails at this step. Check the backend logs for the resolver error at the time of sign-in, and check the provider block under auth.providers.<provider>.<environment> for a signIn.resolvers entry. Add a resolver that matches the provider's claims, such as the email or username, to a catalog user. Then sign in again with a clean browser session so the old failed attempt does not stay cached. The exact log text varies by provider and version, so confirm the wording in your own logs rather than relying on a copied string.

The resolver ran, but the identifier it built, such as an email or username, does not match any User entity in the catalog. Compare the value the resolver produces with the metadata.name or spec.profile.email on the User entity. Common mismatches include different casing, a domain suffix that the directory adds or drops, or a username format that differs between the identity provider and the catalog source. Fix the mismatch in the resolver logic or in the entity source so both use the same key. The authentication documentation advises that every provider resolves to the same identity, so a single agreed key across providers avoids a second class of mismatch. Test the resolver with a known user before rolling it out to everyone.

Backstage resolves identity against User entities that the catalog has already ingested, so a directory user who has not been imported yet has nothing to match. This is a timing and ingestion problem, not a provider problem. Check that the catalog provider for your directory is configured under the catalog section, that it has run, and that the users it imports are within the scope you intended, such as the right group or organization. Look at the catalog processing results for the entity to see whether ingestion failed. Once the user entity exists and processing completes, retry the sign-in. The Backstage architecture overview explains how the catalog fits into the backend, which helps when tracing where a user entity is expected to come from.

A frontend that still offers guest sign-in or a provider you removed will send users into a flow the backend no longer supports. Guest access is useful for local development, but the authentication documentation advises against offering it in production. Search the frontend for the sign-in provider list and any guest provider entry, and remove the entries that the backend does not serve. Then rebuild the frontend, because sign-in pages are compiled into the bundle and a config change alone may not update them in every setup. Confirm that the production build no longer offers guest access, and that users landing on the sign-in page see only supported providers.

Run configuration validation against the same environment files you deploy, so errors surface before users see them. The config:check command in the Backstage CLI reads the configuration and reports values that do not match the schemas that plugins declare. Run it with the production configuration file included, and use --strict in CI so warnings fail the build. Keep provider secrets in environment variables or a secrets store rather than in committed files, and confirm the variables are set in the target environment. Validation catches structural and type errors, but it does not prove that the provider accepts your client settings or that a resolver matches real users, so test sign-in in a non-production environment after the check passes.

Your team can usually diagnose and fix sign-in errors with access to the backend logs, the configuration files, and the identity provider's admin console. The work is mostly reading configuration, matching identifiers, and testing one provider at a time. A partner adds value when the identity design spans several providers, when a directory sync or catalog ingestion must be redesigned, or when the change needs to be documented as evidence for a compliance review. DeployOpen implements and documents self-hosted open-source platforms in infrastructure you control, and its work is agreed in a written, fixed scope before it starts. Ask for a quote based on the providers, environments and resolver logic in question.

No fixed duration can be given before the environment is reviewed, because the time depends on how many identity providers are involved, how cleanly user records map to catalog entities, and whether the fix needs changes in the identity provider itself. A single provider with a clear user identifier and an existing org model usually needs far less work than a setup with several providers, legacy guest access, or a catalog that has never been populated from the directory. Ask for a written scope that lists each provider, each resolver, and each environment (development, staging, production) so the timeline follows from that list.

Yes, a team that already runs Backstage and understands its identity provider can usually resolve these errors itself, provided it has time to read the authentication configuration and test changes outside production. The errors are often caused by a resolver that does not match what the provider returns, or by a catalog that does not contain the user, and both are traceable in logs and configuration. Outside help is most useful when several providers must resolve to one identity, when the team lacks admin rights in the identity provider, or when a production outage needs a fix under time pressure.

The work needs a named contact who can approve changes, read-only or admin access to the identity provider for the applications Backstage uses, a copy of the current app configuration with secrets removed, and access to the catalog data that describes users and groups. A non-production test tenant or staging instance of the identity provider is strongly preferred, so that resolver changes can be tested without affecting staff who sign in today. Confirm with your identity team which app registrations, client identifiers and claim settings can be shared and under what conditions before any access is granted.

The initial fix is one-time work, but some of its parts recur. Each new identity provider, each change to how users are named in the directory, and each Backstage upgrade can change the claims a resolver receives, so the configuration needs checking after those events. Routine checks with configuration validation in CI, and a documented list of which resolver serves which provider, reduce the chance of a repeat failure. Ask whether the quote includes handover documentation and whether you want ongoing support through a retainer for upgrades and provider changes.

A quote is built from the written scope, and its main components are analysis of the current configuration, changes to Backstage authentication and resolver code, changes to identity provider settings if you allow them, testing in a non-production environment, and documentation with handover. Costs rise with the number of providers, the number of environments, and the complexity of the catalog mapping. Ask each vendor, including DeployOpen, to itemize these components so you can compare scope rather than headline totals. DeployOpen does not publish a price list, and a quote follows from the agreed scope.

A fixed-scope engagement covers the agreed set of sign-in problems, the named identity providers and environments, the resolver changes needed to fix them, verification steps, and the documentation that records the final state. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Anything outside that list, such as a new provider, a redesign of the catalog model, or unrelated scaffolder failures, would be scoped separately. Ask for the list of deliverables and the acceptance checks in writing before signing.

Confirm it by running the same sign-in flows in a non-production instance that mirrors the production authentication configuration, then checking the configuration with config:check --strict before deploy. Verify that each provider resolves to the same catalog user, that guest access is disabled in production, and that a user missing from the catalog receives a clear error instead of a broken session. Ask your team to record the test accounts, expected outcomes and rollback steps before the change window opens.